Since OWASP unveiled its 2025 Top 10, one of the most-discussed items has been A03: Software Supply Chain Failures. For many in AppSec, this came as no surprise; enterprise software’s reliance on open source has become one of its greatest strengths and arguably its biggest liability. While OWASP’s inclusion/renaming & promotion of this category signals much-needed recognition, it also raises an important question: what does “prevention” really look like in a world where vulnerabilities live inside thousands of versions of thousands of components?

Let’s start by unpacking what OWASP A03 highlights. The category maps to several Common Weakness Enumerations (CWEs), including:

• CWE-1035 – Using Components with Known Vulnerabilities
  
• CWE-1104 – Use of Unmaintained Third-Party Components
  
• CWE-1329 – Reliance on Component That Is Not Updateable
  
• CWE-1395 – Dependency on Vulnerable Third-Party Component
  
• CWE-447 – Use of Obsolete Function
  

Each of these represents a reality security teams face daily: known issues in upstream dependencies, unsupported components in production, and “can’t-upgrade-yet” situations that become permanent states of risk. The OWASP page lists excellent prevention practices such as maintaining component inventories, using automated dependency checks, and verifying provenance. These are vital steps, but they only address part of the challenge. Visibility without viable remediation still leaves organizations exposed.

The Gap Between Knowing and Fixing

If you work in AppSec, you already know the pain. Your SCA tool flags a vulnerability, but upgrading breaks your app or sends developers into dependency chaos. The fix looks simple on paper but turns out to be disruptive in practice. This is where many organizations end up stuck between CWE-1104 and CWE-1329, running unmaintained or un-updateable software, not because they ignore the risk, but because upgrading introduces even greater risk.

OWASP’s guidance focuses on upstream hygiene: vetting dependencies, monitoring advisories, and verifying digital signatures. These are critical foundations. What is missing is a pragmatic approach to closing the gap once a vulnerable version is already deployed. The industry needs to recognize another layer of defense: version-compatible patching in place.

Expanding OWASP’s “How to Prevent” Section

OWASP’s prevention recommendations for A03 would be more complete with one additional line:

Apply backported and version-compatible security patches to existing components when upgrades are infeasible.

This approach already exists in practice. Patching platforms like Seal Security use it by taking the community’s official security fix and backporting it to the exact version in use. The result is something like ejs@2.7.4-sp1—a vulnerability-free, functionally identical version that requires no code changes or breaking upgrades.

This single practice addresses several of the mapped CWEs directly:

• CWE-1035 / 1395: Removes vulnerabilities in known components by applying targeted fixes rather than requiring full upgrades.
  
• CWE-1104: Allows teams to continue using unmaintained libraries safely while planning future migrations.
  
• CWE-1329: Makes non-updatable components effectively updateable again through backporting.
  
• CWE-447: Keeps older APIs usable while patching only the vulnerable logic.
  

This closes the gap between awareness and action. Visibility into vulnerabilities is not enough without a realistic way to fix them safely.

People, Process, and Pragmatism

The tension between security and engineering is rarely about priorities. It is about capacity. Developers are evaluated on feature delivery, not on dependency maintenance. Security teams are responsible for reducing risk but often lack control over the code that introduces it. Patching solutions like Seal help bridge that divide by letting security teams apply safe, tested fixes without forcing developers to refactor, rewrite, or retest entire systems.

In practice this means:

• AppSec can reduce measurable risk without waiting for lengthy upgrade cycles.
  
• Product Security can maintain compliance with frameworks like FedRAMP or PCI even for legacy components.
  
• DevSecOps can integrate automated patching directly into CI/CD workflows without disrupting existing builds.
  

Backported patching does not replace planned upgrades. It buys the time needed to do them carefully while eliminating exposure in the meantime.

Why OWASP Naming It Matters

The best part of OWASP formally naming “Software Supply Chain Failures” is that it validates what practitioners already know: securing dependencies is difficult. It is not neglect, it is complexity. With the category now officially listed, teams can communicate about it more clearly, benchmark their programs, and use it to justify incremental improvements.

Including version-compatible patching as part of OWASP’s prevention guidance would take this a step further. It would acknowledge that while not every component can be upgraded right away, no component should remain vulnerable indefinitely. It offers a path forward that is practical, measurable, and achievable.

Closing Thoughts

The 2025 OWASP Top 10 invites the industry to think beyond visibility and into action. By adding backported patching to the prevention toolkit, we can turn software supply chain failures from an ongoing pain point into a solvable problem.

For security leaders balancing compliance, stability, and delivery, this is not about new tools or buzzwords. It is about smarter processes that make fixing vulnerabilities as routine and low-impact as identifying them.

We help teams create these smarter processes, fixing open source vulnerabilities so you can patch even the most unfixable CVEs away without any painful upgrade processes or breaking changes. To see this in action and give your security and development team hours of time back in the day plus frictionless workflows for remediation, reach out to our team to schedule a demo today.