A03:2025 - Software Supply Chain Failures

Overview

Software Supply Chain Failures is ranked as A03 in the OWASP Top 10:2025 and was one of the highest-ranked concerns in the community survey. This reflects a shift in how modern applications are built and attacked: compromising the software supply chain is often more effective than attacking the application directly.

Modern applications are no longer self-contained. They are assembled from:

• third-party libraries

• open-source dependencies

• container images

• build tools

• CI/CD pipelines

• package registries

• cloud services

• developer tooling

Each of these components becomes part of the final application. If any part of that chain is compromised, outdated, untrusted, or poorly controlled, the entire system inherits that risk.

From an attacker’s perspective, the supply chain is attractive because it allows:

• compromise at scale

• indirect access to multiple targets

• persistence across deployments

• abuse of trusted relationships

Instead of breaking one application, attackers compromise what builds, updates, or runs many applications.

Why Supply Chain Attacks Are So Effective

Supply chain attacks succeed because they abuse implicit trust.

Organizations trust:

• package repositories

• build pipelines

• vendor updates

• open-source libraries

• developer tools

That trust is rarely validated continuously.

Once a malicious or vulnerable component is introduced, it often:

• runs with the same privileges as the application

• bypasses perimeter defenses

• avoids traditional detection

• persists across environments

In many cases, developers and operators do everything “correctly” from an application standpoint, while the compromise occurs entirely outside the application code they control.

Supply Chain Failures Are Not Just “Outdated Libraries”

A common misconception is that supply chain risk only means “using vulnerable dependencies”.

In reality, Software Supply Chain Failures include:

• unmaintained or abandoned libraries

• malicious packages

• compromised build systems

• tampered artifacts

• unsigned updates

• insecure CI/CD pipelines

• over-permissioned developer tooling

• lack of visibility into transitive dependencies

An application may be fully patched and still vulnerable if its supply chain is not secured.

The Expanding Attack Surface

Every dependency added to a project expands the attack surface.

This includes:

• direct dependencies

• transitive dependencies

• build-time dependencies

• runtime dependencies

• development-only tools that leak into production

From an offensive standpoint, attackers look for:

• popular packages with broad adoption

• poorly maintained projects

• libraries with complex dependency trees

• build steps that trust external inputs

• pipelines with weak access control

The more complex the supply chain, the harder it is to reason about its security.

Supply Chain Failures as a Root Cause

Many high-impact incidents attributed to “advanced attacks” were fundamentally supply chain failures.

In these cases:

• the application did not defend itself against the threat

• the threat arrived already trusted

• traditional controls were bypassed by design

This makes supply chain failures particularly dangerous: they often invalidate assumptions made by security controls higher up the stack.

Scope of A03:2025

In the OWASP Top 10:2025, Software Supply Chain Failures expand beyond earlier categories focused only on vulnerable components. The scope now includes the entire lifecycle of software creation and delivery, from development to deployment.

This category overlaps with:

• dependency management

• build security

• artifact integrity

• CI/CD security

• developer environment security

How This Section Is Structured

This section focuses on:

• understanding how supply chain failures occur

• identifying common attack patterns

• approaching supply chain security from an attacker’s mindset

• validating risks during offensive testing

The goal is not to list tools, but to understand where trust exists — and how it can be abused.

What Is a Software Supply Chain Failure?

A software supply chain failure occurs when trust placed in external components, processes, or systems is abused, weakened, or broken, resulting in risk being introduced into an application without direct changes to its core business logic.

In simple terms, the application becomes vulnerable not because of what it does, but because of what it depends on.

Modern applications are assembled rather than written from scratch. Every dependency, tool, and service involved in building, testing, and running the application becomes part of the final product. When any of those elements is insecure, compromised, or poorly controlled, the application inherits that weakness.

From an attacker’s perspective, a supply chain failure is powerful because it allows them to:

• bypass application-level defenses

• operate within trusted execution paths

• impact multiple targets simultaneously

• persist across updates and deployments

Trust Is the Core Problem

At the heart of every supply chain failure is implicit trust.

Applications trust that:

• dependencies are safe

• packages are what they claim to be

• updates are legitimate

• build artifacts have not been tampered with

• CI/CD pipelines behave as expected

This trust is rarely verified continuously. Once established, it often becomes invisible.

