Renovate integration with Dependabot security alerts for transitive dependency upgrades

[dge808]

Tell us more.

I’d like to open a discussion related to an increase in security issues in transitive dependencies of node modules. While Renovate does an excellent job of keeping direct dependencies up to date, it currently cannot update transitive dependencies unless the top-level dependency itself is updated. I understand this is an expected behaviour at the moment, but as a result, vulnerabilities in indirect dependencies often remain unresolved, especially when upstream packages are slow to release new versions.

I am wondering if the current behaviour can be extended to work together with Dependabot security alerts and open PRs that update dependencies to non-vulnerable versions, creating overrides if necessary? I expect this to target only those dependencies flagged by security alerts.

I’ve discussed this idea with @secustor, and we thought it might be worth opening it up to the community for consideration and feedback. Also, I would be happy to contribute to this topic.

[romanserazhiev]

I think it's a great idea! But isn't renove already doing this on its own? Doesn't Renovate create PRs to bump packages even without security issues.

[jamietanna]

Renovate is currently doing this for direct dependencies, but not transitive dependencies, which is the key thing we'd be adding here

[jamietanna]

I'll be on holiday next week, but hope to get a more full response when I'm back - to use terminology from the Go ecosystem, this is a "likely accept", with some caveats (which I'll share more in the future)

[dge808]

Hello, just a quick check-in on this, let me know what you think when you have a moment🙏🏽 Hope you’re having a good week!

[kyle-bookbub]

This would be a great feature. We are evaluating Renovate as a replacement for Dependabot, but this is a missing feature that makes it tough to recommend. Dependabot is also struggling with pnpm transitive dependencies, so if Renovate could handle that we'd be more enthusiastic adopters.

[aolkin]

I'll be on holiday next week, but hope to get a more full response when I'm back

I hope your holiday went well! I would be very interested in this feature as well and would love to hear more about the potential implementation.

[noahw3]

This would be great, I just went looking for how to enable security updates for transitive dependencies and was surprised that it isn't a supported feature.

I'll also add, the suggested workaround to enable lockFileMaintenance doesn't seem like a great idea to me for a few reasons (since it essentially reduces the value that the lockfile is providing):

1. It updates every package. This introduces not insignificant risk of introducing a breaking or behavioral change if library maintainers aren't following semver perfectly.
2. This also puts you at higher risk of supply chain attacks. If there is a compromised package anywhere in your dependency tree at the time of lockfile regeneration, you've now fallen victim.
3. Security updates may lag. Assuming that lockfile maintenance is run once a week, you can't prioritize security fixes to run with a higher priority. For example, my team runs normally dependency updates once a week, but security fixes are prioritized to run every day. Of course, you could run lockfile maintenance more often, but that just exacerbates the above two points and further reduces the value of the lockfile.

[jamietanna]

Hey folks, apologies for the late reply on this - my TODO list increases roughly twofold every day 🫣

I can confirm that this is a "yes" we'll be up for implementing this - I'll add a bit more detail shortly and get an Issue raised

[zoephilipps]

I'll just throw our hat in the ring: we'd love this for package.json! It came up very recently for us and I suspect it will continue to.

[moonmeister]

Obviously this would be great. I wanted to make a note for whomever decides to implement this. We recently had a site outage due to overrides using >= instead of ^ range. (For some reason the former is default for audit --fix. This meant next.js got an unplanned major version bump. One that wasn't obvious when reading the package.json. The other major factor was that overrides were being used for immediate dependencies instead of running updates and only using overrides for transitive dependencies.

Thus whatever solution is built should protect against this kind of scenario.

[dge808]

hey @jamietanna I think that probably npm, pnpm and yarn are the most popular ones. I have a personal bias towards pnpm 🙂
If by updating the lockfile directly you mean manually, I think this is not a reliable option due to integrity checks, and different registries being used.
Maybe it is possible to mimic pnpm dedupe behavior, afaik it will update lockfile only to the highest version that "satisfies all constraints across the whole dependency tree" - this will solve some vulnerabilities without risking to break packages, safer approach. But this means some vulnerabilities will stay; sometimes we have to go for override in order to fix it. In this case, if Renovate is going to support an override in package.json, maybe it is possible to add something like "overrideMaintenance" to cleanup overrides that are no longer needed, but adding this is not a high priority I think.

[dontgitit]

not sure if this is directly relevant, but fwiw pnpm 11 introduces support for audit --fix=update to directly update the lockfile rather than add overrides

regarding "cleanup overrides that are no longer needed" - we wrote a github action in our repo that checks overrides and

1. for ranges, like package@<v1: v2 it'll remove the line and check if pnpm audit produces an alert for that package
2. for compatibility pins, like package: v3 it'll remove the line and check if pnpm why package returns multiple versions

happy to share the action if it's helpful!

[espipj]

is there any progress on this?