A modern engineering team runs vulnerability management as a continuous loop: know what you run, rank findings by real world exploitation and exposure, fix on a stated clock, and verify. Severity scores alone are not a plan. Combine them with exploitation evidence and whether your code can reach the flaw.
Why does severity alone fail?
CVSS rates how bad a vulnerability could be under general assumptions. It does not say whether anyone is exploiting it, or whether your system exposes it. A team that sorts by score alone ends up chasing a long list of high scores, most of which will never be attacked, while a medium flaw under active exploitation waits.
FIRST publishes both scoring systems, and they answer different questions. CVSS measures severity. The Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited in the wild. You need both, plus local context.
What signals should you combine?
Known exploitation. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation. A match is a strong reason to move to the front of the queue. CISA sets remediation due dates for US federal agencies for catalog entries, which is a useful benchmark even if you are not bound by it.
Likelihood. EPSS gives a probability that helps order the rest.
Severity. CVSS describes impact if exploited.
Exposure. Is the affected system reachable from the internet, or only inside a segment? Does it hold sensitive data?
Reachability. For libraries, does your code call the vulnerable function? If not, urgency drops.
Constructed example: two findings on Monday
A team has two open items. A library flaw scored 9.8 sits in a package used only by an offline report generator, and the vulnerable function is never called. A second flaw scored 7.5 is in the web framework behind the public login page, and it appears in the KEV catalog.
Sorting by score puts the first at the top. Sorting by exploitation, exposure and reachability puts the second there, and that is the one an attacker will try. The team patches the framework the same day and schedules the library for the next regular release.
What does the loop look like?
NIST SP 800-40 Rev. 4 describes patch management as routine preventive maintenance, with defined maintenance groups, response options and communication. It emphasizes planning for different asset types and having emergency procedures. Translate that into a loop.
- Inventory. Components, versions, owners and exposure for every service. For software, a software bill of materials is the practical record.
- Detect. Scan dependencies, code, containers and infrastructure continuously, not quarterly.
- Prioritize. Apply the signals above and assign a service level objective by category, for example hours for exploited and exposed flaws, weeks for the rest.
- Remediate. Patch, upgrade, mitigate, or accept the risk with an owner and an expiry date.
- Verify. Rescan and confirm the finding is closed.
- Learn. Track recurring causes and fix them in templates and defaults.
How do you keep it sustainable?
Give each service owner its own queue. Automate low risk updates, such as patch version bumps with passing tests. Keep a standing process for emergencies so a KEV match does not wait for a meeting. Measure time to remediate by category, and the share of findings that are reachable, instead of raw counts.
Safeguard combines dependency scanning, reachability analysis and zero-day discovery, and it can open fix pull requests, which are off by default so teams opt in. That covers detect, prioritize and remediate for the software layer.
How to check or apply this
- Build or refresh your inventory, including transitive dependencies.
- Subscribe to the KEV catalog and check new entries against your inventory daily.
- Add EPSS and exposure to your triage view next to CVSS.
- Write service level objectives by category and publish them.
- Define who can accept risk, for how long, and where it is recorded.
- Turn on reachability filtering for dependency findings.
- Review remediation time and recurring root causes monthly.
Quick check
Is a high CVSS score the same as high priority?
No. CVSS measures severity, not whether the flaw is exploited or exposed in your environment. Combine it with exploitation data and context.
What does EPSS tell you?
An estimated probability that a vulnerability will be exploited in the wild, which helps rank findings beyond severity.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System
- FIRST, Common Vulnerability Scoring System
Last reviewed: 18 October 2026.
