What breaks when vulnerable third-party libraries are only tracked at the dependency list level?

Why This Matters for Security Teams

Dependency lists answer what was declared, not what was actually executed. That distinction matters because vulnerable code can remain dormant in manifests while a transitive package, plugin, or helper library is still loaded at runtime and reachable through an exposed path. The result is a false sense of coverage: teams believe they have remediated a risk, but the attack surface has not changed.

NHI Management Group has repeatedly shown how supply chain exposure becomes operational risk when visibility is shallow. In the 52 NHI breaches Report, the same pattern appears across identity and automation failures: teams know a component exists, but not whether it is still active, trusted, or reachable. That same blind spot shows up in software supply chains when libraries are tracked only at inventory level.

The practical issue is that remediating a named dependency does not always remove the exploitable code path. Security teams need runtime evidence, deployment context, and reachability analysis to separate noise from true exposure. In practice, many security teams discover the real blast radius only after an incident review shows the vulnerable code was never removed, just misclassified.

How It Works in Practice

Effective tracking requires three layers of evidence: declared dependency data, build and deployment data, and runtime reachability. A package may appear in a lockfile, yet never ship to production. Another may be loaded dynamically, fetched at install time, or activated by a feature flag only in certain environments. Treating all of these cases the same creates both over-remediation and under-protection.

Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls supports evidence-based control validation rather than paper compliance. For dependency risk, that translates into:

• Confirming whether the vulnerable library is actually packaged into the released artifact.
• Checking whether the code path is reachable from deployed services, workers, or plugins.
• Verifying whether the vulnerable component is invoked under normal or attacker-controlled input.
• Prioritising fixes for runtime-exposed paths before dormant or unreachable references.

This is especially important for environments with polyglot builds, container layers, serverless functions, and agent toolchains, where the same library may be vendored, duplicated, or loaded on demand. The LiteLLM PyPI package breach and the Shai Hulud npm malware campaign both illustrate how quickly a package-level issue becomes a live exposure when the malicious or vulnerable code is actually pulled into execution. These controls tend to break down when build outputs are decoupled from source manifests because dependency lists no longer match what is running in production.

Common Variations and Edge Cases

Tighter dependency tracking often increases operational overhead, requiring organisations to balance faster remediation against the cost of deeper inspection. That tradeoff is real, because not every vulnerable library is equally urgent. A package with no runtime path in a non-production image should not compete with a reachable dependency embedded in an internet-facing service.

Best practice is evolving toward risk-based prioritisation, but there is no universal standard for this yet. Some teams use software composition analysis only for declared manifests, while others add SBOM correlation, runtime sensors, or reachability tests. The gap usually appears in dynamically loaded code, optional plugins, and build-time dependencies that never ship, where a static list can overstate risk. It also appears in third-party ecosystems where the same package version behaves differently across platforms or feature sets.

For security leaders, the key lesson is simple: dependency lists are a starting point, not proof of exposure. The real decision point is whether the vulnerable code is deployed, invoked, and reachable under realistic attack conditions. If those questions are not answered, remediation priorities will drift toward the wrong assets while the true exposure remains live.

Related resources from NHI Mgmt Group

• What breaks when third-party libraries in SAP stacks are not patched quickly?
• What breaks when a vulnerable third-party component still has broad network and identity access?
• What breaks when cryptographic debt is not tracked across cloud workloads and third-party dependencies?
• What breaks when security tools treat third-party libraries as black boxes?