OWASP Top 10 2025: What changes – and how signed, verifiable supply chains close the gap

If you’ve been anywhere near application security or DevSecOps in the last few years, you’ve felt the shift: the software supply chain has become the battleground. The release candidate of OWASP’s Top 10 for 2025 doesn’t tiptoe around this – it introduces a dedicated category, A03: Software Supply Chain Failures, which formally recognizes that our build systems, dependencies, and release processes are now prime targets.

But this isn’t a dramatic plot twist. It’s more like OWASP saying out loud what practitioners have known for a while: modern software is assembled, automated, and interconnected – and attackers love that.

Before we dive in, let’s set the scene.

A quick look back: traditional risks still matter

For years, OWASP’s category Outdated & Vulnerable Components reminded teams to keep dependencies patched and watch for CVEs. That hasn’t gone away. In fact, it’s still a major part of the story.

We still need:

solid vulnerability scanning,
dependency updates and patching,
and SBOMs that tell us what’s actually inside our software.

But here’s the catch: knowing your components isn’t enough anymore.

Supply chain attacks go after the process, not just the end product. Even a perfectly patched dependency chain won't save you if your CI runner, build script, or signing key gets compromised. Mitigating tools and processes are moot if they can be evaded. OWASP responds by broadening the spotlight – from “what’s in your software?” to “how does your software come into existence?”

Also, this is where we add a modern twist: SBOMs need integrity, too. An SBOM without verifiable provenance is just another document. Signing SBOMs and ensuring they’re tamper-proof pushes transparency into trustworthiness – and makes them actually usable for automated risk decisions.

Where OWASP A03 meets current threats

OWASP’s new category highlights predictable but critical failure patterns: weak CI/CD security, unsigned artifacts, missing provenance, dependency substitution, and weak release approvals. None of this is theoretical – these are exactly the areas attackers have learned to abuse.

The new A03:2025 Software Supply Chain Failures focuses on:

Integrity
Provenance
Trust
Authorization
Build process transparency
Controlled and auditable release workflows

How modern supply chain failures happen

.. and how SignPath can help you avoid or mitigate them.

Insecure or unverified build environments and configurations

OWASP calls out mutable, unverified build agents and pipelines as a major weak spot.

SignPath’s promise: CI pipelines can't unilaterally produce a “trusted” artifact.

Signing and attestation requires policy-governed CI configuration and execution.
Only designated CI systems, pipelines and repositories can initiate signing requests.
Every signing event is traceable back to a specific commit and build source.
A zero-trust policy framework enforces that no single person can create and promote changes all the way to production and customer systems.

This prevents CI infrastructure from silently pushing compromised builds.

Lack of artifact integrity (or weak signing discipline)

Many organizations still store signing keys or credentials in CI variables or developer laptops – exactly the sort of thing attackers look for.

SignPath fixes this: Not only are keys protected from being copied, but policy-based controls also prevent invalid signing requests – even when they originate from otherwise trusted pipelines.

Keys are kept inside secure HSM-backed vaults.
No direct access from developers or CI jobs.
Automated policies (not personal habits) govern what gets signed.

A compromised build pipeline can no longer sign injected malware. That’s a huge shift.

Dependency trust failures

Even though dependency CVEs are “old news,” OWASP expands the topic: downloading unverified packages, skipping signature checks, or allowing dependency substitution are all supply chain failures now.
SignPath provides end-to-end signature verification

SignPath enables organizations to create secure signatures – and attests for them
The SignPath Foundation provides this for more than 200 Open Source projects
Even if a dependency is tampered with, malicious outputs cannot become “official releases” unless they satisfy enforced signing policies
SignPath provides the foundation for component verification – and can automatically verify 3rd party components that are shipped with a release

As a result, only artifacts produced in trusted pipelines and verified workflows can enter the release chain.

Weak or informal release approvals

Too often, “approval” still means a Slack message or a thumbs-up in a pull request. OWASP flags this as a systemic risk.
SignPath enforces approval policies – automated or manual

Separation of duties on multiple levels
Automatic, policy-based approval
Manual quorum approvals – as a rule or for policy exceptions (emergency release)
Integration with Release Management systems
Promotion of release candidates after security and functional testing
Verifiable audit trails

Releases require actual authorization – not just good intentions.

It’s a whole new world

OWASP Top 10 2025’s addition of Software Supply Chain Failures isn’t a trend piece – it’s a reflection of reality. Vulnerability scanners, dependency updates, and SBOMs are still vital, but they’re no longer sufficient. We need verifiable trust, protected keys, policy-driven signing, attestations, traceability, and tamper-evident SBOMs.
SignPath covers this space by making the entire release pipeline provably trustworthy: