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.