Most of the code in a modern web application was written by someone else, and the build systems that assemble it are now a favoured way in for attackers. A03:2025 Software Supply Chain Failures is the third risk in the OWASP Top 10:2025 and the successor to the long-running "known vulnerable components" item, widened to cover the whole chain: dependencies, developer tooling, repositories, CI/CD pipelines and artifact stores. This guide explains what OWASP includes in the category, how to turn its prevention list into a working programme, what evidence an assessor will ask for and how it maps to NIST, CIS, ISO and ATT&CK. It is written for AppSec engineers, platform and DevOps teams and the security leads who own software risk. For the whole list, start with the OWASP Top 10 Guide.
Key takeaways
- The scope is now the whole chain, not just old libraries. OWASP's 2025 description covers unpatched and unsupported components, untracked transitive dependencies, weak change control over IDEs, repositories and artifact stores, and CI/CD pipelines that are less secure than the systems they deploy.
- Few CVEs, high incidence. The category maps only 6 CWEs and 11 CVEs, yet OWASP reports the highest average incidence rate in its contributed data (5.72% in the score table) and it was the top concern in the community survey, with half of respondents ranking it first.
- An SBOM is the starting point, not the control. Inventory of direct and transitive dependencies only helps if it feeds vulnerability monitoring (CVE, NVD, OSV), documented remediation time frames and an owner who acts.
- Publishing and pipeline credentials are the real blast radius. Shai-Hulud spread through stolen npm tokens and SolarWinds through a compromised build: hardening build identities, signing and provenance matters as much as patching.
- Change management is part of the risk. OWASP explicitly calls out a single person being able to write and ship code without oversight, and monthly or quarterly patch cycles that leave known flaws exposed.
What it is and who it applies to
OWASP describes A03:2025 as covering breakdowns or compromises in the process of building, distributing or updating software, whether through third-party code, tools or the other dependencies a system relies on. It first appeared in 2013 as "A9 Using Components with Known Vulnerabilities" and was A06:2021 Vulnerable and Outdated Components in the previous edition. In 2025 it moved up to third place and was broadened, reflecting attacks such as poisoned packages and compromised build systems rather than only slow patching.
It applies to anyone who ships or runs web software: product teams consuming open source packages, platform teams operating build infrastructure, and organisations that deploy third-party applications and SaaS integrations. Small teams are not exempt: a single compromised maintainer token in an npm or PyPI dependency reaches every consumer that installs the bad version, regardless of the consumer's size.
The 2025 score table
| Metric (OWASP Top 10:2025 data) | A03 value | What it tells you |
|---|---|---|
| CWEs mapped | 6 | A narrow, process-driven category, not a family of coding bugs |
| Max / average incidence rate | 9.56% / 5.72% | Highest average incidence in the contributed data |
| Max / average coverage | 65.42% / 27.47% | Many contributors do not test for it at all |
| Average weighted exploit / impact | 8.17 / 5.23 | Easy to exploit once a weak component exists |
| Total occurrences / CVEs | 215,248 / 11 | Common in findings, rarely expressed as a CWE in CVE records |
The mapped CWEs are CWE-477 Use of Obsolete Function (the OWASP list prints it as CWE-447, a typo against the CWE catalogue), CWE-1035 (the 2017 A9 category), CWE-1104 Use of Unmaintained Third Party Components, CWE-1329 Reliance on Component That is Not Updateable, CWE-1357 Reliance on Insufficiently Trustworthy Component and CWE-1395 Dependency on Vulnerable Third-Party Component.
Structure and key requirements
OWASP groups its prevention advice into four areas. The table restates each area as requirements you can test.
| Area | What OWASP expects | Concrete control |
|---|---|---|
| Component visibility | Centrally generated and managed SBOM, direct and transitive dependencies tracked, unused components removed | CycloneDX or SPDX SBOM generated in every build, ingested into OWASP Dependency-Track or an equivalent; dead dependencies pruned each quarter |
| Vulnerability and patch management | Continuous monitoring of CVE, NVD and OSV; subscribe to alerts; migrate off unmaintained components; virtual patch where neither patching nor migration is possible | SCA gate in CI, Dependabot or Renovate style update PRs, documented remediation time frames (ASVS 5.0 V15.1.1), WAF virtual patch as a time-boxed exception |
| Trusted sourcing | Components only from official sources over secure links, signed packages preferred, versions chosen deliberately | Lockfiles committed, internal registry proxy, ASVS V15.2.4 check that transitive dependencies come from the expected repository; see the Malicious Package and Dependency Confusion Guide |
| Change management | Track changes to CI/CD settings, repositories, sandboxes, IDEs, SBOM tooling, logs, SaaS integrations, artifact repositories and container registries | Audit logs from the source platform, registry and CI shipped to the SIEM; infrastructure as code reviewed through pull requests |
| Hardening | MFA and locked-down IAM on repositories, developer workstations, build servers and artifacts | Protected branches, no checked-in secrets, environment-scoped secrets, signed builds, tamper-evident logs, immutable artifacts promoted rather than rebuilt per environment |
| Safe rollout | No simultaneous deployment everywhere; test updated libraries for compatibility | Canary or staged rollouts with automated rollback; dependency updates through the same test suite as feature code |
When you are likely vulnerable
- Visibility gaps: no record of client-side and server-side component versions, including transitive ones.
- Unsupported software: operating systems, servers, DBMS, runtimes or libraries that are outdated or out of support.
- No monitoring: no regular scanning and no subscription to security bulletins for the components in use.
- Weak process: one person can write and deploy code alone, and patching runs only monthly or quarterly.
- Weak pipeline: the CI/CD system is less hardened than the production systems it builds and deploys. See the CI/CD Security Guide.
Identity and NHI requirements
Most recent supply chain incidents were identity incidents first. The attacker needed a publishing token, a maintainer account or a build credential, and once they had it the registry or pipeline did exactly what it was told. A03 controls therefore depend on how you manage the non-human identities that build, sign and publish software.
| Identity | Typical failure | Requirement |
|---|---|---|
| Package registry publish tokens (npm, PyPI, RubyGems) | Long-lived token with publish rights on every package, stored on a laptop or CI runner | Use OIDC trusted publishing where the registry supports it: npm trusted publishing exchanges a CI OIDC token for a short-lived publish credential (GitHub Actions, GitLab CI/CD and CircleCI cloud runners) |
| CI/CD workload identity | Static cloud keys in pipeline variables, shared across environments | Federated, short-lived credentials scoped per environment; secrets scoped to the job that needs them |
| Signing keys | Private key held as a pipeline environment variable, readable by every build step | Key in an HSM or KMS, signing done by an isolated step, keyless signing where suitable. See the Code Signing Security Guide |
| Maintainer and developer accounts | Password plus SMS, no review on direct pushes | Phishing-resistant MFA on source and registry accounts, protected branches, required review |
| Bots and GitHub Apps | Auto-merge rights and broad repository scopes | Least privilege scopes, no auto-merge for dependency updates on sensitive repositories, periodic app review |
The HashiCorp GPG key exposure shows why: a signing key stored as a CI environment variable was readable by a tampered third-party upload script. The Shai-Hulud first wave spread because long-lived npm publishing tokens with broad rights sat on developer machines and runners. See the CI/CD Pipeline Identity Security Guide, the OWASP NHI Top 10 NHI2 Secret Leakage Guide and the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
Implementation steps
- Inventory first (weeks 1 to 4): generate an SBOM for every deployable in CI, store it with the build, and load it into a component analysis platform. Record owners per application. Do not block builds yet.
- Set remediation time frames: agree risk-based targets per severity and exploitation status (for example, faster for entries on the CISA Known Exploited Vulnerabilities catalogue) and write them into application documentation, as ASVS V15.1.1 requires.
- Turn on SCA in audit mode: report findings in pull requests for two to four weeks, tune false positives and reachability, then enforce a gate on new critical and KEV-listed findings only. Roll back by switching the gate to warn, not by removing the scanner.
- Lock sourcing: commit lockfiles, route installs through an internal registry proxy, block direct internet installs from build agents, and reserve internal package names to stop dependency confusion.
- Harden the pipeline identities: move registry publishing to OIDC trusted publishing, replace static cloud keys with federation, scope secrets per environment, enforce phishing-resistant MFA and branch protection.
- Add integrity: sign artifacts, generate provenance, verify signatures and provenance at deploy, and promote the same immutable artifact through environments. SLSA Build L2 (hosted build platform that signs provenance) is a realistic first target; L3 adds isolation between runs and keeps the signing secret out of user build steps. See the SLSA and Build Provenance Guide.
- Stage rollouts: deploy dependency updates through canary or ring deployments with automated rollback on error-rate or latency regression.
- Plan for end of life: flag unmaintained components (CWE-1104), set migration deadlines, and use virtual patching only as a dated exception with an owner.
Decision guidance
| Choice | Option A | Option B | Guidance |
|---|---|---|---|
| Update strategy | Automatic update PRs for all dependencies | Deliberate, pinned upgrades | OWASP advises choosing versions deliberately. Automate PRs, but require review and a short cooling-off period before merging new releases on critical services; Shai-Hulud style worms publish fresh malicious versions |
| Package source | Public registry directly | Internal proxy or curated mirror | Small teams can start with lockfiles and registry provenance checks; larger organisations benefit from a proxy that can quarantine and block versions centrally |
| Unpatchable component | Virtual patch (WAF rule) | Migrate or replace | Virtual patch buys time only; OWASP ranks it after patching and migration |
| Signing model | Long-lived signing key in HSM or KMS | Keyless signing tied to workload identity | Keyless removes a stealable key but shifts trust to the CI identity; either way, keep signing out of general build steps |
Evidence and assessment
Testing coverage for A03 is low in OWASP's data (27.47% average), so assessors increasingly ask for process evidence rather than a single scan result.
- Inventory evidence: SBOMs per release, retained with the artifact, covering transitive dependencies (ASVS V15.1.2).
- Remediation evidence: documented time frames and a report showing no component past them (ASVS V15.2.1), with dated exceptions.
- Pipeline evidence: branch protection settings, required reviewers, MFA enforcement reports from the source and registry platforms, and an inventory of tokens with their age and scope.
- Integrity evidence: signature and provenance verification logs at deployment, and the policy that rejects unsigned artifacts.
- Change tracking: audit logs for CI configuration, registry settings and SaaS integrations, shipped to the SIEM.
What to monitor
- New publish events from your own packages that did not originate from the expected CI workflow.
- Install-time scripts introduced by a dependency update, and new outbound network destinations from build runners.
- Creation of personal access tokens, new GitHub Apps or OAuth grants, and changes to branch protection or workflow files.
- Advisories for components in your SBOM, matched automatically against CVE, NVD, OSV and the GitHub Advisory Database.
Metrics
| Metric | Target direction |
|---|---|
| Share of deployables with a current SBOM | Towards 100% |
| Median days to remediate critical and KEV-listed component vulnerabilities | Within documented time frames |
| Components past end of life or unmaintained, per application | Falling |
| Share of package publishing done via OIDC trusted publishing rather than stored tokens | Rising |
| Share of production artifacts with verified signature and provenance | Towards 100% |
| Long-lived pipeline or registry tokens older than 90 days | Towards zero |
Mapping to other frameworks
| Framework | Relevant items |
|---|---|
| OWASP ASVS 5.0 | V15.1.1 remediation time frames, V15.1.2 SBOM inventory, V15.1.4 risky components, V15.2.1 components within time frames, V15.2.4 expected repository for transitive dependencies. See the OWASP ASVS Guide |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory, RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation, SA-22 Unsupported System Components, SA-15 Development Process, Standards, and Tools, SR-3 Supply Chain Controls and Processes, SR-4 Provenance, SR-11 Component Authenticity, SI-7 Software, Firmware, and Information Integrity |
| NIST CSF 2.0 | GV.SC-05 and GV.SC-07 (supply chain requirements and supplier risk), ID.AM-02 (software inventories), ID.RA-01 (vulnerabilities identified), PR.PS-02 (software maintained, replaced and removed), PR.PS-06 (secure development practices) |
| NIST SP 800-218 SSDF | Secure software development practices for producers. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets, Control 7 Continuous Vulnerability Management, Control 16 Application Software Security (third-party component inventory and trusted, up-to-date components) |
| ISO/IEC 27001:2022 Annex A | A.5.21 Managing information security in the ICT supply chain, A.8.8 Management of technical vulnerabilities, A.8.28 Secure coding |
| MITRE ATT&CK v20 | T1195.001 Compromise Software Dependencies and Development Tools, T1195.002 Compromise Software Supply Chain |
| Related OWASP lists | CICD-SEC-3 Dependency Chain Abuse, LLM03 Supply Chain, M2 Inadequate Supply Chain Security, and A08:2025 Software or Data Integrity Failures for signing and integrity checks |
Common pitfalls
- SBOMs generated and never read. An SBOM in an artifact store with no vulnerability matching and no owner satisfies a contract clause but not the risk.
- Scanning only direct dependencies. Most vulnerable code arrives transitively; OWASP calls out transitive tracking explicitly, and Log4Shell (CVE-2021-44228) was frequently a nested dependency.
- Trusting the front end you did not build. In the Bybit hack, a supplier's developer laptop and hijacked AWS session tokens let attackers alter wallet interface JavaScript, and the malicious code fired only for the target wallet.
- Long-lived publishing tokens on laptops and runners. One infected install was enough for Shai-Hulud to publish poisoned versions of other packages; CISA advised rotating all developer credentials and requiring phishing-resistant MFA on GitHub and npm.
- Signing keys reachable from build steps. Signing only proves who held the key; if every script in the pipeline can read it, an attacker can sign too.
- Big-bang updates. Rolling a dependency update to every service at once turns one bad release into a full outage or a full compromise.
Practitioner checklist
- Generate an SBOM for every build, including transitive dependencies, and feed it into continuous vulnerability matching.
- Document risk-based remediation time frames per severity and report components that exceed them.
- Commit lockfiles, install through an internal registry proxy and reserve internal package names.
- Replace stored registry publish tokens with OIDC trusted publishing where supported, and inventory any remaining tokens by age and scope.
- Enforce phishing-resistant MFA, branch protection and required review on source and registry accounts.
- Move signing keys into an HSM or KMS, sign artifacts and verify signature and provenance before deployment.
- Ship CI, registry and source platform audit logs to the SIEM and alert on unexpected publish events and workflow changes.
- Deploy dependency updates through staged or canary rollouts with automated rollback.
- Track unmaintained and end-of-life components with migration deadlines and dated virtual-patch exceptions.
Standards and references
- OWASP: A03:2025 Software Supply Chain Failures
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- NIST: SP 800-53 Rev. 5
- OpenSSF: SLSA Security Levels
- CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
- npm Docs: Trusted publishing for npm packages
- MITRE ATT&CK: Compromise Software Supply Chain
Related NHI Mgmt Group resources: OWASP Top 10 Guide · Software Supply Chain Security Guide · SBOM Guide · OWASP Top 10 A02 Guide · OWASP Top 10 A04 Guide