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.”
In practical terms, an SBOM provides a structured representation of the components and dependencies that allow software to function. But Friedman emphasized throughout the conversation that producing an SBOM is not the end goal. The real value comes from what organizations, and their suppliers can do with the information.
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.
That distinction matters because attackers are not limited to vulnerabilities associated with the name of the software vendor.
A smaller vendor’s application may contain an outdated framework, library or open source component with a known weakness. Without component level visibility, an organization may never associate that vulnerability with the commercial product deployed in its environment.
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.
The combination of SBOM and VEX creates the possibility of better prioritization rather than simply more data.
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?
The last question becomes particularly challenging as AI systems become more dynamic and agentic.
Friedman suggested that the answer may increasingly involve a convergence between traditional BOM concepts, logging, information architecture and third party risk management.
The goal is not necessarily to force every piece of information into an AI BOM. Instead, organizations need enough transparency and supporting evidence to reconstruct what happened, understand dependencies, enforce controls and conduct forensic analysis when necessary.
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.
The larger issue, Friedman argued, is determining what information actually needs protection and balancing that concern against the operational value software transparency provides defenders.
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.
Friedman pointed to continuing work among governments, cybersecurity agencies, industry and the open source community to define those expectations and create an ecosystem in which SBOM information can move between suppliers, customers and security tools in a meaningful way.
The ultimate destination is not another compliance document, it is continuous software transparency.
Organizations should be able to understand what their systems depend on, correlate that information with emerging threats and vulnerabilities, determine where actual exposure exists and make risk decisions quickly enough to matter.
Or, as Friedman repeatedly emphasized during the conversation, SBOM is not supposed to solve every cybersecurity problem. It is data. What organizations do with that data is where the security value begins.
Watch or listen to the full SecurityWeek Podcast conversation with Allan Friedman for a deeper discussion on SBOM, AI BOMs, VEX, software supply chain security, continuous monitoring and the future of software transparency.
