SBOM and AI Vulnerability Discovery: How Your Software Bill of Materials Becomes the Attack Surface Map

A Software Bill of Materials is a machine-readable inventory of every component in a software product. The analogy to a food ingredient label is intentional: just as a food label lets you identify allergens, an SBOM lets you identify components with known vulnerabilities. When a critical CVE is published in Log4j, OpenSSL, or wolfSSL, an organization with a complete SBOM can answer the question 'are we affected?' in hours instead of weeks of manual codebase archaeology. Executive Order 14028, signed in May 2021, required NIST to issue minimum SBOM standards as part of secure software development practices. CISA subsequently translated those standards into procurement requirements for federal software vendors. The mandate exists because the 2020 SolarWinds and Kaseya supply chain attacks demonstrated that organizations often did not know which components their software products contained until after an exploitation event.

Two formats dominate SBOM production today. SPDX (Software Package Data Exchange) is an ISO standard maintained by the Linux Foundation. It was originally designed for license compliance and has been extended for security use cases. SPDX documents are produced in RDF, JSON, YAML, or tagged-value text formats. CycloneDX is an OWASP standard designed specifically for security use cases including vulnerability management, supply chain analysis, and SBOM exchange. It supports a broader set of relationship types and is natively designed for machine-readable vulnerability correlation. Both formats are accepted under CISA and NIST guidance. Most tooling in the ecosystem supports both: Syft, Trivy, and Microsoft SBOM Tool can generate either format. For AI vulnerability management integration, CycloneDX is generally preferred because its VEX (Vulnerability Exploitability eXchange) extension provides a standardized format for annotating SBOM components with known vulnerability status and justifications.

The regulatory picture across major jurisdictions is now clear. In the United States, EO 14028 (May 2021) established SBOM as a component of secure software development practices for federal procurement. CISA's 2023 SBOM guidance extended requirements to critical infrastructure sectors, and OMB M-22-18 set hard timelines for federal agencies to require SBOMs from software vendors. In the European Union, the Cyber Resilience Act entered into force in 2024 with a two-year implementation window. It requires manufacturers of connected products sold in the EU to produce and maintain SBOMs and to report actively exploited vulnerabilities within 24 hours. For organizations that sell software in both markets, compliance requires maintaining SBOMs in formats acceptable to both CISA and EU notified bodies. The EU CRA also includes import controls, meaning non-EU manufacturers selling into the EU market face the same obligations as EU-based manufacturers.

AI vulnerability discovery tools can process SBOMs as structured inputs to perform two distinct operations. The first is known-CVE correlation: the AI ingests the SBOM, extracts every component name and version, and cross-references the list against CVE databases to identify components with known vulnerabilities. This is the standard SBOM vulnerability scanning function performed by tools like Trivy, Grype, and Snyk. The second, more powerful operation is the one Glasswing enables: the AI cross-references SBOM components against its own AI-discovered vulnerability database, identifying components where novel vulnerabilities have been found that do not yet appear in CVE databases. When Claude Mythos discovers a vulnerability in the wolfSSL TLS library and Glasswing coordinates the CVD, every organization with wolfSSL in its SBOM can be notified before the CVE is published. This is the legitimate and valuable use of SBOM plus AI discovery. The adversarial mirror image is the concern.

The same machine-readable structure that makes SBOMs useful for vulnerability management makes them immediately useful for adversaries. An attacker who obtains your SBOM can perform the following operation in seconds: extract all component names and versions, cross-reference against CVE databases and public exploit repositories, filter to components where working exploits exist, and sort by exploit complexity to identify the lowest-effort attack path into your software. Before AI, this cross-reference required manual research over hours. With AI, it is an automated query. The SBOM that took your team weeks to generate and gives you visibility into your attack surface gives an adversary exactly the same visibility the moment they obtain a copy. This is not a reason to avoid SBOM: the benefits of internal vulnerability management far outweigh the risks. It is a reason to apply strict access controls to SBOM distribution and to treat SBOM documents as sensitive security artifacts rather than marketing collateral.

FFmpeg is an open source multimedia library used in video players, conferencing software, streaming platforms, content delivery systems, and embedded media devices. It is one of the most widely deployed software components in the world and has accumulated hundreds of CVEs over its history, including memory corruption vulnerabilities that have been exploited in the wild. Any product with video decoding, encoding, transcoding, or streaming capability likely embeds FFmpeg. Many of those products have SBOMs that explicitly list FFmpeg. When Claude Mythos scans a codebase and identifies a novel vulnerability in FFmpeg's packet parsing or codec handling, the Glasswing CVD process notifies affected partners. But the list of affected products can be derived immediately by any party with access to a corpus of product SBOMs: query for FFmpeg, filter to the affected version range, identify the affected products. The SBOM makes this correlation trivially fast.

SBOM access control requires a tiered model that satisfies compliance requirements without making SBOMs freely available to adversaries. Tier one is internal use: the SBOM is used by your vulnerability management team for continuous monitoring and is stored in a controlled internal repository with access limited to security and engineering staff. Tier two is customer sharing: SBOMs are shared with enterprise customers upon request under a mutual NDA, through an authenticated customer portal, or via a SBOM exchange platform like the CISA SBOM sharing system. Tier three is regulatory disclosure: SBOMs are shared with government agencies under procurement requirements through secure submission portals. Public posting of full SBOMs on open repositories is appropriate only for pure open source projects where the component list is already public by definition. For commercial software, avoid public SBOM publishing and instead provide a contact mechanism for qualified customers to request access.

The SBOM becomes most powerful when it is connected to real-time vulnerability intelligence including AI-discovered findings. The integration architecture has three layers. The generation layer produces SBOMs at build time using tools like Syft or the Microsoft SBOM Tool, automatically including every dependency resolved at build time in CycloneDX format. The monitoring layer continuously cross-references the SBOM against CVE feeds including NVD, CISA KEV, and Glasswing CVD notifications to identify newly relevant vulnerabilities in listed components. The response layer automatically creates vulnerability management tickets when a new high-severity CVE matches a component in the SBOM, pre-populated with the affected component version, fix version if available, and the relevant EPSS score. This pipeline transforms the SBOM from a static compliance artifact into an active component of the vulnerability management program.

The Mythos Brief contains the complete SBOM vulnerability mapping workflow for integrating SBOMs with Glasswing CVD notifications, plus the SBOM access control checklist aligned with CISA guidance and EU CRA requirements.