Third-party code now drives most critical software security debt

At a glance

What this is: Veracode argues that third-party code is now a major source of critical software security debt, with open-source vulnerabilities persisting deep in application dependency chains.

Why it matters: This matters because security and IAM teams must govern software supply chains as an access and trust problem, not only as a code-scanning problem, especially where third-party components and development pipelines expand blast radius.

By the numbers:

• 62% of applications contain vulnerabilities originating from open-source libraries.
• Third-party code is responsible for 66% of the most dangerous, long-lived security debt.
• The half-life of flaws in third-party code is 358 days.

Context

Software supply chain risk is the exposure created when organisations depend on code, packages, frameworks, and build inputs they did not author or fully control. In this article, the primary issue is not just vulnerable code, but the governance gap created when transitive dependencies, package trust, and remediation ownership span multiple teams and release cycles.

The identity angle is real but indirect: developers, CI/CD pipelines, package registries, and build systems all act with credentials, permissions, and trust relationships that can be abused. That makes supply chain security a control problem for security, DevSecOps, and IAM teams together, especially where third-party code enters the software estate faster than governance can inventory it.

Key questions

Q: What breaks when third-party code is not governed before it enters the build pipeline?

A: The control that fails first is trust at intake. Without pre-ingestion checks, malicious or non-compliant packages can enter builds through automated dependency resolution, and downstream scanners only see the problem after the code has already been accepted into the software estate.

Q: Why do third-party library vulnerabilities create longer security debt than first-party flaws?

A: Third-party flaws often depend on upstream maintainer fixes, compatible version releases, regression testing, and coordinated deployment across many applications. That creates a longer remediation chain, so the exposure persists even when the issue is known and documented.

Q: How can security teams measure whether supply chain controls are actually working?

A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.

Q: What is the difference between software composition analysis and an SBOM in open source security?

A: Software composition analysis is an active control that scans code and builds to find open source components, versions, and known vulnerabilities. An SBOM is the documented inventory of those components, including direct and transitive dependencies, versions, licenses, and update status. In practice, SCA discovers risk while the SBOM preserves the authoritative record.

Technical breakdown

Why transitive dependencies change the attack surface

A direct dependency is code a team knowingly adds. A transitive dependency is code pulled in by that dependency, often several layers deep. The operational problem is that the security team may only review the top-level package while the real risk sits in nested components, where malicious code, abandoned libraries, or vulnerable versions can persist unnoticed. This is why manual review breaks down at scale. Software composition analysis, software bill of materials data, and policy enforcement are needed because the attack surface now includes software relationships, not just code lines.

Practical implication: inventory direct and transitive dependencies together, or your risk register will miss the packages most likely to create exposure.

How malicious packages turn routine updates into supply chain risk

Dependency confusion, typosquatting, and package injection exploit the trust developers place in public repositories and automated package resolution. In practice, build systems may fetch an attacker-controlled package because it matches a name or version pattern better than the intended internal component. Once that package enters the pipeline, it can execute during install or build time and spread through normal release workflows. The control failure is not only malware detection, but package admission control and provenance validation before code reaches the developer workstation or CI runner.

Practical implication: gate package intake with repository controls and provenance checks before build systems can resolve or execute untrusted code.

Why third-party flaws become long-lived security debt

Security debt in third-party code persists because remediation depends on factors outside the application owner’s direct control, including upstream maintainer fixes, version compatibility, release timing, and downstream testing. When a vulnerable library sits inside a popular dependency tree, the exposure can survive for months even after detection. That is why the article's 358-day half-life matters: it shows the gap between finding a flaw and actually removing it from production. In governance terms, discovery is not remediation, and visibility is not risk closure.

Practical implication: treat third-party vulnerability aging as a governance metric, not just a scanning metric, and escalate aged findings aggressively.

Threat narrative

Attacker objective: The attacker wants trusted code paths to distribute malicious or vulnerable components at scale so that the compromise reaches many downstream applications.

