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?