Why CVSS alone isn't enough
A CVSS score describes how bad a vulnerability could be in general. It doesn't know whether the package is in a production image, whether that image runs on an internet-facing server, or whether the server's role can read anything valuable. Thousands of CVEs score 7 or higher, so a severity-sorted list quickly becomes too long to finish.
The signals that matter
- Known exploitation: is the CVE on the CISA Known Exploited Vulnerabilities (KEV) catalog, or does it have a high EPSS score (the estimated chance it will be exploited soon)?
- Exposure: does the affected workload accept traffic from the internet?
- Runtime: is the package actually deployed, or only in a test dependency or an old image nobody runs?
- Blast radius: what can the workload's role reach: sensitive data, other accounts, admin permissions?
- Fix available: is there a patched version, and is the upgrade a patch release or a breaking change?
A practical order
- Exploited or likely-exploited CVEs on internet-facing workloads with access to sensitive data.
- The same CVEs on internet-facing workloads without that access.
- Critical CVEs on internal workloads that sit on an attack path.
- Everything else, on a schedule, starting with fixes that are simple version bumps.
Make the fix cheap
Most CVE fixes are a dependency or base-image upgrade. Opening that upgrade as a pull request, with the right version for each manifest and lock file, takes the work out of it; your CI tests it and your team merges it. Breaking upgrades need a person to decide, and should be flagged as such instead of opened blind.
Connect code to cloud
Prioritizing this way needs both sides: the dependency in the repository and the server it runs on. Linking the two is what lets a CVE on an exposed production server outrank the same CVE in a sandbox. See also attack path analysis.