1. Entry occurs when attackers target public repositories, package names, or dependency resolution paths to insert malicious or counterfeit third-party code into the software supply chain.
2. Credential and trust abuse follow when build systems, developers, or pipelines automatically accept the package, giving the attacker-controlled code execution or downstream access inside the development process.
3. Impact emerges when the compromised component propagates through releases, turning a routine update into widespread application compromise, data exposure, or persistent security debt.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party code is now a governance asset, not just a developer convenience. The article shows that dependency choice directly shapes residual security debt, which means software supply chain governance has to sit alongside application security, procurement, and release management. When 66% of the most dangerous long-lived debt comes from third-party code, the issue is no longer isolated defect management. Practitioners should treat dependency approval, ownership, and lifecycle control as a formal control plane.

Software composition without trust provenance creates a visibility illusion. Knowing what is in a build is not the same as knowing whether it should be trusted. The real governance gap is that transitive dependencies and public package ecosystems can introduce risk long after the original team believes a component has been reviewed. Security programmes need to separate inventory, provenance, and policy enforcement instead of collapsing them into one scanning exercise.

Dependency aging is the most practical measure of supply chain control failure. A flaw that persists for 358 days is not just a vulnerability, it is evidence that remediation workflows, ownership handoffs, or release constraints are broken. That long tail is what turns open-source risk into security debt. The practitioner conclusion is simple: ageing third-party findings should be managed as lifecycle exceptions, not backlog items.

Software supply chain risk and IAM intersect at the point where trust is delegated to machines. Build systems, package registries, and CI workflows operate through service identities and automation credentials, so compromised trust paths can become identity abuse paths. This is where NHI governance becomes relevant: the software supply chain is often a machine-identity problem hidden inside a code problem. Organisations should govern package trust, pipeline permissions, and non-human access together.

Package firewall thinking is becoming a practical control model for modern development. The article's emphasis on blocking malicious or non-compliant packages aligns with a shift from post-download scanning to pre-ingestion control. That matters because the attack is increasingly upstream of the codebase itself. Security teams should design controls that stop unsafe dependencies before they enter the developer and build environment.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Third-party code debt is now a lifecycle issue. Teams that still treat dependency risk as a one-time scan problem will continue to carry unresolved exposure into production. The better model is continuous dependency governance, with ownership for intake, age, and replacement decisions aligned to the release process.

Transitive dependency sprawl is the hidden boundary problem. Once libraries bring in their own dependency trees, the security perimeter moves beyond what a team explicitly chose. That is why machine-readable inventories and package admission controls matter more than periodic manual review.

For identity teams, the key signal is delegated trust. Build pipelines authenticate to registries, package mirrors, and CI services through non-human credentials, so supply chain controls and NHI governance increasingly overlap. Organisations that secure those machine identities reduce the blast radius of poisoned packages and compromised build trust.

For practitioners

• Map direct and transitive dependencies Build a complete inventory of open-source and third-party components across applications, including nested libraries that your primary scanning tools may miss.
• Gate package intake before build-time execution Apply repository and package admission controls so that public packages are validated for provenance, policy compliance, and naming anomalies before developers or CI runners can fetch them.
• Track third-party vulnerability ageing as a governance metric Measure how long vulnerable dependencies remain unresolved, then escalate aged findings through release, owner, and exception workflows rather than leaving them in scan queues.
• Generate and maintain an up-to-date SBOM Use software bill of materials data to support audit readiness, faster impact assessment, and dependency tracing when upstream libraries are patched or compromised.

Key takeaways

• Third-party code now represents a durable governance problem because exposure can persist long after the vulnerable component is discovered.
• The scale signal is clear: open-source libraries account for a large share of application vulnerabilities, and some flaws remain active for nearly a year.
• Security teams need dependency inventories, package admission controls, and lifecycle ownership if they want to reduce software supply chain debt rather than just observe it.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Package Firewall: A package firewall is a control that blocks or screens software packages before they enter a development or build environment. It is used to prevent vulnerable, malicious, or non-compliant dependencies from reaching downstream pipelines where later detection may be too late to reduce risk.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, including the controls that shape trusted automation in modern delivery pipelines. It is designed for practitioners who need to connect identity governance to broader security and release processes.