TL;DR: OWASP’s Top 10:2025 moves Software Supply Chain Failures to third place, reflecting upstream compromise patterns such as dependency substitution, tampered build pipelines and unvalidated third-party packages, according to Anomali citing OWASP analysis of more than 220,000 CVEs. The control problem is no longer isolated code review but trust in the software ecosystem around the application.
At a glance
What this is: OWASP’s 2025 Top 10 elevates software supply chain failures to third place, signalling that upstream compromise is now a core application-risk driver.
Why it matters: IAM and security teams need to treat build integrity, package trust and third-party assurance as governance issues, not just development hygiene, because compromise now lands through the ecosystem around the application.
Context
Software supply chain failure is the point at which trusted upstream components, build steps or package dependencies become the attack path instead of the application code itself. In this article, the primary security problem is integrity loss in the software ecosystem that developers rely on to build and ship software.
That matters to identity and governance teams because modern delivery pipelines depend on service accounts, tokens, package registries and signing trust. When those control points are weak, the organisation inherits risk from suppliers, build tooling and dependency management long before runtime controls can intervene.
Key questions
Q: What breaks when software supply chain identity controls are missing?
A: When build and release identities are not tightly governed, attackers can exploit trusted packages, signing paths, or automation accounts to push malicious artifacts through delivery. The break is not only technical compromise, but loss of assurance that released software is what the organisation intended to approve and deploy.
Q: Why do misconfigured build pipelines create such a high risk for software supply chains?
A: Misconfigured build pipelines are risky because they can let attackers influence build steps, inject untrusted input, or execute code during the delivery process. That makes the pipeline itself part of the attack surface. When build logic is weakly controlled, attackers may reach sensitive secrets, alter artifacts, or hide activity inside routine automation.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.
Q: Should organisations prioritise software supply chain controls over code scanning?
A: They should prioritise both, but supply chain controls come first when the main risk is untrusted code entering the pipeline. Code scanning only helps after code exists, while provenance checks, signing and release governance reduce the chance that malicious code is accepted in the first place. That is the stronger control boundary.
Technical breakdown
Why dependency trust becomes the attack surface
Software supply chain attacks succeed when teams assume that a package, artifact or build input is trustworthy because it is widely used or comes from a familiar source. In practice, dependency substitution, dependency confusion and malicious package publication exploit the gap between provenance and trust. A build system that can fetch, assemble and promote code without strong verification inherits the attacker’s content as if it were legitimate. This is why the risk is systemic: one compromised dependency can propagate into many downstream environments before anyone notices.
Practical implication: verify provenance and integrity for every external dependency before it enters the build pipeline.
How build pipelines turn trust into privilege
Build pipelines are not just automation, they are privileged execution environments. They hold credentials, publish artifacts, sign releases and often have broad access to internal repositories and cloud services. If an attacker tampers with a pipeline, the result is not only malicious code but trusted code signed and distributed by the organisation itself. That creates a very different failure mode from a simple vulnerable library. The control boundary shifts to the pipeline, its secrets, and the conditions under which artifacts are accepted or promoted.
Practical implication: restrict pipeline credentials, enforce artifact attestation and separate build trust from deployment trust.
Why ecosystem integrity now matters more than isolated code review
Isolated code review can detect obvious defects in first-party code, but it does not reliably expose compromised registries, poisoned dependencies or manipulated upstream artifacts. Software supply chain failures exploit the layers around the application, including package managers, build scripts and third-party distribution channels. That means the effective control set is broader than software scanning alone. Teams need assurance over where components came from, who can publish them, and whether the produced artifact matches what was intended.
Practical implication: extend control coverage to source provenance, registry governance and signed artifact verification.
Threat narrative
Attacker objective: The attacker wants to convert upstream trust into downstream code execution, persistence or broad compromise through a trusted software delivery path.
- Entry begins when attackers introduce malicious or substituted dependencies into package registries or influence a trusted build input.
- Credential and pipeline abuse follow when build systems or automation consume those inputs without strong provenance checks, allowing tampered artifacts to be promoted.
- Impact occurs when the compromised artifact is distributed to downstream environments as trusted software, extending attacker reach across many organisations.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Software supply chain failures are now a governance problem, not a narrow developer problem. Once package trust, build integrity and artifact provenance become central risk drivers, the control question moves beyond code quality into assurance over the entire delivery chain. That puts procurement, engineering and security into the same governance conversation, because compromise can enter through any of them. Practitioners should treat software supply chain trust as a board-level assurance issue, not a tooling choice.
Provenance is the named concept that matters here: the organisation must be able to prove where software came from and whether it changed in transit. Without that, security teams are left reacting to what entered the pipeline after the fact. Integrity verification, signed artifacts and controlled publisher access are the practical expressions of that governance need. The practitioner takeaway is simple: if provenance is unclear, trust is already broken.
Build systems behave like privileged identity ecosystems, and that is why identity security enters the picture. Service accounts, tokens and automation secrets make the pipeline an identity problem as much as a code problem. If those non-human identities can publish, sign or promote software without tightly governed scope, the pipeline becomes a high-value abuse path. Practitioners should align pipeline identity controls with privileged access governance, not treat them as dev-only credentials.
The OWASP shift validates a broader market trend toward ecosystem assurance over point-in-time scanning. Security teams are being pushed to ask harder questions about third-party publishing rights, artifact verification and dependency provenance. That does not replace application security testing, but it does mean testing is no longer enough on its own. The actionable conclusion is that software trust must be managed continuously, from source intake to release promotion.
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: Cloud PAM and CIEM Guide
What this signals
Software supply chain failures now expose a provenance trust gap: defenders must be able to prove where code, dependencies and build outputs came from before they can claim control over release integrity. That is why package trust, registry governance and artifact attestation belong in the same control discussion as secure development.
The identity angle is real but often missed. Build and release pipelines rely on non-human identities to fetch, sign and promote software, so weak lifecycle governance on those identities can turn a software issue into an access issue very quickly.
92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That figure reinforces why supplier trust and non-human credential governance now need to be treated as a single operating problem.
For practitioners
- Implement provenance checks for all dependencies Require signed metadata, source attribution and repository allowlisting before third-party code can enter builds or deployment paths.
- Lock down build and release identities Treat pipeline service accounts, signing keys and automation tokens as privileged identities with narrow scope and rapid revocation paths.
- Add artifact attestation to release gates Block promotion unless the artifact matches the expected source commit, build process and signing policy.
- Review supplier publishing rights and trust paths Map which external maintainers, registries and internal teams can publish or modify software inputs, then remove unnecessary trust.
Key takeaways
- Software supply chain failures are now a core application-risk issue because upstream compromise can enter through trusted dependencies, build systems and registries.
- The key evidence behind the OWASP shift is not a single class of bug but a broad pattern of integrity loss across the software ecosystem.
- Practitioners should respond by hardening provenance, restricting pipeline identities and requiring artifact attestation before release promotion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Dependency and registry trust hinge on knowing what software inputs exist and where they come from. |
| Recommendation — Inventory all external components and block unapproved package sources before they reach the build. | ||
| OWASP Agentic AI Top 10 | Agentic Supply Chain Vulnerabilities | The article centers on upstream trust and integrity failure in software delivery chains. |
| Recommendation — Track provenance for every software input and stop promotion when trust cannot be established. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised builds and repositories often lead to credential abuse and downstream propagation. |
| Recommendation — Map compromised pipeline identities to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity and authenticity of data | Artifact and dependency integrity are central to the article’s risk model. |
| Recommendation — Apply integrity controls to software artifacts and verify authenticity before release. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party package and build trust depend on supplier governance and oversight. |
| Recommendation — Evaluate third-party software sources and restrict trust to approved providers and channels. | ||
Key terms
- Software Supply Chain Failure: A software supply chain failure is any breakdown in the build, dependency, signing, or distribution chain that allows tampering, compromise, or unauthorized access. For NHI security, the concern is not only corrupted code but also the credentials and machine identities that move that code through the pipeline.
- Artifact Attestation: Evidence that a build output was produced by a trusted process and has not been altered before execution. It is a practical control for software and AI supply chains because it helps separate approved runtime inputs from files that merely look legitimate.
- Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
- CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
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 security practitioners connect non-human identity controls to the wider governance decisions their programmes depend 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