Software supply chain security is steadily moving to the forefront of cybersecurity conversations. In the past, it has been overshadowed by a focus on malware outbreaks, ransomware, endpoint protection, and application vulnerabilities. That changed this month, when OWASP elevated software supply chain failures to third place on its 2025 Top 10 list. The OWASP Top 10, compiled based on a global consensus of security experts and industry data, is recognized as a leading benchmark for identifying the most critical application security risks.

The update is a long-overdue recognition that adversaries no longer occasionally exploit the software supply chain but are actively targeting it. The 10th Annual State of the Software Supply Chain report noted: “What was once a relatively niche method of attack has evolved into one of the most significant cybersecurity threats today.”

As organizations deepen their reliance on open-source components and embrace AI-enabled development, software supply chain risks will become more prevalent. In the OWASP survey, 50% of respondents ranked software supply chain failures number one. The awareness is there. Now the pressure is on for software manufacturers to enhance software transparency, making supply chain attacks far less likely and less damaging.

You Can’t Secure What You Don’t See

Every major supply chain incident exposes that most organizations don’t know exactly what’s inside their own software. Dependency trees run deep. Components are swapped, reused, and inherited across generations of products. Firmware in critical equipment often contains code written a decade ago, maintained by developers who have long since moved on.

Attackers only need one forgotten open-source component from 2014 that still lives quietly inside software to execute a widespread attack. The ability to cause widespread damage by targeting the software supply chain makes these vulnerabilities alluring for attackers. Why break into a hardened product when one outdated dependency—often buried several layers down—opens the door with far less effort?

The SolarWinds software supply chain attack that took place in 2020 demonstrated the access adversaries gain when they hijack the build process itself. The Log4j vulnerability showed how a single overlooked library can set the global cybersecurity community scrambling for weeks. GlassWorm malware revealed just how quickly a vulnerability can be weaponized at machine speed.

The fundamental issue, then, is the lack of software transparency across internal source code, third-party vendors, open-source libraries, and, now, AI-generated code.

Next Steps: Know Your Software

Transparency is what will allow organizations to address software supply chain risk. Achieving that transparency starts with several steps.

Map Your Full Dependency Graph: It’s not enough to know your top-level packages. Attackers exploit the forgotten dependencies six layers deep. Build visibility into your complete dependency tree to identify inherited risk.

Generate Software Bills of Materials (SBOMs) at Build-Time: SBOMs should be generated automatically during every build, not retroactively after software ships. Build-time generation provides visibility into exactly which components are compiled into products for an accurate picture of software components and dependencies.

Demand Continuous Transparency from Suppliers: SBOMs should not be a one-time deliverable. Require ongoing component updates, vulnerability notifications, and attestations from your vendors, integrators, and service providers. The security posture of your suppliers is just as important as your own.

Treat Legacy Code as a First-Class Risk: “Stable” legacy components often go uninspected for years. These aging libraries, firmware blocks, and third-party binaries frequently contain memory-unsafe constructs and unpatched vulnerabilities that could be exploited. Be sure to review legacy code and not give it the benefit of the doubt.

Scan for Vulnerabilities Regularly: With an SBOM in hand, generated at every build, you can scan software for vulnerabilities and remediate issues before they are exploited. In the event of an attack, you can use your SBOM to quickly identify compromised software components.

Incorporate AI-Generated Code Into Your Governance: AI accelerates development, but it can also introduce insecure or unvetted patterns. Treat AI-generated code as an external supply chain input and inspect, track, and verify it.

Make Software Transparency a Cultural Expectation: Tools matter, but culture determines success. Build a development environment where SBOMs, component hygiene, build integrity, and Secure-by-Design thinking are defaults.

OWASP Took an Important Step, Now the Industry Must Take One Too

OWASP is correct to elevate supply chain security as a root cause of software weaknesses today. It forces global recognition of what security teams have been seeing for years, and highlights that software trust is as important as software function.

Now the responsibility shifts to manufacturers, integrators, developers, and operators to confront the risk head-on. That means building transparency into the software creation process, embracing Secure-by-Design principles, and reducing the unmanaged legacy components that quietly accumulate over time.