A03:2025 - Software Supply Chain Failures

Software Supply Chain Failures is a new category introduced in the OWASP Top 10 for 2025 at position three. It replaces and significantly broadens the scope of "Vulnerable and Outdated Components" (A06:2021), reflecting the growing threat landscape around software supply chains. Modern applications depend on hundreds of third-party packages, CDN-hosted scripts, and build tools, each a potential vector for compromise if integrity is not verified at every stage.

Overview

The software supply chain encompasses every external dependency your application consumes: open-source libraries, package registries, build pipelines, CDN assets, and container base images. Attacks on this chain have escalated dramatically, from typosquatting and dependency confusion to compromised maintainer accounts and malicious build scripts. The 2025 reclassification acknowledges that the risk goes far beyond simply using outdated packages; it now covers the entire trust chain from source to deployment. Radar's SAST engine identifies code-level supply chain patterns, while its SCA engine complements this with dependency vulnerability scanning against CVE databases.

What Radar Detects

• Usage of known-vulnerable APIs. Calls to library methods that are documented as vulnerable in certain version ranges, such as deprecated cryptographic functions or APIs with known security bypasses, flagged directly in your source code.

• Deprecated security functions. Use of functions that have been replaced by secure alternatives, such as Node.js createCipher() (which should be createCipheriv()), Python's md5() for password hashing, or Java's java.util.Random for security-sensitive generation.

• Unverified package imports from public registries. Dependencies pulled from public registries without pinned versions, integrity hashes, or signature verification, making them susceptible to package substitution attacks.

• Dependency confusion patterns. Internal package names that could be hijacked on public registries because they are not reserved or scoped, allowing an attacker to publish a malicious package with the same name and a higher version number.

• Missing lockfile integrity. Package installations that proceed without checksum verification, meaning a tampered package could be installed without detection. Radar flags projects missing lockfiles or using install commands that bypass integrity checks.

• Unsigned or unverified CDN scripts. External JavaScript or CSS loaded from CDNs without Subresource Integrity (SRI) hashes, allowing a compromised CDN to serve malicious code to all users of the application.

Related CWEs

CWE-1104 (Use of Unmaintained Third-Party Components), CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-494 (Download of Code Without Integrity Check).

See the CWE Reference for details.

Prevention

• Maintain a Software Bill of Materials (SBOM) that catalogs every direct and transitive dependency in your application, updated automatically on each build.
• Verify dependency integrity using lockfiles with cryptographic checksums and reject any package whose hash does not match the expected value.
• Use private registries for internal packages and reserve your internal package names on public registries to prevent dependency confusion attacks.
• Implement Subresource Integrity (SRI) for all scripts and stylesheets loaded from external CDNs, ensuring tampered assets are blocked by the browser.
• Scan source code for calls to deprecated or known-vulnerable API methods and replace them with their secure alternatives.
• Monitor dependency advisories continuously and integrate automated alerts into your development workflow for newly disclosed vulnerabilities.
• Pin dependency versions explicitly and audit version upgrades before merging them into the main branch.
• Sign build artifacts and verify signatures at every stage of the deployment pipeline.

Next Steps