Software Supply Chain Failures: From Dependencies to Deployment

Software Supply Chain Failures is one of the larger changes in the OWASP Top 10:2025. It expands the earlier focus on vulnerable and outdated components to include more of the process used to build, distribute, and update software.

My notes for this category started with dependencies and then widened to repositories, developer tools, build systems, artifact storage, and deployment permissions.

Each of these can influence the software that reaches users.

Following the path to a release

A hypothetical application might begin with source code in a repository. It then pulls in third-party packages, runs through a build pipeline, produces an artifact, and deploys that artifact to an environment.

There are trust decisions at each stage:

Which package sources are allowed?
Who can change the source code or pipeline?
What credentials are available during a build?
Where is the release artifact stored?
How is the artifact selected and verified before deployment?

Developer workstations and extensions are part of that picture too. Tools with access to source code, credentials, or publishing permissions can affect more than the individual machine where they run.

Dependencies include other dependencies

The libraries listed directly by an application may bring in additional libraries of their own. These transitive dependencies make the full inventory larger than the list a developer initially chooses.

A software bill of materials, or SBOM, helps record the components included in software. Keeping that inventory current can make it easier to investigate whether a new advisory affects an application.

The inventory still needs a process around it. Someone needs to review relevant findings, assess the risk, decide on a response, and track the change.

Known vulnerabilities are one part of the problem

A component can contain an accidental vulnerability. A software delivery process can also be compromised so that an attacker introduces a malicious change.

Those situations require overlapping but different controls. Checking versions against known vulnerability information is useful, while controlling publishing access and verifying artifact origin and integrity address other parts of the risk.

A signature can help verify who signed an artifact and whether it has changed. That assurance depends on the trust placed in the signer and the protection of the signing process. It does not establish that the software is free of vulnerabilities or malicious behavior.

Prevention ideas from the reading

The OWASP guidance points to an ongoing process:

Track direct and transitive dependencies, including the versions actually deployed.
Remove unused components and tools where possible.
Monitor relevant vulnerability information and security advisories.
Obtain components from trusted sources and verify their origin and integrity where supported.
Protect repositories, build systems, developer tooling, and artifact stores with appropriate access controls.
Limit credentials and permissions to what each stage needs.
Review changes to pipeline definitions and other release-critical settings.
Test updates and deploy them using a risk-based process, with staged rollouts where appropriate.

Timeliness matters. A regular patching schedule should still allow a faster response when the exposure and impact justify it.

Questions I am keeping with this category

If an advisory appeared for a library tomorrow, could the team identify which releases use it?

If a build credential were exposed, what could it access or change?

Could someone change the pipeline and release code without an appropriate review?

Could the team trace a deployed artifact back to its source and build?

These questions connect the category to practical evidence: inventories, permissions, reviewed changes, build records, and release artifacts.

My takeaway

This section of the reading expands the scope of application security to the process that produces the application. Dependencies matter, and so do the systems and permissions that allow those dependencies and the application's own code to become a release.

The next post covers Cryptographic Failures, with a focus on data protection and key management.

Sources and further reading