Risk-based prioritization
Risk-based prioritization decides which vulnerability to fix first and by when. It combines public signals, such as whether a vulnerability is being exploited and how severe it would be, with local facts: whether the vulnerable code ships, whether an attacker can reach it, and what the system is worth.
A CVSS score says how bad a successful exploit would be, not whether anyone is exploiting it or whether it can reach your code. Sorting by score alone sends a team after a 9.3 on an internal batch host while a 6.5 on an internet-facing admin console in CISA's Known Exploited Vulnerabilities catalog waits. A written policy gives every finding the same answer and a due date someone owns.
- Who
- AppSec or the PSIRT owns the policy; service teams apply it at triage and own each fix
- When
- At triage of every confirmed finding, and again whenever a signal changes, such as a new KEV listing
- How often
- Per finding, with public signals refreshed daily and the policy reviewed against real fix times, often each quarter
- You end up with
- Each finding with its signals, a policy row, an owner and a due date, plus a list of overdue findings by owner
Do this
Collect the public signals
For each finding, record whether the CVE is in the CISA KEV catalog, its EPSS probability with the score date, the CVSS 4.0 vector with its label (CVSS-B, -BT, -BE or -BTE) and source, and the SSVC values CISA adds to many CVE records: Exploitation, Automatable and Technical Impact. Store where and when you read each one, because KEV and EPSS change after you triage.
Add the local facts
Confirm the vulnerable version is in the artifact you deploy, not only in a lockfile. Then record whether attacker-controlled input can reach the vulnerable code, whether the asset is publicly exposed (reachable by unauthenticated or untrusted parties over a public network such as the internet, as CISA BOD 26-04 defines it) and the asset's tier. Treat unknown exposure or reachability as yes.
Write a decision table
Map the signals to an action and a deadline in a short, versioned policy. CISA BOD 26-04, binding only on US federal civilian agencies, is a well-documented model: 3, 14 or 60 calendar days, or the next scheduled upgrade, set by exposure, KEV status, automatability and technical impact. Put confirmed exploitation first, and never multiply EPSS by CVSS: FIRST says the product has no interpretable meaning.
Assign an owner and start the clock
Assign each finding to the team that owns the service, and start the clock when the finding is confirmed and assigned. For an exploited vulnerability in a component, start at the earlier of the KEV listing and detection on your asset. Give triage its own target, for example 2 business days, so routing delays stay visible instead of eating into the fix time.
Mitigate when the fix has to wait
When no fix exists or it cannot ship by the due date, apply a temporary mitigation, such as a feature flag or a WAF rule you have tested against the attack; SSDF task RV.2.2 lists this as a risk response. Record it with an owner and an expiry. Route anything else that will miss its date to an exception with a risk owner, a compensating control and an expiry (Exceptions and metrics).
Re-run on change and report what is late
Re-run the table when KEV, EPSS, the advisory or the deployment changes, and keep the earlier due date. Each week, list overdue findings by owner. Each quarter, report attainment as findings fixed on time out of all findings due in the period, counting still-open ones as missed, and compare your deadlines with how long fixes actually take.
Done when
Each confirmed finding has an owner and a due date from a written policy, and overdue findings are visible.
Mark it in the gap checkCommon mistakes
- Sorting by the CVSS Base score alone. A CVSS-B number already assumes active attack against a high-value asset, because missing Threat and Environmental metrics default to the worst case.
- Reading a low EPSS score, or absence from KEV, as safe. KEV lists only exploitation CISA has confirmed, and FIRST advises prioritizing a KEV-listed CVE regardless of its EPSS score.
- Waiting for an NVD score. Since 15 April 2026 NVD has prioritized enrichment and left many CVEs unscheduled, so read the CNA's vector in the CVE record, CISA's enrichment, OSV or GitHub advisories.
- Letting "unreachable" become permanent. A reachability result covers only the code, configuration and entry points examined; reopen the decision when any of them changes.
- Publishing deadlines teams cannot meet. A target most teams miss teaches them to ignore it, so check it against last quarter's real fix times before you publish.
Which signal answers which question?
No single number answers all of them. Record each signal with its source and date, and let the decision table combine them.
| Signal | Answers | Cannot tell you |
|---|---|---|
| CISA KEV | Exploitation in the wild has been confirmed | Exploitation CISA has not confirmed |
| EPSS (FIRST) | Probability of exploitation in the wild in the next 30 days, published daily | Your inventory, exposure or compensating controls |
| CVSS 4.0 | How bad a successful exploit would be, under stated assumptions | Whether anyone is exploiting it |
| SSVC decision points | Exploitation status, whether attacks can be automated, and technical impact | Your mission and safety impact, which you assess |
| Local facts | Whether the code ships, whether an attacker can reach it, and what the asset is worth | Nothing public has these; only your inventory does |
Tools and guides
- Workflow: Respond to a vulnerability
- Tool: CVSS v4.0 calculator
- Prioritize vulnerabilities by exploitation, exposure and impact
Rank vulnerabilities with CISA KEV, EPSS, CVSS 4.0 vectors and SSVC decision points, adjust for presence, reachability and asset value, and turn the result into due dates. Covers NVD's 2026 enrichment changes and CISA BOD 26-04.
- Set remediation SLAs and measure AppSec outcomes
Set vulnerability SLAs by exploitation and exposure, route misses through expiring exceptions, and measure the program with cohort-based, censoring-aware metrics that resist gaming.
- Approve, expire and measure security exceptions without hiding risk
Keep temporary acceptance separate from remediation and measure outcomes using definitions that survive changing visibility.
Standards
- NIST SSDF 1.1
- RV.2 Assess, Prioritize, and Remediate Vulnerabilities
- OWASP SAMM 2
- Defect Management
Sources
- CISA: Known Exploited Vulnerabilities Catalog
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk. 10 June 2026.
- FIRST: Exploit Prediction Scoring System (EPSS)
- FIRST: Using EPSS
- FIRST: CVSS v4.0 Specification Document. Document version 1.2.
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
- CISA Vulnrichment: ADP enrichment of CVE records
- NIST: NIST Updates NVD Operations to Address Record CVE Growth. 15 April 2026.
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1 (RV.2). February 2022.
- OWASP SAMM: Defect Management, Defect Tracking stream