Why do SBOMs and VEX need reachability data before teams prioritise remediation?

Why reachability changes the meaning of an SBOM finding

An SBOM tells you a component is present, but presence alone does not tell you whether the vulnerable code path is reachable from an attacker-controlled input or an operational workflow. Reachability turns a software inventory into a prioritisation signal, because it separates dormant exposure from code that can actually influence production behaviour.

Without that extra context, remediation teams often treat every disclosed dependency as equally urgent. That creates noise, slows patching, and can push attention away from the smaller set of issues that can really be exercised in the product’s current configuration.

When teams can trace a dependency to a callable function, enabled feature, exposed endpoint, or executed path, they can decide whether the vulnerability is hypothetical, conditionally exposed, or immediately actionable. That distinction matters more than the raw presence of a CVE in a manifest.

Why VEX still needs reachability to be decision-grade

VEX is meant to tell you whether a known vulnerability affects a product, but that statement is only strong when it reflects the product’s actual code paths and deployment state. A vulnerability may exist in a library and still be non-impacting if the affected routine is never invoked, is compiled out, or is unreachable in the deployed service.

Reachability data gives VEX the technical backing it needs to support remediation decisions. It helps separate “present but not exploitable here” from “present and reachable in this build, environment, or feature set,” which is the difference between useful triage and optimistic guesswork.

That is why VEX works best as part of a chain of evidence, not as a standalone label. If the supporting analysis does not show how the vulnerable code could be exercised, teams should treat the conclusion as provisional rather than final.

How reachability prevents bad prioritisation across engineering and security

Prioritisation gets distorted when teams only look at inventory or scanner output. A component with a high-severity issue may deserve less immediate attention than a lower-severity issue that sits behind an exposed, reachable path on a critical service.

Reachability helps teams rank by exploitability, business exposure, and operational context instead of by abstract severity alone. That means remediation can focus on what is actually reachable in production, while non-reachable issues are queued appropriately, documented, and revisited when code paths or deployment conditions change.

For supply-chain governance and open-source risk management, this is the difference between counting vulnerable components and managing real exposure. Guidance from the OpenSSF ecosystem reinforces the value of software supply-chain visibility, while a practical AI supply-chain example of manifest-style inventory can be seen in NHIMG’s AI Supply Chain Security and AI-BOM Guide.

Risk and Threat Considerations

The main risk is wasted remediation capacity, but the deeper problem is false confidence. If teams assume a vulnerability is harmless without checking reachability, they can miss the one path that is exposed in production and leave a real attack surface untouched.

Failure mechanism: Inventory data, advisories, and generic VEX statements can overstate or understate exposure when they are not tied to the actual code path, build, feature flag, or deployment context.

Impact: Security teams may deprioritise a reachable flaw, or spend time fixing an unreachable one, which delays meaningful risk reduction and increases the chance that a business-critical issue stays open.

Practitioner Guidance

What to verify: Confirm that the reachability analysis is tied to the shipped artifact, not just the source tree or a theoretical call graph. If a feature is disabled in production, the code path is dead in practice even if the vulnerable function exists in the repository.

Decision rule: If a vulnerability is both reachable and exposed in a critical workload, treat it as a real remediation candidate even when the SBOM only shows indirect dependency presence. If it is not reachable in the deployed configuration, document the reason and keep monitoring for configuration drift.

What practitioners underestimate: Reachability is not just a security refinement, it is a triage control. It helps engineering teams spend less time debating severity scores and more time fixing the issues that can actually be exercised.

Practitioner takeaway: SBOMs tell you where to look, VEX helps you narrow the candidate set, and reachability tells you what is worth fixing first because it can be hit in the real product path.

Related resources from NHI Mgmt Group

• Should teams prioritise recursive SBOMs before automated remediation?
• How should security teams prioritise remediation when vulnerability data comes from endpoint telemetry instead of a separate scanner?
• How should security teams prioritise data remediation when policy violations are widespread?
• How should security teams validate whether CTEM exposures are actually exploitable before they prioritise remediation work?