OWASP Top 10 shifts put software supply chain failures in focus

At a glance

What this is: OWASP’s 2025 Top 10 revision elevates software supply chain failure as a major application-security risk, driven by upstream compromise and build integrity issues.

Why it matters: This matters to IAM practitioners because software supply chains increasingly carry secrets, service identities and privileged build access that can bypass conventional application controls.

By the numbers:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%).
• 81.5% year-over-year in 2025.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone.

👉 Read Anomali's overview of the OWASP Top 10 2025 supply chain shift

Context

Software supply chain failure is what happens when the trust boundary shifts from the application code itself to the dependencies, build systems and registries that produce it. In practical terms, the risk is not only malicious code but also unverified components, compromised pipelines and hidden credentials that enter software before security teams ever see runtime behaviour. This is now a primary application security and identity governance issue, because build services, tokens and signing keys are themselves high-value non-human identities.

Anomali’s summary of the OWASP update shows why the topic is moving up the priority list: the attack surface is increasingly the ecosystem around software delivery, not just the code a team writes. For IAM and PAM teams, that means treating CI/CD access, secret storage, package publishing and artifact signing as governance problems, not just engineering details. The organisations with the weakest starting position are usually the ones assuming private repos or trusted vendors are enough protection.

Key questions

Q: What breaks when software supply chain controls are only partially automated?

A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.

Q: Why do build systems and package registries matter to identity governance?

A: Build systems and package registries rely on service accounts, signing keys and deployment tokens that act with organisational authority. If those non-human identities are over-privileged or poorly inventoried, an attacker does not need to defeat application logic. They only need to abuse the trusted identities that move code into production.

Q: What do teams get wrong about private repositories and trusted vendors?

A: A private repository is not a guarantee of safety, and a trusted vendor is not a substitute for verification. Attackers target the delivery chain because that is where access, trust and automation concentrate. Teams need provenance checks, secret governance and least-privilege publishing, not assumptions based on ownership or location.

Q: How should organisations respond when package publishing credentials are stolen?

A: Immediately revoke the stolen publishing access, review recent publishes, and rotate every adjacent credential that the compromised identity could reach. Then inspect developer endpoints for persistence, because the attacker may have left backdoors outside the package manager. Response has to cover both registry access and local workstation state.

Technical breakdown

How software supply chain failures bypass application controls

Software supply chain failure occurs when a trusted dependency, package, image or build step is altered before it reaches production. Attackers can substitute a malicious package, poison a dependency tree, tamper with build runners or exploit dependency confusion so that the wrong artifact is pulled into a pipeline. The weakness is trust without verification: the application may be well defended, but the delivery chain has already been compromised upstream. In identity terms, the build pipeline often depends on tokens, service accounts and signing material that are far more privileged than the final app runtime.

Practical implication: map build and release identities separately from application identities and verify every privileged pipeline account.

Why build pipelines and package registries are high-value targets

Package registries and CI/CD systems concentrate repeated access, automation and broad write permissions, which makes them attractive for attackers seeking scale. A single compromised maintainer token or workflow secret can spread malicious changes across many downstream consumers. That is why modern supply chain attacks often aim at the publishing or build layer rather than the application server. The security issue is less about code quality alone and more about who can publish, sign, trigger and approve software artifacts. That makes secrets management, token scope and artifact integrity central controls.

Practical implication: limit publishing rights, protect signing keys and rotate CI/CD secrets on a defined cadence.

Software supply chain failures and NHI governance

The article’s core identity angle is that supply chains are full of non-human identities. Build robots, API keys, deploy tokens, package maintainers and signing certificates all act on behalf of the organisation, often with broad standing privilege. When those identities are not inventoried, scoped and lifecycle-managed, attackers inherit trusted access paths that bypass user-centric controls. This is why NHI governance is inseparable from supply chain security. The control problem is not just whether a package is safe, but whether the credentials and automation that move it are observable and constrained.

Practical implication: inventory every machine credential involved in build and release flows and bind it to an owner, purpose and expiry.

Threat narrative

Attacker objective: The attacker wants to inject trusted malicious code or credentials into software consumers will adopt without suspicion.

1. Entry occurs when attackers compromise a dependency, maintainer account or build credential inside the software delivery chain.
2. Escalation follows when the malicious package, tampered pipeline or stolen secret is used to publish trusted artifacts downstream.
3. Impact lands when the poisoned software reaches consumers, spreading credential theft, code execution or long-lived persistence through normal update paths.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Software supply chain failure is now an identity problem as much as a code problem. The article is right to move beyond dependency hygiene and toward ecosystem trust, because the actors making software move are credentials, service accounts and signing keys. If those identities are poorly governed, application security becomes downstream theatre. Practitioners should treat pipeline identities as first-class assets, not invisible plumbing.

