Third-party code now drives most critical software security debt

At a glance

What this is: This is an analysis of software supply chain risk showing that third-party code and open-source dependencies are now a major source of persistent application security debt.

Why it matters: It matters to IAM practitioners because application supply chains increasingly intersect with secrets, build access, CI/CD permissions, and the identity controls that determine who and what can introduce code into production.

By the numbers:

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

👉 Read Veracode's analysis of the software supply chain challenge

Context

Software supply chain risk is the cumulative exposure created by libraries, packages, build tools, and transitive dependencies that teams do not author directly. In practice, that means security depends on visibility into code provenance, dependency trust, and the identities allowed to publish, approve, or deploy software. For identity and access teams, the adjacent problem is governance over CI/CD credentials, developer privileges, and secrets that make those pipelines usable.

The article's core point is that modern development speed has outpaced manual assurance. Open-source reuse expands attack surface, while hidden dependencies make it difficult to know where risk actually lives. That is not just a code quality issue. It is also an access governance issue, because compromised build paths and exposed credentials can turn dependency risk into production compromise.

Key questions

Q: How should security teams reduce the impact of CI/CD supply chain compromise?

A: Treat build systems as privileged identity infrastructure, not just delivery tooling. Pin dependencies to immutable references, separate build from publish rights, and rotate every secret reachable from the affected pipeline. Then add runtime monitoring for runner behaviour and repository creation so compromise is detected as an identity event, not only as a malware alert.

Q: Why do third-party dependencies create such persistent security debt?

A: Third-party dependencies create persistent security debt because organisations often discover flaws faster than they can replace, patch, or retest them. Dependency sprawl also means one vulnerable component can affect many applications at once. Teams need ownership, prioritisation, and lifecycle tracking, not just detection, to reduce the backlog.

Q: What do security teams get wrong about Software Composition Analysis?

A: The common mistake is treating SCA as a one-time scan of source code. In practice, risk changes as code moves through builds, artifacts, and runtime. Teams that ignore pipeline context and deployment state end up with noisy reports that do not tell them which exposure is actually exploitable.

Q: Who is accountable when a vulnerable embedded component ships in production?

A: Accountability usually spans build engineering, product security, and release management because no single team owns the full chain from source revision to deployed image. Governance works only when one function can answer which artefacts were rebuilt, which products consumed them, and which devices still need replacement.

Technical breakdown

Why transitive dependencies create hidden attack surface

Direct dependencies are the libraries a team intentionally adds. Transitive dependencies are the libraries those libraries pull in, often several layers deep. That nested structure makes software composition difficult to reason about manually, because a vulnerable component can enter the application without being visible in the top-level manifest. Attackers exploit that opacity through dependency confusion, typosquatting, and malicious package publishing. The result is a supply chain where trust is inherited rather than proven, and the true risk profile often remains unknown until after deployment. Practical implication: build dependency inventory and provenance checks into every pipeline stage, not just release review.

Practical implication: build dependency inventory and provenance checks into every pipeline stage, not just release review.

How third-party flaws become long-lived security debt

Security debt appears when a vulnerable component remains in use after it is known to be risky. In third-party code, that debt persists longer because teams do not control the upstream release cycle, and because transitive packages may be hard to locate and replace. The article's 358-day half-life shows that flaws in external code linger substantially longer than other scan types. That delay matters because persistent exposure compounds remediation cost and increases the chance that a known weakness becomes exploitable in production. Practical implication: prioritise automation that can identify, rank, and retire external dependencies before they become embedded debt.

Practical implication: prioritise automation that can identify, rank, and retire external dependencies before they become embedded debt.

Why software supply chain security is also an identity problem

Secure supply chains depend on the identities allowed to access repositories, approve packages, sign builds, and release artifacts. If those identities are overprivileged, poorly governed, or backed by unmanaged secrets, attackers can move from dependency compromise to pipeline compromise very quickly. That is where IAM and NHI controls intersect with application security. Service accounts, tokens, and CI/CD credentials are the identities that make the pipeline work, and they are often the shortest path from code risk to operational impact. Practical implication: treat build and release identities as high-value assets with lifecycle control, not as implementation detail.

Practical implication: treat build and release identities as high-value assets with lifecycle control, not as implementation detail.

Threat narrative

Attacker objective: The attacker wants to turn trusted dependency channels into a scalable route for code execution, data access, or long-term compromise inside production software.

1. Entry occurs when attackers exploit trusted software distribution paths such as dependency confusion, typosquatting, or malicious package uploads.
2. Credential or build access is then abused when pipeline identities, tokens, or secrets allow the attacker to publish, sign, or deploy compromised components.
3. Impact follows when the poisoned component is pulled into production, creating persistent application compromise or downstream breach exposure.

NHI Mgmt Group analysis

