Dependency presence answers whether a vulnerable component exists in the build. Code-path reachability answers whether the application actually calls the vulnerable function in that component. The second test is more precise because exploitability depends on execution path, input flow, and invocation context. For SCA teams, reachability is the better basis for prioritising remediation and reducing false positives.
Why dependency presence and reachability answer different security questions
Dependency presence is a bill of materials question: does the build include a component with a known vulnerability? Code-path reachability is an exploitability question: can the running application actually invoke the vulnerable routine under realistic conditions? That distinction matters because a listed dependency may never be called, may be behind dead code, or may require inputs the application never accepts.
For software supply chain security, presence tells you where exposure may exist, but reachability tells you where that exposure can become a practical defect. A component can be present in a repository, package lock, or container image and still not change the runtime risk if the vulnerable function is unreachable from the application’s execution flow.
Why reachability is the better prioritisation signal
Reachability improves remediation triage because it connects component inventory to actual execution context. That means teams can separate “interesting but inert” findings from issues that can be exercised through real code paths, data flow, or dependency invocation. It also reduces false positives, which is critical when SCA is producing large volumes of dependency alerts across many builds and services.
In practice, reachability is strongest when it is backed by static analysis, call graph inspection, unit or integration test evidence, or other traceable proof that the vulnerable function can be invoked. It is weaker when it is inferred from package metadata alone. The goal is not to ignore presence, but to use presence as an inventory layer and reachability as the prioritisation layer.
For supply chain programmes, this is the difference between “we have the vulnerable library” and “we have a vulnerable execution path that matters in this deployment.” The second statement is the one that should drive patch timing, exception handling, and risk acceptance.
How to apply both tests without losing signal
Use dependency presence to maintain coverage: it answers whether a vulnerable version exists anywhere in the estate. Then apply reachability to rank the findings that deserve immediate action. That sequencing is especially useful when a dependency appears in multiple products, only some of which expose the risky function, because a single version finding can map to very different exploitability outcomes across applications.
If you need a broader supply chain benchmark for where this kind of exposure shows up in practice, NHIMG’s Ultimate Guide to Non-Human Identities notes that 30.9% of organisations store long-term credentials directly in code, which is a reminder that software inventories and runtime exposure often intersect with secret handling. For build integrity and dependency assurance, the most useful external references are SLSA and NIST SSDF (SP 800-218), because both help teams improve provenance and secure development controls around the software that enters the pipeline.
Risk and Threat Considerations
Dependency presence without reachability can still create operational noise, but the greater risk is the opposite mistake: assuming every vulnerable dependency is equally exploitable. That leads to patch queues that ignore actual attack paths and can distract teams from the few findings that expose real runtime abuse opportunities.
Failure mechanism: Attackers care about whether the vulnerable code is invoked with controllable input, not whether the package merely exists in the tree. If the call path is reachable, the dependency can become an abuse point even when the vulnerable version is only one of many transitive components.
Impact: Reachability-aware prioritisation helps teams focus on defects that can realistically be triggered in production, reducing false positives while improving time to remediate the findings most likely to matter in an exploit chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Controls secure software and dependency risk management for supply chain exposures. |
| Recommendation — Prioritise remediation using application security evidence, including exploitability and code-path reachability. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Covers secure development and software integrity practices that shape dependency exposure management. |
| ID.RA — Risk Assessment | Supports risk-based triage of findings by actual exploitability and business impact. | |
| PR.AC — Access Control | Relevant where reachability depends on whether code paths are exposed through inputs and execution context. | |
| Recommendation — Use software integrity procedures to distinguish inventory exposure from actionable vulnerability paths. Rank vulnerable dependencies by reachable attack paths and practical impact. Restrict exposure paths so vulnerable routines are not reachable from untrusted inputs. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Exposure | Supply chain findings often intersect with exposed secrets in code and dependencies. |
| NHI-05 — Overprivilege and Excessive Permissions | Excessive permissions increase the impact when a reachable vulnerable path is abused. | |
| NHI-09 — Supply Chain and Third-Party Risk | Directly addresses dependency trust and software supply chain exposure. | |
| Recommendation — Search dependency and build artefacts for embedded secrets that turn inventory findings into active exposure. Reduce permissions so any reachable dependency flaw has a smaller blast radius. Validate third-party components and prioritise those whose vulnerable code is actually reachable. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Included only because exposed secrets and invocation context can alter trust in software actors. |
| AAL — Authenticator Assurance Level | Relevant when dependency compromise could affect authenticators or token handling. | |
| Recommendation — Use stronger assurance where software components or secrets materially affect authentication trust. Protect authenticator handling paths that could be abused through reachable code. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Models adversary behaviour in compromised dependencies and build ecosystems. |
| Recommendation — Map dependency findings to supply-chain compromise techniques and hunt for exposed execution paths. | ||
Practitioner Guidance
What to verify: Treat reachability as a claim that needs evidence. Confirm which endpoints, jobs, libraries, or test paths actually invoke the vulnerable function, and be wary of findings that rely only on package-level presence or generic transitive exposure.
Decision rule: If the dependency is present but the vulnerable code path is not reachable in the deployed configuration, record and monitor it rather than escalating it above a reachable issue. If the path is reachable and the inputs are attacker-influenced, prioritise it even when the package sits deep in the dependency tree.
Practitioner takeaway: Presence tells you where to look, but reachability tells you what to fix first, and that distinction is what keeps supply chain remediation aligned with actual exploitability.
Related resources from NHI Mgmt Group
- What is the difference between code provenance and an SBOM for software supply chain security?
- What is the difference between protecting source code and protecting the build pipeline in software supply chain security?
- What is the difference between SaaS supply chain security and software supply chain security?
- What is the difference between code-level bugs and software supply chain failures?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
