Software Supply Chain Failures
OWASP Top 10 (Web Application Security Risks) · A03:2025
New in the 2025 edition, and a broadening of what used to be framed narrowly as vulnerable and outdated components. The point is that you inherit risk from everything involved in producing and delivering your software, not just from the libraries you import: package registries, build systems, CI/CD runners, base images, plugins, and the third-party services your build trusts. An attacker who compromises any of those can have malicious code signed and shipped through your own legitimate release process.
The 2025 edition replaced the long-running 2021 edition. Many certification exams still test the 2021 list, so both are shown on this page.
How it shows up in the real world
- A dependency, or a transitive dependency several levels deep, that has a known exploited vulnerability and no available maintainer.
- A maintainer account takeover or malicious release that publishes credential-stealing code to a package widely used in builds.
- Dependency confusion, where a build resolves an internal package name from a public registry that an attacker has claimed.
- A compromised CI runner or build script that injects a backdoor into an artifact after tests pass but before signing.
- A pinned base image or build tool that silently changed because the tag was mutable.
How to mitigate it
- Maintain an accurate inventory of first- and third-party components, and generate a software bill of materials as a build output.
- Pin dependencies by cryptographic digest rather than by mutable tag or floating version range.
- Use a vetted internal registry or proxy, and configure resolution so internal names can never be satisfied from a public source.
- Verify signatures and provenance attestations for both dependencies and your own artifacts before deployment.
- Treat build infrastructure as production: least-privilege credentials, ephemeral runners, and no long-lived signing keys on general-purpose workers.
- Monitor for newly disclosed vulnerabilities in shipped versions and have a rehearsed path to patch and re-release quickly.
Practice this topic
Test your knowledge of Software Supply Chain Failures with exam-style practice questions.
Rest of the Web 2025 list
A01:2025Broken Access Control
Access control decides who may do what. It breaks when an application checks identity but never properly re-checks authority on the server for the specific action and record being requested. Because the rules live in application logic rather than in a single enforceable boundary, gaps are easy to introduce and hard to spot in review. In the 2025 edition this category also absorbed server-side request forgery, on the reasoning that tricking a server into making a request on your behalf is itself a failure to constrain what the server is permitted to reach.
A02:2025Security Misconfiguration
Software is usually far more permissive out of the box than it needs to be in production, and modern systems have an enormous amount of configuration surface: frameworks, containers, orchestrators, cloud services, identity providers, and CI systems all carry their own defaults. This category covers the security you never switched on, the sample content you never removed, and the environment differences nobody reconciled. It climbed to second place in the 2025 edition, reflecting how much of a deployment's risk now sits in configuration rather than in code.
A04:2025Cryptographic Failures
This category is about failures to protect data that deserves protection, whether in transit, at rest, or in backups and logs. The failures are rarely broken mathematics; they are missing encryption, obsolete algorithms, reused or hard-coded keys, weak randomness, and passwords stored with fast hashes. The first question is always a data-classification question: what are you holding, does it need protection, and for how long.
A05:2025Injection
Injection happens when untrusted input is concatenated into something an interpreter parses, so data crosses the boundary and is treated as instructions. The interpreter varies — SQL, the shell, an LDAP or XPath query, a template engine, a NoSQL document, or the browser's HTML parser in the case of cross-site scripting — but the shape of the bug and the fix are consistent: keep code and data structurally separate rather than trying to guess which characters are dangerous.
A06:2025Insecure Design
Some weaknesses cannot be patched because nothing is technically broken — the system was specified to behave that way. Insecure design covers missing or inadequate security controls in the design itself: a workflow that can be replayed, a trust assumption that does not hold, a recovery mechanism weaker than the thing it protects. A perfect implementation of a flawed design is still insecure, which is why this category is addressed with threat modelling and reference architectures rather than with scanners.
A07:2025Authentication Failures
Authentication establishes who is making a request, and session management preserves that answer across subsequent requests. This category covers weaknesses in both: credential stuffing and brute force that go unthrottled, factors that can be phished or relayed, and sessions whose tokens are predictable, long-lived, or never invalidated. Because credentials are the most consistently attacked part of any application, small gaps here tend to be found and exploited quickly.
A08:2025Software or Data Integrity Failures
Integrity failures occur when a system accepts code, updates, or structured data without verifying that it is what it claims to be and has not been altered. Deserializing attacker-controlled objects is the classic technical case, because many deserializers can be steered into constructing dangerous types and reaching code execution. The broader case is any trusted-by-default input: an unsigned update, a script pulled from a third party, or a CI step that consumes an unverified artifact.
A09:2025Security Logging and Alerting Failures
This category is about not being able to tell that something happened. If security-relevant events are not recorded, or are recorded somewhere nobody watches, an intrusion continues until an outsider notices. The 2025 edition renamed the category to emphasise alerting rather than passive monitoring: the failure is usually not an absence of data but an absence of anything that turns data into a timely response. Logging failures also make incident response and forensics much harder after the fact.
A10:2025Mishandling of Exceptional Conditions
New in the 2025 edition. This category covers what a system does when something goes wrong: an unhandled error, an unexpected input, a dependency timing out, a resource running short. Failure is inevitable, so security depends on failing in a defined and safe direction. The common pattern is a control that silently degrades — an authorization or verification step that returns an error which is treated as success, or an exception path that skips cleanup and leaves the system in an inconsistent state.