How should security teams use reachability analysis to prioritize open-source vulnerabilities in software supply chains?

Why reachability analysis changes vulnerability prioritization

Reachability analysis is useful because it turns a long list of open-source findings into a smaller set of defects that can actually influence runtime behaviour. In supply-chain work, that means separating “present in the dependency tree” from “callable from the application path”, which is often the difference between backlog noise and a real remediation item. It is especially effective when paired with SBOM, lockfile, and code-path evidence.

For teams trying to reduce false positives, the key question is whether the vulnerable function, class, or code path is reachable in the shipped build, not whether the package contains a CVE in abstract. That approach is consistent with Reachability Analysis Guide, which focuses on code, runtime, and network reachability, and on documenting outcomes with VEX-style evidence when a flaw is not actually exploitable in the application context.

Reachability also improves decision quality because it preserves developer attention for issues that can affect behaviour, availability, or data exposure. When used well, it supports risk-based software supply chain management rather than raw vulnerability counting. For broader supply-chain governance, the Open Source Security Guide is useful context for how dependency management, SCA, SBOMs, and malicious-package risk fit together.

What evidence should drive the reachability decision?

The strongest prioritisation signals come from combining multiple sources of truth. Manifest and lockfile data tell you what is declared and pinned, but they do not prove execution. Static analysis can show whether a vulnerable function is imported, called, or reachable through a call chain, while runtime evidence can confirm whether that path is actually exercised in the deployed service. None of those signals alone should be treated as definitive.

That is why reachability should be framed as an evidence stack, not a single scanner result. If the package is present but the affected code path is never invoked, the finding may still deserve tracking, but it should usually rank below a defect that is both present and reachable in production. This is where finding correlation matters, and why an ASPM guide is relevant: it explains how to deduplicate findings and use reachability as part of broader application risk prioritisation.

Teams should also be careful about false confidence. Reachability is usually better at reducing noise than proving safety in the absolute. A library may be unreachable in one code path today and become reachable after a small refactor, feature flag change, or new integration. So the output should be treated as a prioritisation signal, not a permanent exemption.

For organisations that want a more operational model, the ASPM Buyer’s Guide covers how to use reachability, deduplication, and vulnerability prioritisation together so the result is actionable rather than merely descriptive.

How to apply reachability without creating blind spots

The practical mistake is to use reachability as a binary pass or fail. A better pattern is to classify findings into tiers: reachable in production, reachable only in test or non-critical paths, and not currently reachable. That lets teams focus on the highest-risk dependencies while keeping lower-confidence issues visible for later review.

It is also important to distinguish between code reachability and exploitability. A vulnerable function can be reachable but still require a second condition such as malformed input, a specific runtime mode, or a privileged caller. Conversely, a defect may appear unreachable in static analysis but still be reachable through reflection, dynamic loading, or configuration changes. Current guidance suggests teams should treat those edge cases as review triggers, not as automatic closure.

When the supply chain itself is the concern, reachability should be combined with provenance and build integrity checks. A dependency that is reachable and untrusted is a much higher-priority problem than one that is reachable but well-governed. For that reason, NIST SSDF (SP 800-218) Guide is a useful companion for tying vulnerability triage to secure build, release, and evidence practices.

Risk and Threat Considerations

Reachability analysis reduces alert noise, but it can also create a false sense of safety if teams treat “not reachable” as permanent. A dependency that is dormant today can become reachable after a feature release, configuration change, or transitive dependency update, which is why supply-chain triage should remain version-specific and build-specific.

Failure mechanism: Static findings miss runtime context, or runtime assumptions drift after refactoring, so a vulnerable component is either over-prioritised when it cannot execute or under-prioritised when a new path makes it reachable.

Impact: Teams waste remediation effort on low-value noise, or they miss the vulnerabilities most likely to affect production behaviour, data handling, or service availability.

Practitioner Guidance

What to prioritise: Start with reachable findings in production code paths that touch externally exposed inputs, privileged operations, or sensitive data flows. Those are the findings where a vulnerable dependency is most likely to matter operationally.

What to verify: Require evidence from at least two layers, such as SBOM or lockfile presence plus code-path or runtime reachability. If the tool cannot show where the vulnerable code is called, do not treat the finding as fully validated for priority purposes.

Common mistake: Do not use reachability to suppress all non-reachable findings automatically. Some should remain on a watchlist because feature flags, dynamic imports, or dependency churn can change the answer quickly.

Practitioner takeaway: The objective is not to eliminate every vulnerability finding, but to sort dependency issues by whether they can actually change application behaviour in the current build and deployment context.

Related resources from NHI Mgmt Group

• Open Source Vulnerabilities
• How should security teams respond when static analysis surfaces critical vulnerabilities in widely used open source software?
• How should security teams secure software supply chains when build systems depend on open-source packages and base images?
• How should security teams use honeytokens in software supply chains?