HACKER Q&A
📣 nrig

How do you prioritize dependency updates?


I maintain several open source projects and dependency management has become overwhelming.

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?

  👤 stevepike Accepted Answer ✓
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:

  - "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.
> 3. For those using Dependabot/Renovate/Snyk - what's your workflow? Do you review every alert or have you found a good filtering system?

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.