You know a vulnerability is exploitable when you have evidence at one of four levels: the vulnerable code is reachable in your app, the flaw is being exploited in the wild, a probability score says it is likely, or a tester has exploited it. Each level is stronger and costs more effort than the last.
Definitions
- Present: the vulnerable component is in your software. A scanner can tell you this.
- Reachable: your code actually calls the vulnerable function or path. Reachability analysis estimates this.
- Exploited in the wild: attackers have used it against real targets. CISA's Known Exploited Vulnerabilities catalog lists such flaws and says organizations should use it as one input when setting priorities.
- Likely: a model estimates the probability. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days.
- Proven: someone exploited it against your system. NIST notes the attack phase of a pen test exploits a vulnerability to confirm it.
The evidence ladder
| Level | Question answered | Effort | Strength |
|---|---|---|---|
| Present | Do we ship the affected version? | Automated | Weak |
| Reachable | Can our code reach it? | Automated, deeper | Medium |
| Exploited in the wild | Are attackers using it? | Lookup | Medium to strong |
| Likely | How probable is exploitation? | Lookup | Medium |
| Proven | Did a tester break in? | Manual | Strong |
Note that "not reachable" is not the same as "safe forever." Code paths change, and an unreachable flaw can become reachable after a refactor.
How to use the ladder
- Start with every present finding. Do not stop here, because presence alone drives most alert noise.
- Check reachability. Set aside unreachable ones, with a note and a recheck date.
- Check for exploitation in the wild. Anything on the KEV list moves to the front of the line.
- Check the probability score for the rest.
- Reserve manual exploitation for the few items where the call is hard or the stakes are high.
- Record the evidence level in the ticket so reviewers can see why you chose that priority.
Where people go wrong
- Treating a base severity score as a verdict. FIRST's guide says base scores are severity, not risk.
- Dismissing everything unreachable without recording it.
- Asking a tester to prove every dependency finding, which is slow and expensive.
Try it yourself
Open the demo and watch how reachability analysis reduces a long list to the findings your code can reach. Compare the list before and after.
Click through it at your own pace, or open it full screen.
Quick check
Is an unreachable vulnerability safe to ignore?
It can be deprioritized, with a note and a recheck. Code changes can make it reachable later.
Is a high EPSS score proof of exploitation?
No. It is a probability estimate for the next 30 days, not proof that the flaw works against your system.
Safeguard provides reachability analysis with SBOM and dependency scanning, so you can filter by whether your code reaches the flaw. Try the free scan.
Sources
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS
- FIRST CVSS v4.0 user guide
- NIST SP 800-115 full text (PDF)
Last reviewed: 19 October 2026.
