Ask HN: How do you prioritize dependency updates?
5 comments
This is hard for lots of companies. Some ignore the problem entirely until there's a fire drill (which can be a huge risk if you end up on an old major version that won't get patched). Some keep everything up to date, and then taking a new security patch is trivial. It's always risk/reward tradeoff between the risk of breaking production with an upgrade and the value an org sees from staying up to date. We work on this problem at Infield (https://www.infield.ai/post/introducing-infield) where we tackle both sides of the project management: "Which dependencies should I prioritize upgrading" and "How difficult and likely to break production is this upgrade".
To your specific points
> 1. How do you decide what's actually urgent? CVSS? EPSS? Manual assessment?
The risk factors we track are open CVEs, abandonment (is this package supported by the maintainer?), and staleness (how deep in the hole am I?).
We also look at the libyear metric as an overall indication of dependency health.
> 2. Do you treat "outdated but not vulnerable" dependencies differently from "has CVEs"?
We group upgrades into three general swimlanes:
We offer a Github app that integrates with alerts from Dependabot. While security teams are happy with just a scanner, the engineering teams that actually do this upgrade work need to mash that up with all the other data we're talking about here.
To your specific points
> 1. How do you decide what's actually urgent? CVSS? EPSS? Manual assessment?
The risk factors we track are open CVEs, abandonment (is this package supported by the maintainer?), and staleness (how deep in the hole am I?).
We also look at the libyear metric as an overall indication of dependency health.
> 2. Do you treat "outdated but not vulnerable" dependencies differently from "has CVEs"?
We group upgrades into three general swimlanes:
- "trivial" upgrades (minor/patch versions of packages that respect semantic versioning, dev/test only packages). We batch these together for our customers regardless of priority.
- "could break". These deserve standalone PRs and an engineer triaging when these become worth tackling, if ever.
- "major frameworks". Think something like Rails. These are critical to keep on supported versions of because the rest of the ecosystem moves with them, and vulnerabilities in them tend to have a large blast radius. Upgrading these can be hard. You'll definitely need to upgrade someday to stay supported, and getting there has follow-on benefits on all your other dependencies, so these are high priority.
We offer a Github app that integrates with alerts from Dependabot. While security teams are happy with just a scanner, the engineering teams that actually do this upgrade work need to mash that up with all the other data we're talking about here.
Sounds very interesting solution!
Do you support all the famous programming languages?
Do you also offer prioritasion on the "issues"?
Thanks! We support Python, JS, and Ruby right now (started with dynamic languages).
I'm not sure what you mean by prioritization on the issues, but generally we are trying to help you figure out what to upgrade next, and to actually do it too.
I'm not sure what you mean by prioritization on the issues, but generally we are trying to help you figure out what to upgrade next, and to actually do it too.
Yeah that's exactly what I meant by issues prioritasion, thanks! Do you plan to support PHP or it's totally out of scope?
PHP would definitely be in scope, either that or Java are likely to be next for us. If you are familiar with PHPs ecosystem I'd be interested in your take on what's most important / problematic there.
Dependabot opens 20-30 PRs per week across my repos. Most are minor version bumps, but buried in there are actually critical security issues. I find myself either ignoring them all (risky) or spending hours triaging (unsustainable).
The problem: I don't have a good signal for what's actually urgent vs. what can wait.
What I've tried: - Following CVSS scores → but "critical" doesn't mean "exploitable in my context" - Auto-merging patch versions → missed a few important security fixes - Manual review of everything → takes 5-10 hours/week
I recently discovered CISA's KEV catalog (Known Exploited Vulnerabilities) which flags CVEs that are actively being exploited in the wild. This seems like a better signal than CVSS alone, but I'm curious:
1. How do you decide what's actually urgent? CVSS? EPSS? Manual assessment?
2. Do you treat "outdated but not vulnerable" dependencies differently from "has CVEs"?
3. For those using Dependabot/Renovate/Snyk - what's your workflow? Do you review every alert or have you found a good filtering system?
I'm considering building something to help with this (health score + exploitation-based prioritization) but want to make sure I'm not just solving my own weird problem.
What's working for you?