In the years following landmark cybersecurity executive orders and industry-wide mandates, the Software Bill of Materials (SBOM) transitioned from a niche concept to a fundamental compliance requirement. Today, almost every enterprise software pipeline automatically generates a comprehensive JSON or XML manifest of its dependencies.
We finally have visibility into the software supply chain. So why are supply chain attacks still succeeding at an alarming rate?
The answer lies in a growing industry crisis: SBOM fatigue. Security teams have successfully mapped their dependencies, but in doing so, they have unleashed a tsunami of unactionable vulnerability alerts. It is time to evolve from simply cataloging our software to actively defending it.
The Anatomy of SBOM Fatigue
When a modern SaaS application is compiled, it pulls in thousands of transitive dependencies. A standard SBOM scanner will cross-reference these libraries against the National Vulnerability Database (NVD) and flag every known CVE.
For a typical enterprise application, this can result in thousands of critical and high-severity alerts. However, research consistently shows that over 85% of these vulnerabilities are never actually invoked by the application's code.
If a vulnerable function exists in a library but your application never calls that specific function, the risk is effectively zero. Yet, traditional SBOM scanning tools treat it as a five-alarm fire. This leads to severe consequences:
- Alert Ignorance: Developers, overwhelmed by false positives, begin to ignore security dashboards entirely.
- Wasted Engineering Cycles: Security teams spend weeks chasing down patches for vulnerabilities that pose no actual threat.
- False Sense of Security: Teams focus on patching easy, low-risk vulnerabilities to lower their metrics, while complex, highly exploitable attack paths remain open.
The Evolution: VEX and Reachability Analysis
To combat SBOM fatigue, the industry is shifting its focus from presence to exploitability. This is where VEX (Vulnerability Exploitability eXchange) and reachability analysis come into play.
Comparison of a traditional noisy SBOM scanning process versus a VEX-streamlined workflow that eliminates unreachable vulnerability alerts.
A VEX document acts as a companion to the SBOM. While the SBOM says, "This software contains Library X, which has CVE-2026-1234," the VEX document provides the critical context: "This software contains Library X, but it is not affected by CVE-2026-1234 because the vulnerable module is never executed."
Advanced Application Security Posture Management (ASPM) tools now utilize call-graph analysis to trace data flows from user input down to the vulnerable dependency. If a path exists, the alert is prioritized. If no path exists, the alert is suppressed or deprioritized.
3 Steps to Actionable Supply Chain Security
If your organization is drowning in dependency data, you need to pivot your DevSecOps strategy. Here is how to make your software supply chain security actionable:
1. Implement Continuous Reachability Analysis
Stop treating all CVEs equally. Integrate static and dynamic reachability analysis into your CI/CD pipeline. By filtering your SBOM vulnerability alerts through a reachability engine, you can reduce developer alert volume by up to 90%, allowing them to focus exclusively on vulnerabilities that attackers can actually exploit.
2. Operationalize VEX for Vendor Risk Management
If you are consuming third-party commercial software, demand VEX documents alongside their SBOMs. Do not accept a raw list of dependencies; require the vendor to attest to which vulnerabilities are actually exploitable in their specific implementation. Conversely, begin generating VEX documents for your own customers to reduce their inbound support tickets to your security team.
3. Move Beyond Dependencies to Pipeline Integrity
An SBOM only tells you what went into the build; it does not tell you if the build process itself was compromised. To secure the supply chain, you must implement frameworks like SLSA (Supply-chain Levels for Software Artifacts). Secure your CI/CD runners, enforce multi-party code reviews, and cryptographically sign your artifacts. A perfectly patched dependency is useless if an attacker has poisoned the build pipeline to inject malicious code post-compilation.
Conclusion
Generating an SBOM is the starting line of software supply chain security, not the finish line. As attackers develop more sophisticated methods to compromise open-source ecosystems and development pipelines, relying on a static list of ingredients is a recipe for failure.
By embracing reachability analysis, adopting VEX, and securing the pipeline itself, organizations can cut through the noise of SBOM fatigue and build truly resilient software.