Overview
On the SecurityWeek Podcast, Allan Friedman, a pioneer of the Software Bill of Materials (SBOM) movement, discussed where software transparency is heading. The conversation covers why knowing what is inside software is only the beginning, how AI is complicating software supply chain visibility, and what organizations should do with SBOM data once they have it.
This summary is based on SecurityWeek's published description of the episode rather than a full transcript.
Key themes
- An inventory is the start, not the goal. An SBOM lists components; the value comes from matching it against vulnerability and exploitation data and acting on the result.
- AI complicates visibility. Models, datasets, prompts, and agent tooling are new kinds of components that traditional SBOMs do not capture, which is the motivation behind the AI BOM concept.
- Operationalizing SBOM data. Organizations that collect SBOMs need processes to ingest, correlate, and prioritize them, or the data goes unused.
What to do now
- Generate SBOMs in CI for the software you build, in a standard format such as SPDX or CycloneDX.
- Request SBOMs from critical vendors and store them where you can query them during an incident.
- Correlate against known-exploited vulnerabilities (for example, CISA KEV) so a new advisory maps to affected assets in minutes.
- Start tracking AI components: model provenance, third-party model APIs, and agent plugins or MCP servers in use.
- Pair SBOMs with VEX data to cut noise from components that are present but not exploitable.
Why it matters
Recent supply chain compromises across package registries and CI tooling show that fast answers to "are we using this component?" shape incident response. As AI components enter the stack, the same question needs to cover models and agent tooling as well.