Apply exploit evidence first, reachability second and asset context third. Reachability answers whether the vulnerable code can run in your application, so it can remove findings. Asset context then orders what remains by exposure, data and business role. Doing it the other way round wastes effort labelling assets for findings that do not apply.
Two different questions
Reachability asks about the code: is the vulnerable function actually called, directly or through a dependency chain? Asset context asks about the place: where does this code run, who can reach it and what is at stake?
They do not compete. One filters, the other ranks.
A comparison of approaches
| Approach | What it does well | What it misses |
|---|---|---|
| Severity score only | Fast, consistent | Ignores whether code runs or where |
| Asset context only | Reflects business impact | Ranks findings that may not apply at all |
| Reachability only | Cuts noise sharply | Does not know which system matters more |
| Exploit evidence only | Flags active threats | Silent on newly disclosed flaws |
| All combined in sequence | Removes, then orders | Needs maintained inventory |
Why the order matters
Imagine one hundred findings. If you label assets first, you spend effort deciding that a flaw in a public service holding sensitive data is high priority, only to learn later that the vulnerable function is never called. You ranked something that should not have been on the list.
If you apply reachability first, a share of those hundred findings drops out or moves down, and you rank the rest. The amount that drops varies by application, so measure it on your own code rather than assuming a number.
The recommended sequence
- Exploit evidence. Check whether a flaw is on a list of known exploited vulnerabilities, such as CISA's catalog. These move up regardless.
- Reachability. Is the vulnerable code called in this application? If not, move it down but keep it tracked, since code paths change.
- Asset context. For findings that remain, rank by exposure, data label, criticality, verified controls and owner.
- Severity score. Use it as a tie breaker.
The CVSS v4.0 specification says Threat metrics, such as exploit maturity, and Environmental metrics, such as the importance of the system, can be applied to refine a base score. The same logic runs here, with reachability as an extra filter your own code supplies.
Where the sequence bends
- Exploited flaws on unreachable code. Check carefully. If you are unsure whether the code is reachable, treat it as reachable.
- Reflection or dynamic loading. Static analysis can miss paths where code is loaded by name at runtime. Note where your application does this.
- Shared libraries. A vulnerable function unused by one service may be used by another that shares the library.
- Changing code. A path that is dead today can become live next sprint. Recheck reachability when code changes.
A practical test
Pick one application and compare three lists: findings sorted by severity, findings after a reachability pass, and findings after context ranking. Count how many items you would fix in the first week under each list. The difference is your own evidence for how useful each step is.
What to record
For each finding record the reachability result, the asset context used and the date. When someone asks why a finding was deferred, the answer is in the record.
Where Safeguard fits
Safeguard offers reachability analysis alongside asset discovery, vulnerability management and policies, so both filters can be applied in one place. Safeguard also offers a free scan at gold.safeguard.sh/scan if you want to see your own dependency findings first.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the list before and after the reachability pass, then think about how you would rank what is left.
Quick check
Does reachability replace asset context?
No. Reachability filters findings, and asset context ranks the ones that remain.
Is a finding with unreachable code ever urgent?
If it is known to be exploited and you are unsure of the code path, treat it as reachable until proven otherwise.
Sources
Last reviewed: 19 October 2026.
