Our solution tackles the hurdles and greatly simplifies the process.
- They solve vulnerabilities in indirect dependencies by calculating which version of the direct dependencies contains safe versions downstream
- They can solve vulnerabilities in indirect dependencies without known fixes by finding if a dependency upstream has replaced or removed the vulnerable dependency
Hurdle 1: Vulnerabilities in indirect dependencies
When you import a dependency, that dependency in turn depends on a set of dependencies, which depends on a set of dependencies, and so on – creating a tree of dependencies.
If a vulnerability is introduced a few layers down the dependency tree updating that specific dependency is very likely to introduce breaking changes to the dependencies higher up in the tree. In order to get around this, you need to figure out which version of the direct dependency (that you originally imported) contains a safe version of the indirect dependency that is currently vulnerable.
Debricked’s PRs figure this out for you, relieving you of having to dig through dependency yarn.lock or package-lock.json files to figure out dependency relations.
Hurdle 2: Other dependencies depending on the dependency you want to update
So you worked your way up the dependency tree and figured out what to update in order to get your indirect dependency to a safe version, great! Now do it again 5 more times.
Oftentimes an indirect dependency is used by multiple other dependencies. That means that it’s not enough to figure out which version of a direct dependency contains the safe version of the indirect dependency – you need to find the versions for several direct dependencies that contain a version of the indirect dependency they can all use.
Debricked PRs solve this for you.
How does it work?
There are three main methods of updating dependencies used by Debricked PRs.
When a direct dependency is vulnerable
When a direct dependency is vulnerable, Debricked updates it to the safe version.
If other dependencies depend on it, and the update takes it out of their defined version range, they too are updated to keep them from breaking.
When an indirect dependency is vulnerable but the safe version is within its defined version range
In these cases Debricked locally reinstalls all direct dependencies using their current version. This fetches the latest versions within the dependencies’ defined version ranges, making the risk of breaking changes minimal.
Debricked then updates your lockfiles with the versions found from the local reinstall.
When an indirect dependency is vulnerable and the safe version is outside of its defined range
Here Debricked climbs the dependency tree to find which direct dependencies are dependent on the vulnerable indirect dependency.
Once found we update the direct dependency and see if that either updated the indirect dependency or removed it all together. If not, we increment the version and try again until we’ve found a safe version.
This has the added benefit of fixing vulnerable indirect dependencies without a known fix, if a dependency upstream has removed or replaced it.
This sounds great, how do I start?
If you have an existing account, your GitHub admin will have received an email requesting increased permissions for Debricked’s GitHub App, since we need write access to create PRs. Once the request is approved PRs are ready to use.
If you’re here for the first time and want to create an account you can do so here. PRs are available in all of our tiers – including our free tier!
- Support for more Source Code Managers (We’re already working on GitLab support)
- Support for more languages
- Even better UX
While you can currently open a PR for a specific vulnerability – we will be adding functionality to open a PR to fix all vulnerabilities in a specific dependency or a specific repo. This will reduce the amount of PRs needed to make your repos safe.
What languages and SCMs do you want to see us support? Let us know in the comments, or send an email to firstname.lastname@example.org and let me know personally.