OWASP Top 10 2025 placed Software Supply Chain Failures at A03. The change is broader than renaming the former vulnerable and outdated components category: it recognizes that risk emerges during software selection, acquisition, build, promotion, and distribution.
From a vulnerable component to a chain failure
A narrow assessment asks whether a library has a known CVE. A supply chain assessment also asks where it came from, who published it, whether the artifact was modified, how it entered the build, and which controls allowed it to be promoted.
| Component-focused view | Software Supply Chain view |
|---|---|
| Does the version have a known vulnerability? | Are the component's source, identity, and integrity trustworthy? |
| Is an update available? | Can the process select, test, and promote the update securely? |
| Is the dependency declared in the manifest? | Are transitive dependencies and delivered artifacts inventoried? |
| Did the tool raise an alert? | Can policy block, approve, record exceptions, and produce evidence? |
This broader scope includes dependency managers, build systems, artifact repositories, pipelines, distribution tools, and update processes. The question is no longer only “which component do we use?” but also “through which path did this component gain trust?”.
Why the category reached A03
In the community survey used for the 2025 edition, Software Supply Chain Failures ranked first: exactly 50% of respondents ranked it as the #1 category. The final OWASP Top 10 result, however, is not based on voting alone. OWASP combines community input with submitted data and editorial analysis.
Limited presence in datasets and the 11 associated CVEs do not mean that half of observed applications have this issue or that the category is universally the third most frequent. Software supply chain failures are difficult to represent through CVEs because many involve process, trust, identity, infrastructure, and distribution rather than a single code vulnerability.
The A03 position should be read as a signal of impact and systemic relevance. A compromise in a dependency, maintainer account, pipeline, or repository can propagate to many consumers before a traditional vulnerability indicator exists.
What changes in control design
1. Control begins during selection
Policies must operate before download or build introduction. Relevant signals include allowed source, component age, integrity, maintainer history, licenses, known vulnerabilities, and signs of malicious behavior.
2. Inventory includes transitive dependencies
Direct manifests do not describe the complete composition. Inventory must reflect transitive dependencies and the artifact actually produced. SBOMs help when they stay current, are tied to versions, and support monitoring and response processes.
3. Build and promotion are trust boundaries
Credentials, runners, plugins, actions, registries, and repositories can alter what reaches the user. Separation of duties, least privilege, signing, provenance, and promotion policies reduce the chance that an unauthorized change crosses the pipeline.
4. Updates must be continuous and testable
Rapid updates require more than receiving an alert. The team must locate consumers, assess compatibility, run tests, rebuild artifacts, promote the fix, and confirm distribution.
- 01Selectionsource, identity, and policy
- 02Ingestionintegrity and risk signals
- 03Buildenvironment, credentials, and provenance
- 04Promotionapproval and separation of duties
- 05Distributionsigning and trusted channel
- 06Monitoringnew vulnerabilities and incidents
How to assess your environment
- Do external dependencies come directly from the internet or through a controlled point?
- Does the inventory cover transitive dependencies and the delivered artifact?
- Does the pipeline pin versions and validate the integrity of actions, plugins, and images?
- Do build and publishing credentials use least privilege and rotation?
- Do artifacts receive verifiable signatures or provenance?
- Do promotion policies block risk and record exceptions with an owner and expiration date?
- Can the organization quickly locate and rebuild every consumer of a component?
Answering “yes” to the existence of a tool does not complete the assessment. Coverage, data quality, enforcement, exceptions, and response capacity still need verification.
Sources and references
- OWASP Top 10:2025 — A03 Software Supply Chain Failures
- OWASP Top 10:2025 — Introduction and methodology
- OWASP Software Component Verification Standard
Would you like to assess the trust boundaries in your CI/CD?
Xmart helps teams assess architecture, policies, and controls to reduce exposure across the Software Supply Chain.
