# Are SBOMs Failing? Supply Chain Attacks Rise as Security Teams Struggle to Act on SBOM Data


The software supply chain remains under siege. As organizations worldwide have scrambled to implement Software Bill of Materials (SBOM) initiatives following government mandates and industry best practices, a troubling reality has emerged: having an SBOM isn't enough. Despite the widespread adoption of these visibility tools, supply chain attacks continue to rise, suggesting that security teams are drowning in data but starving for actionable intelligence.


Recent research indicates the culprit isn't the concept of SBOMs themselves, but rather a critical missing layer: governance-driven intelligence that transforms raw SBOM and Vulnerability Exploitability eXchange (VEX) data into explainable security decisions that teams can actually act upon.


## The Problem: Data Without Direction


Security teams today face a paradox. On paper, SBOMs should be revolutionary—a comprehensive inventory of every component in a software application, enabling rapid identification of vulnerable dependencies during supply chain incidents. Yet in practice, many organizations have found that SBOMs generate more questions than answers.


The core challenges:


  • Data volume: A single application SBOM can contain hundreds or thousands of components, making manual triage impossible at scale
  • Incomplete context: Knowing a vulnerable component exists doesn't tell you whether it's actually exploitable in your specific environment
  • False positives: Many listed vulnerabilities may not affect your organization due to configuration, usage patterns, or compensating controls
  • Action paralysis: Security teams lack clear prioritization frameworks to determine which vulnerabilities pose the greatest risk

    • The result is a dangerous stalemate: SBOMs exist, but teams lack the governance structure needed to convert them into strategic security decisions. Meanwhile, adversaries continue exploiting supply chain weaknesses with impunity.


    ## Background: The SBOM Mandate and Its Limitations


    SBOMs emerged as a critical security control following several high-profile supply chain breaches, including SolarWinds and Log4Shell. The U.S. Executive Order on Cybersecurity (2021) and subsequent regulations mandated that software vendors provide SBOMs, positioning them as essential transparency tools for enterprise security teams.


    Initially, the promise was straightforward: visibility equals control. If organizations knew exactly what components comprised their software, they could rapidly identify and mitigate vulnerabilities. The VEX standard (released by NTIA in 2021) was introduced to enhance this capability by allowing vendors to document whether or not their products are affected by known vulnerabilities.


    However, this model assumed a level of maturity in vulnerability management that most organizations simply don't possess. The tool became sophisticated before the process caught up.


    ## Technical Details: Why SBOMs Aren't Enough


    ### The SBOM-to-Action Gap


    A typical SBOM contains:

  • Component names and versions (often multiple representations of the same library)
  • Dependencies and sub-dependencies (some of which may be transitive or unused)
  • License information (increasingly important for compliance)
  • Provenance data (source and attestation where available)

    • While comprehensive, this data alone cannot answer the questions security teams actually need answered:


    | Question | SBOM Can Answer | Intelligence Layer Required |

    |----------|---|---|

    | What components are in our software? | ✓ | – |

    | Are any components vulnerable? | ✓ | – |

    | Can the vulnerability actually be exploited in our environment? | ✗ | ✓ |

    | Which vulnerabilities should we prioritize? | ✗ | ✓ |

    | Do we have compensating controls? | ✗ | ✓ |

    | What's the business impact of delaying a patch? | ✗ | ✓ |


    ### The VEX Shortfall


    Vulnerability Exploitability eXchange (VEX) documents attempt to bridge this gap by allowing vendors to declare whether products are "affected," "unaffected," or "fixed" for specific CVEs. While valuable, VEX data suffers from:


  • Inconsistent adoption: Not all vendors provide VEX documents, leaving gaps
  • Binary judgments: VEX doesn't easily express nuanced scenarios (e.g., "affected only if feature X is enabled")
  • Timing delays: VEX documents are often released days or weeks after vulnerability disclosure
  • Lack of context: VEX documents don't account for organizational configurations or risk tolerance

    • ## The Rise of Supply Chain Attacks Despite SBOM Adoption


    Paradoxically, as SBOM adoption has increased, supply chain attack sophistication has accelerated. According to industry reports, supply chain compromises doubled in 2023 compared to 2022, suggesting that attackers are outpacing defensive investments.


    Why? Consider a realistic scenario:


    1. A vulnerability in an obscure JavaScript library is discovered

    2. The SBOM immediately identifies that 47 applications use the vulnerable version

    3. A VEX document arrives stating "unaffected" (due to configuration)

    4. Security teams begin validation but lack automated tools to verify the claim

    5. Manual review begins, creating a bottleneck

    6. Meanwhile, attackers exploit the component in organizations that haven't yet triaged the finding


    The friction between discovery and action remains the critical vulnerability.


    ## The Intelligence Layer Solution


    Researchers and forward-thinking security vendors are now advocating for a governance-driven intelligence layer that sits between raw SBOM/VEX data and security decisions. This layer would:


    ### Core Functions


  • Normalize SBOM data across multiple formats and vendors
  • Correlate VEX information with organizational context (configurations, controls, policies)
  • Prioritize vulnerabilities using risk scoring that accounts for exploitability, business impact, and organizational factors
  • Track remediation progress and validate claimed fixes
  • Generate explainable decisions that security teams can justify to stakeholders

    • ### Key Capabilities


    Context awareness: The intelligence layer understands your environment—which teams own which applications, which controls are in place, which systems are internet-facing versus internal.


    Automated reasoning: Rather than dumping 500 vulnerabilities on a team, it surfaces the 15 that actually matter to your organization right now.


    Compliance integration: Links vulnerability data to regulatory requirements, reporting obligations, and audit trails.


    Feedback loops: As teams fix vulnerabilities or apply compensating controls, the intelligence layer learns and adjusts future prioritization.


    ## Implications for Organizations


    For security teams, the message is clear: having SBOMs is necessary but insufficient. Organizations that treat SBOMs as a checkbox exercise will continue struggling with supply chain security.


    For enterprises, this represents both a challenge and an opportunity. Those who implement governance frameworks around SBOM and VEX data will gain:

  • Faster incident response during supply chain events
  • Reduced alert fatigue through intelligent prioritization
  • Better resource allocation for remediation efforts
  • Stronger compliance posture with audit-ready documentation

    • For vendors, the gap represents accountability. As scrutiny increases, vendors must:

  • Provide timely, accurate, and detailed VEX documentation
  • Support multiple SBOM formats
  • Include contextual information about exploitability and affected configurations

    • ## Recommendations


    ### For Security Teams


    1. Don't stop at SBOMs alone — implement tooling that adds governance and intelligence on top of raw SBOM data

    2. Establish prioritization criteria — define how your organization will rank and triage vulnerabilities based on risk, not just existence

    3. Automate what you can — use SBOM and VEX data to automatically flag high-risk changes or trigger workflows

    4. Build feedback loops — as you remediate, feed that data back into your SBOM analysis to improve future decisions


    ### For Organizations


    1. Invest in supply chain security governance — designate ownership and establish clear processes

    2. Evaluate SBOM tooling carefully — focus on solutions that add intelligence, not just aggregation

    3. Collaborate with vendors — request SBOMs and VEX documents from all software suppliers

    4. Integrate with existing security programs — connect SBOM analysis to asset management, vulnerability management, and incident response


    ### For Industry


    1. Standardize governance frameworks — establish best practices for converting SBOM data into decisions

    2. Improve VEX documentation — include more contextual information about affected configurations

    3. Develop open intelligence formats — enable better interoperability between SBOM tools and downstream systems


    ## Conclusion


    SBOMs represent a genuine advance in supply chain security transparency. But as the data reveals, tools alone don't prevent attacks. The missing piece is the human and organizational infrastructure needed to act on the data.


    Organizations that recognize this gap and invest in governance-driven intelligence layers will transform SBOMs from compliance exercises into strategic security assets. The rest will continue running faster on the treadmill of supply chain risk, mistaking data collection for actual risk reduction.


    The question isn't whether SBOMs are failing—it's whether organizations will rise to the challenge of using them effectively.