Prioritize by filtering first and ranking second. Remove findings that cannot apply to you, promote anything with evidence of exploitation, then rank what remains by exploit likelihood and impact on the asset. Sorting by severity alone mixes all three jobs together and buries the issues that matter.
Why order matters
Ranking thousands of findings by one score treats a critical flaw in unused code the same as a critical flaw in your login path. Filtering first shrinks the list, so the ranking step works on fewer, more relevant items.
The four steps
Step 1: filter out what cannot apply. Ask whether the component is shipped, whether the vulnerable code can be reached, and whether the advisory is still valid. Development-only packages and unreachable code are typical removals. Record why each was removed, so the decision can be audited.
Step 2: promote confirmed exploitation. Check each remaining finding against the CISA Known Exploited Vulnerabilities catalog. Each entry shows a date added and a due date. CISA's own SSVC decision model uses exploitation status as its first input, alongside technical impact, whether exploitation is automatable, mission prevalence and public well-being impact, and it outputs one of four decisions: Track, Track*, Attend or Act.
Step 3: rank the rest by likelihood. EPSS estimates the probability of exploitation in the next 30 days on a 0 to 1 scale, refreshed daily. Use it to order findings that are not in KEV.
Step 4: weigh impact and exposure. Combine severity with where the asset sits: internet-facing, holding sensitive data, or internal and isolated. FIRST states that EPSS lacks your context, so this step is yours.
The result as a queue
| Tier | Rule | Typical handling |
|---|---|---|
| Urgent | Known exploited, reachable, exposed | Fix now, outside the normal cycle |
| High | High likelihood or high impact, reachable | Next sprint |
| Planned | Moderate on both | Regular maintenance |
| Tracked | Unreachable or low on both | Revisit when data changes |
Resist inventing too many tiers. Four is enough for most teams, and each needs a clear service target that your own policy defines.
Common mistakes
- Using severity as the only input.
- Treating a missing score as zero.
- Never revisiting "tracked" items, even though exploit data changes daily.
- Skipping the record of why something was deprioritized.
For how the three public signals relate, read the prioritization guide.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through an exploitability check and notice which questions remove a finding and which move it up.
Where Safeguard fits
Safeguard applies reachability analysis to cut findings that cannot be triggered and lets policies and gates enforce your priority rules. A free scan shows how that looks on a real project.
Quick check
Should I ever fix a finding that is not reachable?
Sometimes. Code paths change, so unreachable findings should be tracked and rechecked. Cheap upgrades can simply be done anyway.
Is KEV enough on its own?
No. It is a strong promotion signal, but it covers only a subset of vulnerabilities. Use it with probability and context.
Sources
Last reviewed: 19 October 2026.