Build pipelines are becoming the new privilege concentration point. CI/CD systems hold the access that turns source into production, which makes them a natural target for dependency substitution and tampered artifact creation. That concentration should change how teams think about PAM and secrets management. The practical conclusion is that the most dangerous privilege in many engineering organisations is the ability to publish what others will trust.

Secret sprawl is the fuel that makes supply chain compromise durable. The more places secrets live, the more likely a compromised workflow can be replayed or extended beyond the initial incident. NHIMG’s research shows internal repositories are 6x more likely to contain secrets than public ones, which makes “private” an unreliable security boundary. Teams need lifecycle control, not just detection, if they want to stop exposure from turning into persistence.

OWASP’s revision validates that supply chain governance must sit inside application security, not beside it. The category’s rise signals a wider market shift toward verifying provenance, artifact integrity and non-human access across the delivery path. That is where NHI governance, secret rotation and software integrity meet. Practitioners should expect audit, engineering and security teams to share ownership of the same control surface.

From our research:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), according to The State of Secrets Sprawl 2026.
• From our research: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026.
• From our research: Review the 52 NHI Breaches Analysis to see how exposed credentials and over-privileged automation repeatedly turn upstream trust into downstream compromise.

What this signals

Software supply chain failure is increasingly a control-plane issue, not just a code-review issue. For practitioners, that means the security programme has to watch the identities that build, sign and publish software, not only the systems that run it. In environments where internal repositories are 6x more likely to contain secrets than public ones, the line between source control and credential storage is already blurred.

Pipeline identity sprawl creates a governance gap that most organisations still underestimate. Service accounts, tokens and signing certificates often live outside the normal IAM review rhythm, which leaves release paths with persistent privilege and weak ownership. Teams that already manage workload identity should extend the same discipline to CI/CD and artifact signing, using the OWASP Non-Human Identity Top 10 as a practical reference point.

Secret exposure will keep turning into supply chain compromise until lifecycle control is built into delivery workflows. The programme signal to watch is not just the presence of leaked credentials, but whether revocation, provenance verification and publishing restrictions happen fast enough to break reuse. NHIMG’s view is that this is where software integrity and identity governance now converge.

For practitioners

• Inventory all software delivery identities List every service account, API key, signing certificate and bot account that can publish, approve or deploy software. Record owner, purpose, scope and expiry so that build access can be reviewed like any other privileged access path.
• Restrict build and publish privileges Separate read, build and release permissions so that no single automation identity can both change and ship artifacts. Require approval for package publishing and artifact signing, especially in pipelines that touch production.
• Rotate and revoke secrets tied to CI/CD Treat pipeline secrets as short-lived credentials with automated rotation and immediate revocation when compromise is suspected. Use secret scanning to find credentials in repositories, tickets and collaboration tools, not just in source code.
• Verify artifact provenance before deployment Require signed artifacts, provenance checks and reproducible build controls before release promotion. This reduces the chance that dependency confusion or malicious substitution reaches downstream consumers unnoticed.
• Link supply chain controls to identity governance Fold build identities into IAM and PAM review cycles so service accounts, tokens and certificates are owned, logged and offboarded. This is where software integrity and non-human identity governance become the same control problem.

Key takeaways

• Software supply chain risk now sits at the intersection of application security and identity governance, because build-time trust is enforced by non-human identities.
• Upstream compromise becomes far more dangerous when secrets, signing keys and publishing tokens are scattered across pipelines and internal repositories.
• Practitioners should treat provenance, least-privilege publishing and credential lifecycle control as core supply chain defences, not optional hardening.

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.
• Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
• Dependency Confusion: Dependency confusion is an attack technique where a build process pulls a malicious public package instead of the intended internal one. It works because package selection is based on naming or resolution rules rather than verified provenance, turning normal automation into a delivery channel for attacker-controlled code.

What's in the full analysis

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

• The specific OWASP 2025 category reshuffle and how it affects prioritisation across application security teams.
• The named supply chain failure modes OWASP used to justify the ranking change, including dependency substitution and tampered build pipelines.
• Anomalies and incident examples that show how ecosystem compromise reaches production through trusted software delivery paths.
• The analyst commentary that ties the OWASP shift to current defender focus areas across software assurance and access control.

👉 Anomali's full post covers the OWASP category changes, analyst commentary and related threat context.

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 controls to the broader security programme they run.