Attackers exploit this by inserting themselves upstream, where security controls are weaker and visibility is lower.

Supply Chain Failures Are Often Invisible

One of the most dangerous aspects of supply chain failures is that they frequently:

• do not break functionality

• do not trigger errors

• do not raise alarms

• look like normal application behavior

A malicious dependency may execute as part of the application startup. A compromised build pipeline may produce artifacts that look legitimate. A poisoned update may be installed automatically.

From the system’s point of view, everything is working as designed.

Where Supply Chain Failures Occur

Supply chain failures can occur at multiple stages of the software lifecycle:

• Development stage Malicious or vulnerable libraries added as dependencies, compromised developer tools, poisoned package installs

• Build stage Compromised CI/CD pipelines, insecure build scripts, tampered artifacts

• Distribution stage Unsigned or unverified packages, compromised registries, man-in-the-middle delivery

• Deployment stage Insecure container images, untrusted base images, weak integrity checks

• Runtime stage Over-privileged dependencies, embedded secrets, unsafe update mechanisms

Each stage introduces trust assumptions that attackers can target.

Not All Supply Chain Failures Are Malicious

It is important to note that supply chain failures are not always the result of an intentional attack.

They may also result from:

• abandoned or unmaintained libraries

• dependencies with known vulnerabilities

• outdated build tools

• insecure defaults in third-party components

• lack of visibility into transitive dependencies

From an attacker’s perspective, neglect is just as useful as malice.

Why Traditional Security Often Misses This

Traditional application security focuses on:

• input validation

• authentication

• authorization

• runtime behavior

Supply chain failures often bypass these controls entirely because the compromised component:

• is already trusted

• runs with legitimate privileges

• executes before or outside normal request handling

This makes supply chain attacks difficult to detect using conventional testing alone.

Supply Chain Failures as a Force Multiplier

A single supply chain failure can impact:

• multiple applications

• multiple environments

• multiple organizations

This is why supply chain attacks are attractive to attackers seeking scale and persistence, rather than one-off exploitation.

Once trust is compromised upstream, downstream defenses become irrelevant.

Transition to Attack Scenarios

Understanding what a software supply chain failure is provides the foundation. The next step is to see how these failures are abused in practice and what attackers actually target during offensive testing.

Common Software Supply Chain Attack Scenarios

Software supply chain attacks rarely target the final application directly. Instead, attackers focus on components, processes, and relationships that the application implicitly trusts.

These scenarios represent the most common ways attackers abuse the software supply chain in real-world environments.

Compromised or Malicious Dependencies

One of the most well-known supply chain attack scenarios involves malicious or compromised third-party libraries.

This can happen when:

• a legitimate package is taken over by a malicious actor

• a new version of a trusted library introduces malicious code

• a popular package is intentionally published with hidden behavior

• a dependency becomes abandoned and later compromised

Because these libraries are installed through trusted package managers, they often:

• run with full application privileges

• bypass security controls

• blend into normal application behavior

From an attacker’s perspective, compromising a widely used dependency can provide access to thousands of applications at once.

Dependency Confusion and Namespace Attacks

Dependency confusion attacks exploit how package managers resolve dependencies across public and private registries.

If an application depends on an internal package that is not properly namespaced or scoped, an attacker can:

• publish a package with the same name in a public registry

• rely on the package manager to install the attacker’s version instead

When successful, malicious code is executed during:

• dependency installation

• build processes

• application startup

This attack is especially dangerous because it requires no direct access to the target organization.

Compromised Build and CI/CD Pipelines

Build systems and CI/CD pipelines are high-value supply chain targets.

Attackers target:

• exposed CI/CD dashboards

• weak access controls on build tools

• leaked tokens or credentials

• insecure build scripts

Once inside the pipeline, attackers can:

• inject malicious code into build artifacts

• modify dependencies at build time

• alter configuration or secrets

• compromise all downstream deployments

A single pipeline compromise can affect every application built by that system.

Tampered Artifacts and Update Mechanisms

In this scenario, attackers manipulate artifacts or updates after they are built but before they are deployed.

This can occur through:

• insecure artifact repositories

• unsigned or unverified binaries

• weak integrity checks

• man-in-the-middle delivery

If the application trusts updates blindly, attackers can introduce malicious code that persists across versions.

