When many products contain a vulnerable component, fix first the ones where the vulnerable code is reachable from untrusted input and the deployment is exposed. Version presence tells you a product is in scope. Reachability, exposure and impact tell you the order.
Three questions per product
- Is the vulnerable code reachable? Does the product call the affected function or feature in a way an attacker can influence?
- Is it exposed? Is the component on an internet-facing path, or deep in an internal batch job?
- What is the impact? Does the product handle sensitive data, or support critical operations for customers?
Answering these takes more time than reading a version number, but the effort concentrates where the risk is.
A simple ordering table
| Reachable | Exposed | Suggested order |
|---|---|---|
| Yes | Yes | First, treat as urgent |
| Yes | No | Second, schedule soon |
| Unknown | Yes | Investigate quickly, treat as reachable until shown otherwise |
| No | Yes | Plan the upgrade, lower urgency |
| No | No | Normal upgrade cycle |
This is a working heuristic, not a standard. Adjust it with your own risk policy.
What reachability can and cannot tell you
Reachability analysis looks at whether code paths in your application can lead to the vulnerable function. It helps cut a long hit list down, and it can support a statement that a product is not affected because the vulnerable code is not in the execute path. The OpenVEX specification lists justifications such as vulnerable_code_not_in_execute_path and vulnerable_code_cannot_be_controlled_by_adversary for exactly these cases.
Reachability is still an analysis with limits. Dynamic loading, reflection and configuration can hide paths. If the analysis result is uncertain, treat it as unknown, not as safe. The related post on VEX and reachability explains how the two fit together.
Steps
- Take the affected product list from your SBOM search.
- Run reachability analysis on each, or review code paths for a short list.
- Record exposure from your architecture notes.
- Apply the table and set an owner and a target date per product.
- Publish VEX statements as verdicts settle: fixed, not affected with a justification, or affected with an action statement.
Keep the unreachable ones on the list
Not reachable today does not mean never. A later feature may call the code. Record the reasoning and set a review date, and still upgrade on the normal cycle.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the full findings list with the reachable subset.
Quick check
Can we skip products where the code is unreachable?
You can lower their urgency, with a recorded reason and a review date, but still plan the upgrade.
What if reachability is unclear?
Treat the product as reachable until you can show otherwise.
Safeguard includes reachability analysis alongside dependency scanning, and autonomous remediation can propose fix pull requests (off by default).
Sources
Last reviewed: 19 October 2026.
