Score a finding red if it is exploited, reachable and unfixed in something customers rely on, yellow if it is real but contained or has a dated plan, and green if it is fixed, unreachable or not applicable. Use the same four questions every time: exploited, reachable, owned, and fixable.
Why a rubric helps
In a deal, reviewers produce long lists. Without a shared rule, one person's high is another's medium, and the debate eats the calendar. A rubric does not remove judgement. It makes the judgement visible and repeatable, so the negotiation is about facts.
The four questions
- Exploited? Is it listed in CISA's Known Exploited Vulnerabilities catalog, or is there other credible evidence of exploitation?
- Reachable? Can the product's own code actually trigger it, or is the package present but unused?
- Owned? Is there a named person and a date?
- Fixable? Is there a patched version, a workaround or a replacement?
The rubric
| Colour | Criteria | Typical action |
|---|---|---|
| Red | Exploited or clearly exploitable, reachable, no owner or no plan | Fix or mitigate before signing, or reflect in terms |
| Yellow | Real but contained, or planned with a date and owner | Track in the integration plan |
| Green | Fixed, not reachable, or not applicable, with a note saying why | Record and move on |
A finding can move. Yellow with a missed date becomes red. Red with a verified fix becomes green.
Examples without names or numbers
- A package listed in KEV, called in the login path, with no fix applied: red.
- A vulnerable parsing library only used in an internal test tool: green, with a note.
- An end of life framework with no known exploit but no support: yellow, with a replacement plan.
- A leaked credential that was rotated and logged: green. One still live: red.
Process tips
- Score in pairs, one engineer and one reviewer, to catch bias.
- Write one sentence of reasoning for every red and yellow.
- Keep greens in the record. Reviewers later want to know it was checked.
- Summarise by count and by theme. Ten yellows about the same weak process is one red process finding.
- Let the target respond before you finalise. Many reds turn yellow with context.
Limits
This is a triage tool, not a risk model. It does not price anything, and it says nothing about legal exposure, which belongs with counsel. It also depends on the quality of the underlying scan, so review what a clean report leaves out.
Try it yourself
Open the demo to see reachability filtering split findings into those that matter and those that do not. Notice which ones you would colour red.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis and vulnerability management support this kind of sorting, and a free scan gives you findings to practise on.
Quick check
Should severity scores drive the colours?
Use them as one input. Exploitation and reachability usually change the order more than a base score does.
Who signs off on red findings?
Name an executive owner in advance, so the decision is made on purpose.
Sources
Last reviewed: 19 October 2026.
