Update dependencies to resolve security vulnerabilities in sub-dependencies

[mattpardee]

What would you like Renovate to be able to do?
GitHub informs of vulnerabilities for sub-dependencies present in package-lock.json, but Renovate doesn't cut PRs for updating the top-level dependencies that would resolve those vulnerabilities.

Describe the solution you'd like
For Renovate to know when there's a vulnerability in deps' sub-dependencies and then cut a PR for updating the top-level deps to the version that contains the resolution of the security issue.

Describe alternatives you've considered
A more regular schedule to update our top-level dependencies (e.g. every day).

Additional context
We discussed this on Twitter. Thanks Rhys!

[rarkins]

Thank you for making an issue for this to track progress.

When Renovate reads the vulnerability alerts, it converts them into packageRules. However the depName for each rule will be the vulnerable dependency and not the top level dependency itself.

Two possibilities:

1. The top level dependency needs updating and the vulnerable transitive dependency will get updated at the same time (easy)

2. The top level dependency is up to date but the lock file holding back the vulnerable transitive dependency. (Harder)

For point 1, we need to trace back the vulnerable dependency to its top level and make sure they one is updated like usual.

For point 2, we need to poison the lock file to force the update of the vulnerable transitive dependency. The question is how to describe this.

Another possibility is to trigger lock file maintenance of the whole file if we detest a transitive vulnerability that can’t be solved at the top level.

[songkeys]

@rarkins

I believe the second point is the more reasonable, which is dependabot's current behavior.

The question is how to describe this.

What do you mean by this? How to describe the API field or how to implement it?

[rarkins]

This is now implemented for npm@6 behind the feature flag transitiveRemediation. I've flipped it on for all public repos in the app on github.com and it's found thousands of additional vulnerabilities it's been able to remediate, so it seems like a success. I'll add npm@7 support and then close this issue. We can/should have individual issues for others with lock files like yarn, bundler, composer.

[cameron-martin]

That's awesome. Does this work for yarn too, or only npm?

[viceice]

Currently only npm < v7

[kunalnagar]

@rarkins I just wanted to check if there's a rough timeline on yarn support for the transitiveRemediation flag? I couldn't find any active PRs around this at the moment 🤔

[The-Code-Monkey]

Do we have a timeframe for updating the yarn lock file dependencies for security reasons?

[viceice]

Idea:

Run a forced lockfile maintenance for managers which support it and has transitive dependency security issues?

@rarkins WDYT?

[rarkins]

That could often fix transitive vulnerabilities although not always. Anyway, can be useful.

[milind009]

Hi @rarkins , does renovate have the capability to update specific version of a dependency in case there are multiple versions for a dependency present in the lockfile. For e.g a repo uses 3 versions for dependency A in its lockfile -> 1.0, 1.1, 1.5. Now there is a vulnerability discovered with dependency A for versions <= 1.1 with secure version being >= 1.5. Will renovate be able to resolve the security vulnerability associated with A in this repo's lockfile and create a PR for it assuming that the current semver constraints allows update of dependency A -> 1.5

[rarkins]

The current approach is supported for npm only, and you are using versions which aren't valid npm versions, so I don't know if we're on the same page or not. The answer is really "maybe". For example I'm not sure that GitHub's alerts would even correctly pick up the situation you're describing anyway, or if they'd just alert for 1.0 or 1.1. If you can reproduce it with an example, I can answer you with more certainty

[khvn26]

Solution for uv: #44262

I focused on uv since it's our primary use case at Flagsmith. I've managed to surface uv's lockfile-only deps so osvVulnerabilityAlerts can match them, and remediate each via uv lock --upgrade-package which bumps a single locked package in place. It seems that the approach will generalise well to other ecosystems supporting targeted lock bumps.