A03 · Software Supply Chain Failures

Program: Application Security — OWASP Top 10 and Threat Modeling Module: OWASP Top 10 — Web Application Security Risks Submodule: A03:2025 · Software Supply Chain Failures

The 2025 evolution of what used to be A06:2021 · Vulnerable and Outdated Components. The rename is not cosmetic — it acknowledges that attackers no longer just wait for CVEs in your dependencies; they actively compromise the process by which those dependencies get into your build. This is now #3 in the Top 10.

The category maps to STRIDE's Tampering (the artifact you shipped is not the artifact you thought you shipped) and Elevation of Privilege (a compromised build tool runs with production access).

---

1. What It Is

Any weakness in how software components enter your system and are built into your product, including:

• Direct dependencies with known vulnerabilities — the classic "Vulnerable and Outdated Components" case.
• Transitive dependencies — bugs in your dependencies' dependencies.
• Malicious packages — typosquatting (reqeusts), dependency confusion (public package with the same name as your internal one is installed first), maintainer account takeover, deliberately malicious releases.
• Compromised build pipelines — CI/CD systems executing untrusted code with production secrets (SolarWinds, 3CX, PyPI-CI attacks).
• Compromised distribution channels — package registries, container registries, VCS forge accounts.
• Lack of provenance and attestation — you cannot prove that the binary you're running was built from the source you audited.

---

2. Landmark Incidents That Shaped the Category

Year	Incident	What it demonstrated
2018	event-stream (npm)	Maintainer transferred package to malicious actor who added a Bitcoin-stealing payload targeting a downstream wallet.
2020	SolarWinds Orion	Nation-state compromised the build system, injecting SUNBURST into the signed installer distributed to ~18,000 orgs.
2021	Log4Shell (CVE-2021-44228)	A single string in log4j2 gave RCE on millions of systems; showed how deep transitive dependencies really go.
2022	colors / faker	Maintainer self-sabotaged widely-used npm packages; broke thousands of downstream builds.
2022	PyPI account takeovers	Hundreds of package maintainers phished; malicious releases pushed.
2023	3CX	Trojanized DesktopApp distributed via signed installer; second known "signed-installer" supply-chain attack at that scale.
2024	XZ-Utils backdoor (CVE-2024-3094)	A patient multi-year maintainer takeover embedded a backdoor into the xz compression library, targeting sshd on Linux; caught 4 weeks before wide distribution.
2024–2025	ultralytics, pytorch-nightly, PyPI/npm typosquats	Continued flood of malicious releases through registry and CI compromise.

The trend line is unambiguous: the source is no longer the source of truth. What you build is only as trustworthy as your registry, maintainer, and pipeline.

---

3. How It Happens — Common Patterns

Layer	Failure mode
Dependencies	No dependency-vulnerability scanning; pinning without update discipline; no SBOM.
Package resolution	Missing .npmrc / pip.conf scopes → dependency confusion (public package with same internal name resolves first).
Maintainer / registry	Registry-side account takeover; malicious maintainer; no signed publishing (sigstore).
Build pipeline	CI runs untrusted PRs with production secrets; workflow_dispatch writes to prod; secrets not scoped to jobs; self-hosted runners shared across repos.
Distribution	Artifacts signed with insecure keys, or not signed at all; no reproducible builds.
Runtime	No verification of container image signatures at admission (cosign verify + Sigstore policy-controller).

---

4. Prevention — The SLSA Levels

SLSA ("Supply-chain Levels for Software Artifacts", pronounced "salsa") is Google/OpenSSF's tiered maturity model. It gives concrete requirements you can build toward.

Level	Focus	You must have
L1	Provenance exists	Automated build with a documented process; provenance artifact generated.
L2	Provenance is authenticated	Build platform generates signed provenance; source is version-controlled.
L3	Provenance is trustworthy	Hardened, isolated build service; non-falsifiable provenance.
L4	Highest assurance	Hermetic, reproducible builds; two-person review of all changes.

Concrete practices:

• Maintain an SBOM for every artifact (syft, cyclonedx-cli) — now required by US EO 14028 and EU CRA for many products.
• Dependency scanning in CI — dependabot, renovate, snyk, trivy fs, grype, osv-scanner. Fail builds on critical CVEs.
• Pinning and lockfiles — package-lock.json, poetry.lock, go.sum, Cargo.lock. Pin to hashes, not just versions (--require-hashes in pip).
• Scoped package sources — npm config set scope / .pip/pip.conf index-url — so internal names never resolve to a public registry. Kills dependency confusion.
• Signed builds and artifacts — sigstore/cosign for container images and generic blobs; verify signatures at admission.
• Isolated CI — never run untrusted PR code with production secrets; use pull_request (limited perms) not pull_request_target; scope secrets to the smallest job.
• Reproducible builds where possible — you can then verify a binary came from a specific source.
• Verify third-party actions/plugins pinned by SHA, not tag — GitHub Actions in particular.
• Have a plan for maintainer takeover. Watch for maintainer changes on critical packages; consider vendoring.

---

5. Detection & Testing

• SCA (Software Composition Analysis) — snyk, dependabot, trivy fs, grype, osv-scanner, GitHub Advanced Security. First line of defense against known CVEs in deps.
• Container image scanning — trivy image, grype, cloud registry scanners (ECR, GCR, Docker Scout).
• SBOM diffing — compare SBOMs across releases; new/unexpected transitive deps are worth investigating.
• Registry-side alerts — enable typo/scope alerts on npm/PyPI; monitor for packages with suspicious install-time scripts.
• CI hardening scanners — actionlint, harden-runner (StepSecurity), OpenSSF Scorecard.
• Runtime signature verification — cosign verify + Kyverno/Sigstore policy-controller at admission.

---

6. Key Takeaways

• The rename from "Vulnerable Components" to "Software Supply Chain Failures" is the biggest conceptual shift in the 2025 list — attackers now compromise the pipeline, not just wait for CVEs.
• SBOM + SCA in CI + signed builds is the modern minimum, and now a regulatory minimum in the US (EO 14028) and EU (CRA).
• Dependency confusion and maintainer takeover are two attack patterns unique to open-source ecosystems that no traditional vulnerability scan will catch.
• Use SLSA as the maturity ladder — most teams should aim for L2/L3 within a year, L4 for critical/regulated systems.

---

7. Glossary (this submodule)

• Supply chain (software) — everything and everyone involved in getting code from a developer to running in production: source hosts, dependencies, build systems, registries, distribution.
• SBOM — Software Bill of Materials; machine-readable inventory of every component in an artifact (SPDX or CycloneDX format).
• SLSA — Supply-chain Levels for Software Artifacts; OpenSSF maturity model (L1–L4) for build integrity.
• Sigstore / cosign — OpenSSF project for signing and verifying software artifacts using short-lived keys and a transparency log.
• Provenance — cryptographic evidence linking an artifact back to its source repo, commit and build.
• Dependency confusion — attack where a public package with the same name as an internal package is installed first because the resolver isn't scoped.
• Typosquatting — publishing a malicious package with a name close to a popular one (reqeusts vs requests) hoping for misspellings.
• SCA — Software Composition Analysis; automated scanning of dependencies for known vulnerabilities.

---

8. What's Next

• A04 · Cryptographic Failures — the same discipline of "prove what's actually in production" applied to how data is protected.
• Cross-refs: A02 · Security Misconfiguration (CI runners and registries are configuration surfaces), A08 · Software or Data Integrity Failures (missing signature verification is the runtime half of this problem).