TL;DR: Third-party code now accounts for 70% of critical security debt, while breaches exploiting vulnerabilities in third-party code rose 180% in 2024, according to Veracode’s source article and the 2024 Verizon Data Breach Investigations Report. DevSecOps only works when supply chain controls, exploitability checks, and automated remediation are built into the pipeline, not layered on afterward.
At a glance
What this is: This is a DevSecOps supply chain security analysis that argues third-party and open-source code now create most of the critical risk in modern application delivery.
Why it matters: It matters because IAM, PAM, and software teams need governance over dependency intake, provenance, and remediation if they want secure delivery without slowing developers.
By the numbers:
- 70% of critical security debt comes from third-party code.
- Breachs exploiting vulnerabilities in third-party code increased by 180% in 2024.
Context
DevSecOps only works when security controls track the actual software delivery path, including third-party packages, transitive dependencies, and the CI/CD systems that assemble them. When teams treat external code as outside the control boundary, they create a governance gap between first-party development practices and the real attack surface.
The identity angle is indirect but real: build systems, package registries, signing services, and pipeline automations all rely on credentials, tokens, and permissions to pull, verify, and ship software. If those non-human identities are over-privileged or poorly governed, supply chain exposure becomes a credentials and access problem as much as a code problem.
The starting position described here is common rather than exceptional. Many organisations have improved developer security workflows but still struggle to extend the same discipline to dependency intake, exploitability validation, and remediation governance across the full software chain.
Key questions
Q: What happens when software supply chain security is treated as an afterthought in DevOps?
A: When supply chain security is bolted on late, teams usually create blind spots in the very stages attackers target most. Malicious packages can run during build, persistence can be hidden in seemingly harmless artifacts, and remediation becomes slower because ownership is fragmented. The result is more exposure, more rework, and greater risk to release integrity.
Q: Why do third-party dependencies create outsized risk in software delivery pipelines?
A: Third-party dependencies expand the attack surface because they can be compromised, abandoned, or replaced with malicious packages. In modern delivery pipelines, a single poisoned library can reach many applications at once. Risk rises when teams lack a complete dependency inventory, do not verify package authenticity, or fail to patch vulnerable components quickly.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.
Q: How should teams implement software supply chain security across build pipelines?
A: Start by inventorying dependencies, then add provenance checks, secret governance, and continuous remediation evidence at the pipeline level. The goal is to prevent untrusted code and unowned automation from entering production. Teams should measure success by reduced exposure age, fewer risky dependencies, and better traceability across releases.
Technical breakdown
Why third-party dependencies change the DevSecOps control boundary
DevSecOps traditionally embeds testing, scanning, and policy checks into the delivery pipeline, but software supply chain security widens that boundary to include external code, package registries, and transitive dependencies. A library can be safe in isolation and still create risk once it is pulled into a build, repackaged, or called by application logic. The technical issue is not just vulnerability presence, but provenance, trust, and runtime reachability across dependency chains.
Practical implication: extend pipeline controls to dependency provenance, not only source code quality.
How vulnerable methods detection reduces alert fatigue
A dependency scan that flags every known CVE produces noise if the application never calls the flawed function. Vulnerable methods detection adds reachability analysis by tracing whether first-party code actually invokes the risky method in the dependency. That shifts security from theoretical exposure to exploitability, which is the decision point developers and risk owners need. This is especially useful in large codebases where transitive packages create thousands of low-value findings.
Practical implication: prioritise remediation on reachable flaws instead of treating every dependency alert as equal.
Why SBOMs and policy enforcement need to live in the pipeline
A software bill of materials only becomes operational when it is generated continuously and paired with policy decisions on acceptable components, versions, and licences. In practice, that means the SBOM must be current enough to support audits, incident response, and release approvals. Policy enforcement then turns inventory into governance by blocking non-compliant packages, unsupported versions, or unapproved sources before they reach production.
Practical implication: automate SBOM generation and release gating so component risk is controlled before deployment.
Threat narrative
Attacker objective: The attacker aims to get malicious or vulnerable code accepted as trusted software so it can reach downstream environments and users.
- Entry occurs when a malicious or typo-squatted package, compromised repository, or vulnerable transitive dependency is introduced into the software supply chain.
- Credential or trust abuse follows when the pipeline pulls and executes the external component using normal build permissions and automated access paths.
- Impact occurs when the compromised dependency is shipped into applications, creating exploitable paths that can lead to breach, downtime, or remediation cost.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
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 problem, not just a development convenience. Once organisations rely on external packages and transitive dependencies, the security boundary shifts from code authorship to dependency governance. The real question becomes whether teams can prove what entered the build, why it was allowed, and whether it was actually exploitable. Practitioners should treat dependency intake as a controlled identity-and-policy decision for software supply chains.
Exploitability is the control gap that matters most. Many DevSecOps programmes still overreact to library-level CVEs without asking whether application code can reach the flawed method. That creates alert fatigue and weak prioritisation. A more defensible programme centres on reachability, provenance, and policy enforcement, because those controls separate theoretical exposure from material risk.
Software supply chain trust gap: this is the failure mode where organisations assume third-party code is safe once it passes into the pipeline. That assumption breaks when malicious packages, transitive dependencies, or compromised repositories arrive through normal build permissions. The practitioner conclusion is straightforward: trust must be verified continuously, not inferred from package origin.
Build automation now depends on non-human identity governance. CI/CD systems, package managers, and signing services all operate through credentials and tokens that can widen blast radius if over-permissioned. That means supply chain security and NHI governance intersect at the point of build access, verification, and release control. Practitioners should govern pipeline identities as tightly as application identities.
SBOMs are useful only when they drive decisions. Inventory without enforcement does not stop risky code from shipping. The article points toward an operational model where component visibility, policy checks, and remediation automation work together inside the delivery pipeline. Practitioners should use SBOMs as a control input, not a reporting artefact.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Software supply chain trust gap: the industry still behaves as if package origin is a sufficient trust signal, but that model collapses once third-party repositories, transitive dependencies, and build permissions are in play. Practitioners should move supply chain decisions into policy-controlled pipeline checkpoints rather than leaving them as informal developer choices.
The identity dimension is easy to miss, yet it is central to operational control. Build systems and signing services are non-human identities, and if their credentials are over-privileged, compromised dependencies can be pulled, signed, and shipped at machine speed. That is why pipeline identity governance belongs in the same discussion as dependency risk.
Teams that still rely on inventory alone will not reduce exposure. The real work is to combine SBOM visibility, reachability analysis, and release gates so only exploitable code paths and approved components survive into production.
For practitioners
- Embed package intake controls into CI/CD Block non-compliant or suspicious packages before they enter builds by applying policy at package download time and during dependency resolution.
- Add reachability analysis to SCA results Prioritise only the vulnerabilities that are actually invoked by application code so developers do not spend cycles on non-exploitable findings.
- Automate SBOM generation on every build Generate an up-to-date software bill of materials as part of the pipeline so component inventory supports audit, release, and incident workflows.
- Govern build credentials and signing access Limit who and what can pull dependencies, sign artifacts, and publish releases, because pipeline identities are part of the attack surface.
- Create policy gates for third-party code Define which dependency sources, versions, and licences are allowed, then enforce those rules before code moves toward production.
Key takeaways
- Third-party and open-source code now drive a large share of application risk, so DevSecOps controls must extend beyond first-party code.
- Reachability analysis matters because a vulnerable library is not automatically exploitable unless application code actually calls the affected method.
- Governed pipelines should combine provenance checks, SBOM generation, policy gates, and build identity controls before release.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised dependencies can be used to move through trusted build and release paths. |
| Recommendation — Map supply chain compromise paths to TA0006 and TA0008, then monitor build and release systems for abnormal access. | ||
| NIST CSF 2.0 | PR.DS-10 — Data in Transit Is Protected | Pipeline-controlled package transfer and artifact movement rely on protected data flows. |
| Recommendation — Apply PR.DS-10 to secure package transfer, artifact movement, and dependency intake across the pipeline. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build and signing identities need tight account governance because they control software release paths. |
| Recommendation — Use CIS-5 to inventory, restrict, and review the accounts that pull, sign, and publish software. | ||
| SLSA | L3 — Build integrity | The article centres on build provenance, dependency trust, and release integrity in the software supply chain. |
| Recommendation — Target SLSA L3 practices to harden provenance, isolate builds, and prevent tampered artifacts from shipping. | ||
Key terms
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- 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.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- 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.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and machine identity security that underpin build and pipeline trust. It helps practitioners connect identity controls to the delivery systems that software supply chain security depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org