Software Supply Chain Failures: The OWASP Category That Eats Everything
OWASP Top 10 2025 added Software Supply Chain Failures as a top-level category. The change reflects what every working application security professional has been seeing for two years: the supply chain is the dominant attack vector, and it is structurally distinct enough from "vulnerable components" to deserve its own category.
The numbers behind the elevation are not subtle.
Sonatype's State of the Software Supply Chain 2024 reported more than 700,000 malicious packages found across npm, PyPI, and Maven since 2019, with a 156 percent year-over-year jump. Indusface's State of Application Security 2026 reports 6.29 billion attacks targeting website vulnerabilities in 2025, up 56 percent year-over-year. The median time to weaponization of a disclosed vulnerability is now under five days. 54 percent of critical vulnerabilities face active exploitation within the first week of disclosure.
This is the category. This is what is happening.
// what makes supply chain different from "vulnerable components"
The previous OWASP category — A06:2021 Vulnerable and Outdated Components — focused on the use of components with known vulnerabilities. The fix was conceptually clear: keep components updated, scan for known CVEs, replace deprecated libraries.
Supply chain failures are a superset that includes scenarios where the component is not "vulnerable" in any classical sense, because it was deliberately weaponized:
An attacker steals or socially engineers credentials to a package maintainer's account. They push a malicious version under the legitimate maintainer's identity. The Axios npm compromise of March 2026, attributed to North Korean threat actor UNC1069, used patient social engineering of the lead maintainer to gain account access. The Bitwarden CLI npm compromise used a similar pattern.
The malicious code is injected during the build process, not in the source. The Trivy GitHub Action compromise modified release tags after the build had completed, redirecting downstream consumers to attacker-controlled artifacts. Source review would not catch this. The artifact in the registry differed from the source in the repository.
Attackers register packages with names similar to legitimate ones (requets vs requests, colorama-py vs colorama) or names matching internal company packages on public registries. PyPI removed hundreds of malicious typosquats per month throughout 2024 according to Checkmarx and Phylum tracking. The pattern continues in 2026.
The infected package is not a direct dependency. The PyTorch Lightning compromise propagated through pyannote-audio, infecting consumers who never directly installed Lightning. The further the malicious component is from the consumer's direct dependency declaration, the harder it is to detect with manual review.
GitHub Actions and similar systems allow tags to be reassigned to point at different commits. An attacker who compromises the publishing pipeline can force-push tags to point at malicious code. Every workflow that references the action by tag silently runs the malicious code on next execution.
The AI model supply chain is the newest layer. HuggingFace incidents through 2024 and 2025 demonstrated that model weights can be manipulated to embed backdoors that activate on specific inputs. The OWASP LLM Top 10 covers this under its supply chain category, which overlaps with the new core OWASP category.
For LLM agent ecosystems, malicious instructions can be embedded in tool descriptions that the agent processes during MCP server registration. The MCPTox benchmark found that more than 60 percent of popular agents are susceptible to this class of attack. The compromise is in the metadata, not the code, which makes traditional code review insufficient.
// the defensive playbook
The defensive techniques against this category are mostly known. Adoption is the gap. The list below is what produces real reduction in supply chain risk, ordered by effort to value ratio:
- Lockfile and integrity hashes everywhere. package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, Gemfile.lock, go.sum, Cargo.lock. No exceptions. Every CI job that installs dependencies must use the lockfile. Most ecosystems support integrity hashes — use them.
- Pin GitHub Actions to commit SHA, not version tag. Tags are mutable. SHAs are not. The diff between
uses: aquasecurity/trivy-action@masteranduses: aquasecurity/trivy-action@a3e4f...is the difference between a vulnerable workflow and a hardened one. - Sigstore verification on package install where the ecosystem supports it. npm audit signatures. PyPI attestations. Cosign for container images. The verification is fast and the cost is low. The benefit is non-trivial.
- Behavioral analysis at install time. Socket, Phylum, Snyk Reachability, JFrog Curation, Checkmarx Supply Chain. These tools execute or sandbox new packages and flag suspicious behaviors — unexpected network calls, filesystem access, postinstall scripts that match known malware patterns. Catches attacks that signature-based tools miss.
- Internal proxy with quarantine period. Net-new dependencies — packages your organization has never used before — go through a quarantine period during which they are scanned, behaviorally analyzed, and reviewed before being available to developers. Most malicious packages are caught in the first 24 to 72 hours after publication. A quarantine period eats most of the risk window.
- SBOM generation in CI for every release. The starting point for vulnerability triage and supply chain analysis. Required by EU CRA. Useful regardless.
- Namespace ownership for internal packages. Register your internal package names as stubs on the public registry. Prevents dependency confusion attacks where an attacker publishes a public package matching your internal name.
- Egress control on build runners. The build runner has unrestricted internet access by default. Constraining its outbound network destinations to known package registries and known internal services eliminates an entire class of exfiltration paths.
- Disable install-time script execution where feasible. npm install --ignore-scripts. pip install with PEP 517 isolation. Some legitimate packages break, requiring an allowlist. The remaining attack surface is much smaller.
- Provenance attestations on your published packages. npm publish --provenance generates SLSA-style provenance metadata that downstream consumers can verify. Free signal that protects your users.
// the part that is not technical
The honest takeaway from every supply chain incident I have read post-mortems on: the open source supply chain is held together by individual humans who notice things. Andres Freund noticing 500ms of unexplained latency and discovering the XZ backdoor. The crypto developer who noticed an anomalous Lottie transaction. The Sansec engineer who spotted the polyfill.io rewrite. The Lightning maintainers who discovered their PyPI compromise via user reports.
Tools narrow the attack surface. Tools do not eliminate it. The durable defense is a team that has time to investigate anomalies. The unfashionable, unscalable, irreplaceable component of supply chain security is human attention and engineering judgment.
The investment that produces the highest return: give your senior engineers explicit budget for "weird things in the build." The next XZ-class incident will be caught by someone paying attention. Make sure that someone exists in your organization, and that their attention is not consumed by dashboards.
// the bottom line
Software Supply Chain Failures earned its OWASP Top 10 spot the hard way. The category is not going to shrink. The attack surface keeps expanding — new package ecosystems, new model registries, new agent tool catalogs.
The defensive playbook is mostly known. The work is adoption. The teams that close their supply chain gaps in 2026 will read about other people's incidents in 2027. The teams that do not will be in the news.
