Vulnerable means a flawed component is present. Reachable means your code can call the flawed part. Exposed means an attacker can get to the service. Exploitable means someone can actually turn the flaw into harm in your setup. Each word answers a different question, so a good triage asks all four.
The four terms
| Term | Question it answers | Typical evidence |
|---|---|---|
| Vulnerable | Is an affected version installed? | SBOM or lockfile match against an advisory |
| Reachable | Does my code path call the affected function? | Static call graph or runtime trace |
| Exposed | Can an attacker reach this service or input? | Network position, internet facing, authentication |
| Exploitable | Can the flaw be used to cause harm here? | Working exploit, preconditions met, no blocking control |
A scanner can establish the first with confidence. The others take more work, and each one narrows the list.
Why the words get mixed up
Most scan reports list every vulnerable component and label the severity of the flaw. That is a statement about the component, not about your system. CVSS says as much: its base score reflects the intrinsic severity of a flaw, while threat and environmental metrics adjust it for exploit availability and for your environment.
So a "critical" finding can be vulnerable, unreachable and internal only. The word critical describes the flaw in general, and your risk may be lower. It can also be the reverse. A modest score can matter a lot on an exposed, reachable path.
Which signal answers which question
- Vulnerable: advisories and component inventories. Keep an accurate SBOM so this is quick.
- Reachable: call path analysis. A reachable path is evidence that the code can run, not proof that an attacker can control the input.
- Exposed: your architecture. Know which services face the internet and which sit behind other layers.
- Exploitable: exploit evidence and preconditions. CISA's SSVC guide separates none, public proof of concept, and active exploitation as distinct states.
A common mistake
Treating reachable as exploitable. Reachability shows the vulnerable function can be called. Exploitation also needs attacker controlled input, the right conditions, and no mitigating control. Equally, treating unreachable as safe forever is a mistake, since code changes can create new paths. Re-check after significant changes.
Using the four together
Work through them in order, stopping when the answer is no:
- Vulnerable? If not, close the finding.
- Exposed? If the service is internal only, lower the urgency but keep the item.
- Reachable? If not, record the reason (a VEX statement works well) and revisit on change.
- Exploitable? If there is active exploitation or a public exploit, move it to the front.
Try it yourself
Open the demo and walk a finding through the exploitability check. Look at which question removes or confirms it at each step.
Click through it at your own pace, or open it full screen.
Quick check
Is a vulnerable dependency always a risk?
No. It is a candidate. It becomes a risk when your code reaches it, an attacker can get to it, and the conditions for abuse are met.
Can a reachable finding still be harmless?
Yes. If attackers cannot influence the input, or a control blocks the abuse, a reachable path may not be exploitable.
Should unreachable findings be deleted?
No. Record why they were set aside, and re-check when the code changes.
Sources
Last reviewed: 19 October 2026.
