How should security teams manage vulnerable open source libraries in third-party dependencies and sub-dependencies?

Why This Matters for Security Teams

Vulnerable open source libraries are rarely a simple “update the direct dependency” problem. Most production risk sits deeper in the chain, where transitive packages are introduced by frameworks, build tools, and plugins that application teams do not review closely enough. That is why inventory, provenance, and runtime exposure matter as much as the vulnerability notice itself. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows how quickly unmanaged software relationships become identity and access problems, not just patching problems.

This is also where supply chain incidents become operationally noisy. A transitive package can be present in a repository, embedded in a container, or bundled into a deployed artifact long after the team thinks it has “removed” the dependency. The OWASP Non-Human Identity Top 10 is relevant here because vulnerable libraries often expose secrets, tokens, and service credentials that let attackers move from code weakness to identity compromise. In practice, many security teams discover these issues only after a release has already shipped with a vulnerable sub-dependency in production, rather than through intentional dependency governance.

How It Works in Practice

The operational answer starts with complete software inventory, then extends to dependency graph analysis that includes direct, transitive, and build-time packages. Security teams should not stop at package manifests. They need software composition analysis, lockfile inspection, container image scanning, and release artifact review so they can see what is actually deployed. For prioritisation, current guidance suggests using a mix of severity, exploitability, reachability, and deployment exposure rather than CVSS alone. The NIST Cybersecurity Framework 2.0 supports this risk-based approach by tying asset visibility to protective action.

In practice, the workflow should answer four questions quickly: Is the vulnerable library reachable from the internet-facing code path? Is it loaded in a production workload? Does the known fix exist in an upstream release? Can the team ship that fix without breaking compatibility? For identity-heavy systems, vulnerable libraries are often dangerous because they can expose secrets or help attackers intercept tokens. NHIMG’s The 52 NHI breaches Report and Top 10 NHI Issues both reinforce that weak visibility and poor secret hygiene turn a library flaw into an identity incident.

• Track direct and transitive dependencies in the same inventory.
• Prioritise packages that are reachable from production paths or exposed services.
• Use release tracking so the moment a fixed version exists, patching can move through change control.
• Rebuild and redeploy artifacts after updates, because patching the source tree alone is not enough.
• Watch for secret leakage in dependency exploit paths, not just remote code execution.

These controls tend to break down in polyglot monorepos with shared build pipelines because ownership, version pinning, and deployment evidence are spread across multiple teams and artifact types.

Common Variations and Edge Cases

Tighter dependency control often increases release overhead, requiring organisations to balance faster patching against build stability and developer throughput. That tradeoff matters most when a fix is available upstream but not yet compatible with a pinned framework version. Best practice is evolving, but there is no universal standard for this yet: some teams allow temporary exceptions with compensating controls, while others enforce emergency upgrade paths for internet-facing workloads.

Containerised and serverless environments create another edge case because the vulnerable package may be present in a base image, a transient build step, or a function layer that no application team directly owns. In those cases, the security team should verify the effective runtime bill of materials rather than relying on source control alone. The NHI lens matters again because vulnerable dependencies often become the route to service account theft, token abuse, or supply chain tampering. The LiteLLM PyPI package breach and Shai Hulud npm malware campaign are clear reminders that dependency compromise is often also credential exposure. This guidance is strongest when teams can rebuild rapidly and verify reachability; it becomes less effective in legacy systems with frozen dependencies and no reliable deployment inventory.

Related resources from NHI Mgmt Group

• How should security teams manage third-party non-human identities in supply chain environments?
• How should security teams manage third-party cyber risk in practice?
• How should security teams manage third-party access in a TPRM programme?
• How should security teams manage third-party vendor risk across external applications?