Insecure or Untrusted Container Images

Container-based deployments introduce new supply chain risks.

Common attack paths include:

• using untrusted base images

• pulling images from public registries without verification

• running containers with excessive privileges

• embedding secrets in images

Attackers exploit these weaknesses to:

• gain runtime access

• move laterally within environments

• compromise underlying hosts

Containers inherit the security posture of their base images.

Compromised Developer Tooling

Developer environments are part of the supply chain.

Attackers target:

• IDE plugins

• build tools

• package managers

• browser extensions

• developer scripts

Compromised tooling can:

• inject malicious code into projects

• leak credentials

• modify builds silently

Because developers trust their tools, these attacks often go unnoticed.

Transitive Dependency Abuse

Applications often depend on libraries that themselves depend on other libraries.

Attackers abuse this by:

• targeting obscure transitive dependencies

• hiding malicious code deep in the dependency tree

• relying on lack of visibility

These dependencies are rarely reviewed directly, making them ideal hiding places.

Over-Permissioned Dependencies and Services

Some dependencies require access to:

• file systems

• network resources

• cloud APIs

• sensitive data

When these permissions are overly broad, a compromised dependency gains far more power than intended.

Attackers look for components that:

• run with elevated privileges

• have access to secrets

• can communicate externally

Why These Scenarios Matter

These attack scenarios demonstrate that supply chain failures:

• exploit trust, not code

• operate upstream of traditional defenses

• impact multiple targets at once

• persist over time

Attackers do not need to compromise the application directly if they can compromise what the application trusts.

Transition to Testing Perspective

Understanding attack scenarios is only part of the picture. The next step is learning how attackers and pentesters identify supply chain risks during testing.

Testing Perspective (Offensive Mindset)

Testing for software supply chain failures is fundamentally different from testing traditional application vulnerabilities. Instead of attacking inputs, endpoints, or business logic, the attacker focuses on trust relationships and assumptions made during the software lifecycle.

From an offensive mindset, the central question is:

“What does this application trust that I can influence?”

Supply chain testing is about moving upstream, where controls are weaker, visibility is lower, and compromise has broader impact.

Think in Terms of Trust, Not Code

In supply chain testing, code is often the last thing to look at.

Attackers focus on:

• where dependencies come from

• how they are retrieved

• how they are built

• how they are verified

• how they are deployed

Any place where trust is implicit and validation is missing becomes a candidate for exploitation.

Start With Publicly Observable Signals

Many supply chain weaknesses can be identified without access to source code.

Attackers look for:

• dependency names in error messages

• framework and library versions

• container image references

• build metadata in responses

• exposed configuration files

• public repositories and documentation

Public information often reveals what the application depends on.

Enumerate Dependencies and Their Origins

From an offensive perspective, dependency enumeration is reconnaissance.

Attackers try to determine:

• which package managers are used

• which registries are trusted

• whether private packages exist

• how dependencies are named and resolved

This reconnaissance enables attacks such as dependency confusion or malicious package substitution.

Target Build and Deployment Infrastructure

Build pipelines and deployment systems are often more exposed than production applications.

Attackers look for:

• exposed CI/CD dashboards

• weak authentication on build tools

• leaked tokens in repositories

• misconfigured webhooks

• build scripts that trust external input

Compromising the pipeline often yields access to everything it produces.

Test Artifact Integrity and Update Mechanisms

Attackers assess whether the system:

• verifies artifact signatures

• validates checksums

• enforces trusted sources

• restricts update channels

If updates or artifacts are trusted blindly, attackers can inject malicious components that persist across deployments.

Abuse Over-Permissioned Components

Many supply chain components operate with broad privileges.

Attackers identify components that:

• access cloud APIs

• read or write sensitive files

• communicate externally

• run as privileged users

If compromised, these components become powerful internal attack tools.

Look for Indirect Influence Paths

Not all supply chain attacks require direct access.

Attackers look for ways to:

• influence dependency resolution

• publish similarly named packages

• poison caches

• control mirrors or proxies

• manipulate configuration used during builds

Indirect influence is often enough.

Assume Detection Is Weak

Supply chain attacks are attractive because they are:

• low noise

• persistent

• difficult to attribute

Attackers assume:

• changes to dependencies are not closely monitored

