Say you rank findings using several signals: severity, whether the flaw is known to be exploited, the probability of exploitation, whether the vulnerable code is reachable in your product, and how exposed the affected system is. Name the order of precedence and show a sample.
The signals, in plain words
Severity. The base score describes how bad a flaw could be in general. It does not say whether it matters to you.
Known exploitation. CISA maintains its Known Exploited Vulnerabilities catalog as the authoritative list of flaws exploited in the wild, and says organizations should use it as an input to their prioritization framework. An entry here jumps the queue.
Exploit probability. FIRST's EPSS gives a probability from 0 to 1 that a CVE will be exploited in the next 30 days, updated daily. It helps rank the long tail that is not on the exploited list.
Reachability. Does your code actually call the vulnerable function? If not, risk is lower, though not zero, so record the reason.
Exposure. Internet facing, handles sensitive data, or internal only.
A simple precedence you can state
| Order | Condition |
|---|---|
| 1 | Known exploited and present in a shipped version |
| 2 | High severity, high exploit probability, reachable |
| 3 | High severity, reachable, no signs of exploitation |
| 4 | Not reachable or low exposure, scheduled with others |
| 5 | No fix available, mitigate and review on a date |
Adjust to your risk appetite, but write it down. Buyers do not need your exact scoring formula; they need to see that you have a rule and that it is not only the base score.
A model answer
"We prioritise using severity together with known exploitation data, exploit probability, reachability in our code and the exposure of the affected service. Vulnerabilities that are known to be exploited and present in shipped versions are handled first. Deprioritised findings carry a recorded reason and a review date."
Evidence to offer
A policy excerpt, a screenshot of a triage view with the signals visible, and an example finding with the decision recorded.
Caution on reachability
Do not claim reachability analysis eliminates risk. It reduces noise for findings in code paths that cannot run, but it depends on how well the analysis understands your code. Keep deprioritised items under review. For questions to put to any tool, see questions to ask a vendor about reachability claims.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability filtering and note which findings drop down the queue.
Quick check
Is CVSS alone acceptable?
It is a start, but many buyers expect you to add exploitation and context. Say what else you use.
Do we share our scoring model?
Share the principles and precedence. The detailed weights can stay internal.
Safeguard provides reachability analysis and policies that apply these signals, with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
