Yes. A vulnerable dependency can sometimes remain in place if the vulnerable code path is unreachable, the package is isolated, or a compensating control blocks exploitation. Common examples are dead code, optional features that are disabled, or a library present only for build time. The decision should be based on reachability, exposure, and compensating controls, not the CVE alone.
When a vulnerable dependency is not automatically a remove-now problem
A vulnerable dependency can sometimes stay in place when the vulnerable code path is genuinely unreachable, the component is isolated from the trust boundary that matters, or another control blocks exploitation. The key question is not whether a CVE exists, but whether the vulnerable behaviour can actually be reached and abused in your environment.
That distinction matters because many dependency findings are broader than the real exposure. A package may be present for build time only, a feature may be compiled but disabled, or the vulnerable function may never be invoked by the application’s actual inputs. In those cases, the remediation decision should be driven by reachability, exposure, and compensating controls rather than a blanket “every vulnerable package must be removed immediately” rule. See the Software Composition Analysis (SCA) Guide for how reachability, KEV prioritisation and VEX-style decisions fit together.
That does not mean the finding should be ignored. It means you need evidence that the dependency is not on an exploitable path, and you need a decision record that explains why leaving it in place is acceptable for now. Where the dependency sits inside a broader software supply chain risk pattern, the Open Source Security Guide and the Software Supply Chain Security Guide are the right references for managing dependency risk, provenance, and vulnerability handling as part of the release process.
How to decide whether the dependency is truly exposed
Start by tracing the vulnerable component from the application entry point to the affected function. If no request, job, plugin, parser, or internal call can reach the vulnerable code, the practical risk is lower than the scanner result suggests. That is especially common with optional modules, dead code, libraries that are loaded but unused, and packages that only support build, test, or development tasks.
Then test the surrounding assumptions. An unreachable path can become reachable after a feature flag change, configuration drift, dependency update, or deployment change. Likewise, a package that is “safe” in one environment may become exposed in another if the same artifact is reused across tiers. If the dependency is part of a broader open source stack, confirm the situation against the project documentation and package management guidance from OpenSSF.
Isolation also matters. A dependency that exists only in a build container, a sandbox, or a non-production toolchain may be acceptable to defer if the environment is tightly controlled and never processes untrusted input. But isolation must be real, not assumed. If the same package is also deployed into runtime images, shared services, or downstream customer-facing systems, the exposure story changes immediately.
What to do when you choose to leave it in place
If you decide not to remove the vulnerable dependency yet, treat that as a controlled exception, not an informal waiver. Record why exploitation is not currently feasible, which compensating control blocks the path, and what event would invalidate the decision. That gives security, engineering, and release teams a common basis for revisiting the exception when the application or environment changes.
Compensating controls should be concrete. Examples include disabling the vulnerable feature, blocking the relevant input type at the edge, preventing untrusted data from reaching the library, constraining execution through container or host isolation, or removing network access from the component altogether. If the issue is in a third-party package and the upstream project publishes a fix or a safer configuration, the exception should be temporary rather than open-ended.
When the dependency is retained, monitor for environmental changes that could make it reachable later. A package that is harmless today may become exploitable after a code refactor, a new integration, or a build pipeline change. The safest posture is to pair the exception with a defined review trigger, such as a release, architecture change, or new exposure path.
Risk and Threat Considerations
A vulnerable dependency creates a false sense of safety if teams treat “installed” as the same as “exploitable.” The real risk is that reachability, configuration drift, or a later code change can silently turn a dormant issue into a live one. That is why dependency exceptions should be precise and time-bound.
Failure mechanism: The vulnerable code becomes reachable through a new feature, input path, deployment context, or build/runtime mismatch, at which point the original scanner finding becomes an active attack path.
Impact: Exploitation can lead to remote code execution, data exposure, service disruption, or a larger supply chain compromise if the dependency sits in a widely reused component or build process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8, SLSA, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Reachability and dead-code decisions depend on secure design and component exposure. |
| Recommendation — Design away unused vulnerable paths and verify they cannot be reached in production. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Dependency exceptions require prioritisation, tracking, and review of real exposure. |
| Recommendation — Track vulnerable dependencies by exploitability and review exceptions until exposure is removed. | ||
| SLSA | SLSA — Supply chain integrity | Build-time-only dependencies and provenance affect whether a vulnerable package matters at runtime. |
| Recommendation — Separate build-time components from runtime artifacts and verify provenance before release. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity checks | Integrity-focused controls help validate whether a dependency or artifact has changed unexpectedly. |
| Recommendation — Check that artifacts and dependencies remain intact across build and deployment stages. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Known vulnerable dependencies require controlled remediation or documented exception handling. |
| Recommendation — Remediate vulnerable components or formally manage accepted exceptions with review triggers. | ||
Practitioner Guidance
What to verify: Prove that the vulnerable function is unreachable in the deployed state, not just in source code. If you cannot demonstrate that with code review, runtime configuration, or test coverage, treat the dependency as exposed.
Decision rule: If the vulnerable package can process untrusted input, reaches production runtime, or has a realistic path to become reachable, prioritise removal or upgrade. If it is build-only, feature-disabled, or effectively isolated, a documented exception can be justified until the next planned change window.
What to measure: Track exception age, affected application tier, and whether the dependency is tied to runtime or non-runtime use. Exceptions that persist across multiple release cycles deserve escalation because the chance of future exposure rises over time.
Practitioner takeaway: A vulnerable dependency is only “safe” when you can show why exploitation is not possible in the current deployment, and why that remains true as the system evolves.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org