Third-party code has become a governance problem, not just a scanning problem. The article shows that most organisations are now living with risk they did not author, but still own. That shifts the burden from vulnerability discovery to dependency governance, including provenance, approval, and lifecycle control. In NHI terms, the same pattern appears when organisations trust secrets, tokens, and build identities without enforcing ownership. The practical conclusion is that software supply chain security must be managed as an access and trust discipline, not a periodic code review.

Dependency sprawl creates a verification trust gap. Teams can see that libraries are present, but not always whether they are trustworthy, still maintained, or coming from the intended source. That gap mirrors broader identity governance failures, where access exists without sufficient context or lifecycle control. For application security teams, SCA and SBOMs are necessary but not sufficient because they do not by themselves prove that the publisher, maintainer, or signing path is trusted. The practitioner conclusion is to pair inventory with provenance assurance and release identity controls.

Build and release identities are now part of the attack surface. The article's supply chain framing becomes more serious once you recognise that CI/CD systems depend on service accounts, tokens, and signing credentials. Those non-human identities can be the bridge between external code risk and internal compromise. This is where OWASP Non-Human Identity Top 10 thinking becomes relevant, especially around secret exposure and overprivilege. The practitioner conclusion is to govern pipeline identities with the same rigor as privileged human access.

Security debt in external code is a lifecycle issue, not a point-in-time defect. A flaw that persists for months is not just a missed detection. It is evidence that ownership, prioritisation, and remediation workflows are not aligned to dependency risk. That is why the longest-lived exposure tends to sit in components nobody feels directly responsible for. The practical conclusion is to assign explicit ownership for third-party package risk and measure remediation as a lifecycle outcome.

Software supply chain assurance will keep converging with identity assurance. The more build systems automate, the more important it becomes to know which identities can publish code, inject secrets, or approve releases. That convergence is already visible in modern development environments where a compromised token can be as damaging as a vulnerable library. The practitioner conclusion is to unify application supply chain controls with IAM, PAM, and NHI governance instead of running them as separate programmes.

What this signals

Dependency trust and secret governance are converging. The more organisations rely on open-source packages and automated pipelines, the more they need identity controls around the systems that fetch, sign, and release code. That is where OWASP Non-Human Identity Top 10 thinking becomes operational rather than theoretical, because pipeline secrets and release identities can no longer be treated as implementation details. For practitioners, the next step is to unify dependency policy with build identity governance.

The practical signal for security programmes is that supply chain resilience now depends on ownership, not just tooling. If a team cannot say who approves a package, who rotates the pipeline credential, and who can promote an artifact, then the programme has a governance gap disguised as a developer productivity issue. The control conversation should move toward provenance, least privilege, and explicit lifecycle responsibility.

As third-party code becomes a longer-lived source of exposure, remediation SLAs should be measured in dependency classes rather than generic application backlog items. That lets teams identify where external libraries, build plugins, and package sources are creating hidden drag on resilience. Programmes that align application security with IAM and NHI governance will be better positioned to reduce both exploitability and operational ambiguity.

For practitioners

• Map direct and transitive dependencies across all critical applications Use software composition analysis to inventory every package, framework, and nested library, then tie each dependency to an owner and an upgrade path. This gives security and engineering a shared view of where external code enters the estate.
• Enforce package provenance before dependency acceptance Require signed or verified package sources, block unexpected publishers, and reject components that do not meet your trust criteria. A package firewall or equivalent control should stop malicious or non-compliant code before developers can pull it into a build.
• Treat CI/CD secrets and service accounts as high-value identities Rotate pipeline tokens, remove standing privileges, and apply lifecycle ownership to build and release accounts. If a compromised package can reach your pipeline, overprivileged build identities can turn that exposure into production compromise.
• Set remediation targets by dependency class, not just by application Track how long third-party vulnerabilities remain open, then prioritise the dependencies that contribute the most persistent debt. Use separate reporting for direct packages, transitive packages, and build tooling so that hidden risk does not disappear into a single backlog.

Key takeaways

• Third-party code is now a primary source of persistent security debt, which makes software supply chain governance a board-relevant risk issue rather than a narrow application security concern.
• The largest failure mode is not just vulnerable code, but opaque trust in dependencies and the identities that move them through build and release pipelines.
• Practitioners should pair dependency inventory with provenance controls, pipeline identity governance, and explicit remediation ownership to reduce long-lived exposure.

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 component that your application uses indirectly through another library. These packages often escape manual review, yet they can introduce the same vulnerabilities, malicious code, or trust problems as direct dependencies. They are a major reason software inventory and provenance matter.
• 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.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step dependency review practices for teams introducing third-party components into software delivery workflows
• Guidance on package firewall and policy-as-code implementation for blocking risky packages before download
• Developer workflow examples showing how SCA, SAST, and DAST can be combined for release decisions
• Measured goals for reducing third-party contribution to critical security debt over a defined time horizon

👉 Veracode's full post covers dependency management practices, layered controls, and developer workflow guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle control to the broader security programmes their environments depend on.