Modern software is built on layers of dependencies, open source components, third-party libraries and increasingly, artificial intelligence models and external data sources. For security teams, understanding exactly what is running inside an application has become less of a compliance exercise and more of an operational necessity. That is the foundation behind the Software Bill of Materials, or SBOM.
In a recent episode of the SecurityWeek Podcast, host Brian “SchleiF” Schleifer sat down with cybersecurity policy expert Allan Friedman for a wide-ranging discussion about the origins of SBOM, how organizations should actually use the data, the emergence of AI BOMs, vulnerability management, VEX, and where software transparency may be heading next.
Friedman, who helped drive early government and industry work around SBOM, offered perhaps the simplest explanation for why the concept matters. “Software isn’t written, it’s assembled,” Friedman said. “What’s it assembled out of? More software.”
SBOM Is About Response, Not Just Inventory
Much of the early SBOM conversation focused on whether vendors could generate the documents and whether customers should require them. The more important question today may be: What happens after you receive one? Friedman argues that one of the first indicators of software supply chain maturity is simply knowing that a supplier can generate an accurate SBOM. That capability becomes critical when organizations face the next Log4j style vulnerability, compromise of a major software package, malicious update, or other widespread supply chain event.
A supplier that understands the components within its products can determine its exposure far more quickly than one forced to reconstruct dependencies during an incident. For customers, the same visibility can dramatically shorten response time. Instead of spending days or weeks contacting vendors and attempting to determine which systems contain a vulnerable component, security teams can analyze their software inventory and dependencies directly.
The objective, however, should ultimately be deeper integration. Friedman said SBOM information needs to become another source of enterprise security data, feeding vulnerability management, asset management, procurement and continuous risk management processes rather than existing as a static document stored somewhere for future reference.
Not Every Vulnerability Creates the Same Risk
More visibility can also create another problem: more alerts. Finding that a vulnerable component exists inside an application does not necessarily mean the vulnerability is exploitable within that specific implementation. Friedman highlighted the Vulnerability Exploitability eXchange, or VEX, as an important companion to SBOM. VEX provides a machine processable method for communicating whether a vulnerability actually affects a product.
An application, for example, may contain a vulnerable version of a software library but never use the functionality associated with the vulnerability. VEX can provide the context needed to distinguish between the presence of a vulnerable component and an exploitable condition. That becomes increasingly important as organizations face what Friedman jokingly described as the “vulnerpocalypse”: an environment in which security teams have far more vulnerability information than they have resources to investigate manually.
AI Makes the Transparency Problem More Complicated
The next evolution is already underway. As organizations embed machine learning, generative AI and autonomous agents into applications, traditional software inventories may no longer capture everything security teams need to understand. Friedman described the emergence of the AI BOM as inevitable.
At its core, AI is still software, meaning traditional software components remain relevant. But AI systems introduce additional elements that may need to be documented, including the model itself, the data supporting the model, external data sources and the surrounding infrastructure or “harnesses” used to operate the system. That creates new questions: Where did the model originate? What data was used to support it? What external data is being introduced at runtime? Who owns the model? What happens when an agent dynamically creates a tool, executes an action and then disappears?
Transparency Should Favor the Defender
Resistance to SBOM adoption has often centered on concerns about intellectual property and the possibility that providing detailed information about software components could benefit attackers. Friedman challenged that argument. Modern reverse engineering capabilities already allow determined attackers to analyze software and identify many of its underlying components. Automated attack frameworks and ransomware operations also frequently do not require an SBOM because they simply test systems against known exploits.
Defenders face a different problem. They need to know where vulnerable components exist across potentially thousands of systems. “You know who does need visibility into what’s in a piece of software? Blue Team,” Friedman said. SBOM standards can also support redaction where legitimate proprietary concerns exist, allowing suppliers to disclose the existence of a dependency without necessarily revealing every detail associated with it.
From SBOM to an “Omnibomb”
SBOM may ultimately be only one layer of a much larger transparency ecosystem. AI bills of materials are emerging alongside cryptographic bills of materials designed to identify cryptographic dependencies as organizations prepare for crypto agility and post quantum computing. Hardware bills of materials can provide similar visibility into physical components such as semiconductors. Friedman suggested that those different transparency mechanisms could eventually converge into what he jokingly called an “omnibomb.”
Before that happens, however, there is significant work left to do. Even today’s SBOM ecosystem continues to struggle with interoperability. Two quality SBOM tools analyzing the same software may not necessarily produce identical dependency graphs, making harmonization, minimum requirements and common expectations critical.