• build artifacts are trusted implicitly

• updates are applied automatically

This assumption is often correct.

Supply Chain Testing Is Strategic, Not Tactical

Unlike endpoint testing, supply chain testing is:

• slower

• broader

• more strategic

The payoff, however, is much higher.

A single successful supply chain compromise can:

• bypass multiple security layers

• affect multiple applications

• persist across environments

Hands-on Testing Checklist – Software Supply Chain Failures (A03:2025)

This checklist is intended for active offensive testing and threat modeling, not for compliance reviews. Each item represents a real attacker action or question related to the software supply chain.

The mindset is simple:

If the application trusts it, try to influence it.

1

Dependency Enumeration and Discovery

• Can I identify third-party libraries from responses, errors, or headers?

• Are framework or dependency versions exposed?

• Can I infer package managers or build tools in use?

• Are dependency names visible in public repositories or documentation?

• Are private or internal package names referenced anywhere?

Offensive goal: Understand what the application is built from.

2

Public vs Private Dependency Resolution

• Are internal packages properly namespaced or scoped?

• Is there a risk of dependency confusion?

• Are public registries used alongside private ones?

• Are package sources explicitly defined?

• Are version ranges overly permissive?

Assumption to break: “Our internal packages can’t be replaced.”

3

Dependency Integrity and Verification

• Are dependency signatures verified?

• Are checksums validated?

• Are artifacts pulled from trusted sources only?

• Are tampered packages detectable?

• Are lock files enforced?

Red flag: Dependencies trusted without verification.

4

Transitive Dependency Visibility

• Are transitive dependencies documented or monitored?

• Are deep dependency trees present?

• Are indirect dependencies reviewed?

• Are abandoned or unmaintained packages in use?

• Are transitive updates applied automatically?

Attack surface rule: What you don’t track, you can’t secure.

5

Build and CI/CD Pipeline Exposure

• Are CI/CD dashboards exposed publicly?

• Are build systems protected with strong authentication?

• Are build logs publicly accessible?

• Are tokens or secrets exposed in pipeline configs?

• Are build scripts hardened against tampering?

High-impact target: Anything that produces artifacts.

6

Artifact Storage and Distribution

• Are artifact repositories publicly accessible?

• Are artifacts immutable once published?

• Are release channels protected?

• Are artifacts signed?

• Are old or deprecated artifacts still accessible?

Offensive reality: If attackers can modify artifacts, they control deployments.

7

Update and Deployment Mechanisms

• Are updates automatically applied?

• Are update sources validated?

• Are rollback protections in place?

• Are update channels segregated?

• Are deployment triggers authenticated?

Think persistence: Supply chain compromise often survives redeployments.

8

Container and Image Supply Chain

• Are base images trusted and verified?

• Are images pulled from public registries?

• Are image tags mutable?

• Are images scanned and validated?

• Are secrets embedded in images?

Container rule: An insecure base image infects everything built on top of it.

9

Developer Tooling and Environment Security

• Are developer tools centrally managed?

• Are IDE plugins reviewed?

• Are build tools locked down?

• Are developer credentials protected?

• Are local environments trusted too much?

Reality: Developers are part of the supply chain.

10

Permissions and Execution Context

• Do dependencies run with excessive privileges?

• Do build tools have cloud access?

• Can dependencies access secrets?

• Are execution boundaries enforced?

• Are least-privilege principles applied?

Escalation path: Over-permissioned components amplify compromise.

11

Monitoring and Detection Gaps

• Are dependency changes logged?

• Are unexpected updates detected?

• Are build anomalies monitored?

• Are artifact changes audited?

• Can malicious changes persist silently?

Offensive reality: Supply chain attacks thrive on invisibility.

12

Organizational Trust Assumptions

• Are third parties fully trusted?

• Are vendor updates automatically accepted?

• Are external services implicitly trusted?

• Are trust boundaries documented?

• Are trust decisions periodically reviewed?

Final question: “What happens if this trusted thing turns hostile?”

Final Attacker Mindset

Software supply chain attacks are not about clever exploits — they are about compromising trust at scale.

If the application assumes:

• “this dependency is safe”

• “this update is legitimate”

• “this pipeline is secure”

• “this tool would never be compromised”

That assumption is the vulnerability.