Quartz 5

A03_2025 Software Supply Chain Failures

3 min read

A03:2025 Software Supply Chain Failures

is one of the most important expansions in the 2025 release. The OWASP A03:2025 page states that this risk is not limited to using vulnerable components; it also covers dependencies, build systems, CI/CD pipelines, artifact repositories, developer tooling, and distribution infrastructure.

Modern web applications often rely on more third-party code, packages, container images, and build tools than code written directly by the application team. For that reason, the attacker’s target may not be a production endpoint; it may be an npm package, GitHub Action, CI runner, container registry, IDE extension, or vendor update mechanism. In supply chain attacks, malicious code can arrive through a channel the development process already trusts, which helps it bypass classic perimeter controls.

Root Cause

Modern web applications may use thousands of direct and transitive dependencies. Application security depends not only on your own code, but also on:

  • Package registry
  • Open-source library
  • Build tool
  • CI/CD runner
  • Container image
  • Artifact registry
  • IDE extension
  • Deployment script
  • Third-party SaaS integration

If any part of the chain is maliciously changed or remains vulnerable, the application can be affected.

Typical Risks

  • Vulnerable and outdated dependencies
  • Unmaintained packages
  • Lack of transitive dependency visibility
  • Package confusion or typosquatting
  • CI/CD secret exposure
  • Unsigned build artifacts
  • Developer workstation or IDE extension compromise
  • Missing SBOM
  • Uncontrolled vendor updates rolled out to all environments

Vulnerable Dependency Flow

Developer laptop
  -> npm install unknown-helper
  -> package runs postinstall script
  -> CI token is read from environment
  -> malicious package publishes modified build artifact
  -> production deploys compromised artifact

There may be no classic SQL Injection in the application code. The impact can still be greater because malicious code reaches production.

SBOM and Dependency Control

A Software Bill of Materials (SBOM) is an inventory of the components that make up the application. An SBOM is not a defense by itself, but it is necessary for vulnerability management, license control, incident response, and supply chain visibility.

Example dependency checks:

npm audit --production
pip-audit
osv-scanner --recursive .

The command output alone is not the final decision. Whether a CVE is exploitable depends on the version used, reachable functions, exposed endpoints, and compensating controls.

Secure CI/CD Principles

  • Use branch protection and mandatory code review.
  • Scope CI/CD secrets by environment.
  • Separate build and deploy permissions.
  • Promote signed artifacts instead of rebuilding for each environment.
  • Review package lock files.
  • Mask secrets in build logs.
  • Roll out dependency updates in stages.
  • Scan container images regularly and use minimal base images.

Testing Approach

Supply chain testing is not just running

npm audit

. Review these areas:

  • Dependency manifests and lock files
  • Transitive dependency risk
  • Build pipeline permission model
  • Artifact signing and provenance
  • Registry sources
  • Secret exposure
  • Release approval process
  • Vendor update processes

Defensive Controls

  • Generate and centrally track SBOMs.
  • Use trusted package registries and pinned versions.
  • Run dependency updates through a risk-based process.
  • Treat the CI/CD pipeline as critical as production.
  • Sign build artifacts and verify before deployment.
  • Include developer tooling and workstation security in supply chain scope.

This category shows that web security is no longer only HTTP endpoint testing. Where the application is built, which code reaches production, and how that code’s integrity is verified are part of the security assessment.

Graph View