Check four things in order: whether your exact version is in the affected range, whether your code can reach the vulnerable function, whether the preconditions the advisory describes hold in your setup, and whether the flaw is known to be exploited. A yes to all four means fix now.
The four checks
- Version. Compare the installed version, from your lockfile or SBOM, against the affected range. Advisories in the OSV format give introduced and fixed events, so you can tell whether you are inside the range.
- Reachability. Does any path from your entry points call the vulnerable function? A package can be present and the flaw can still be unreachable.
- Preconditions. Many flaws need a specific configuration, input type or feature flag. Read the advisory text for what must be true.
- Exploitation. Is the flaw on CISA's Known Exploited Vulnerabilities list? If so, someone has used it against real systems.
Decision table
| Version affected | Reachable | Preconditions met | Known exploited | Action |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | Fix or mitigate today |
| Yes | Yes | Yes | No | Fix in your normal urgent window |
| Yes | Yes | Unsure | Any | Confirm preconditions, treat as urgent meanwhile |
| Yes | No | Any | Yes | Fix soon, reachability analysis can be wrong |
| Yes | No | Any | No | Schedule the upgrade, document the reasoning |
| No | Any | Any | Any | Close the finding, note the evidence |
Reachable does not mean exploitable, and unreachable does not mean permanently safe. Code changes, and a new entry point can make an unreachable function callable.
Recording the decision
When you decide a finding does not apply, write it down: which check failed, who decided, the date, and what would change the answer. A standard such as VEX exists for sharing these decisions with customers.
Steps to make this routine
- Put versions in an SBOM so check one is a lookup, not a search.
- Use call graph analysis for check two, and spot check the results by reading a few call paths yourself.
- Keep a short precondition note on every finding you triage.
- Pull the exploited list into your triage so check four is automatic.
- Re-run checks when the code changes or new advisory data arrives.
Try it yourself
Open the demo and walk through the checks for a sample CVE. Look at which answer changes the recommended action.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's reachability analysis answers the second check and its SBOM scanning handles the first. You can try both on your own project with the free scan.
Quick check
Is a high CVSS score enough to call a CVE exploitable?
No. CVSS describes severity in general. Exploitability in your application depends on version, reachability and configuration.
Can I ignore a CVE that is not reachable?
You can defer it with a recorded reason and a review trigger. Unless it is on the exploited list, deferral is often reasonable.
Sources
- OSV schema, ossf.github.io/osv-schema (introduced and fixed events).
- CISA Known Exploited Vulnerabilities Catalog.
Last reviewed: 19 October 2026.
