Demystifying SBOMs: Strengthening cybersecurity defenses

The talk opens with the growing danger of software supply chain attacks, pointing to Log4j as an example where teams struggled to find every application using a vulnerable library. The presenters describe a software bill of materials (SBOM) as a nested inventory of components, their versions and suppliers, comparable to an ingredient list on a food label. They explain why government agencies are pushing organisations to adopt SBOMs for inventory, compliance and faster response to newly disclosed flaws.

The middle section is a walkthrough of generating an SBOM from a container image with an open-source generator from Anchore. The output is exported in the CycloneDX JSON format, and the presenters compare it with SPDX, which focuses more on package-level licensing. A recorded demo then passes the SBOM to an open-source vulnerability scanner, which lists severity and whether a fix is available, and shows how those findings can be added back into a single document.

The closing part covers practical challenges. Different SBOM tools can report different components, since manifest-only analysis may miss what the code actually uses. Vulnerability data keeps changing after release even when the component list is stable, so teams need ongoing updates. Prioritising a long list of findings also requires exploitability context. The speakers encourage attendees to build SBOM generation and scanning into their CI/CD pipelines and to look into exploitability exchange formats.