What’s in a Name? Vulnerabilities, SBOMs, and the Challenge of Software Identity
summary
CISA requires machine-readable SBOM data for federal procurement (BOD 22-01 / EO 14028) and treats SBOMs as a transparency layer but says they often produce false positives, so VEX adds machine-readable affected/not-affected status and justifications. Work focuses on CSAF, CycloneDX/SPDX interoperability, purl, CPE, and tools like GetBOM to answer “do I contain log4j?” Four community working groups tackle sharing/exchange, tooling/implementation, cloud apps, and on-ramps/adoption.
AI-written summary · about
chapters (13)
- 0:00Start
- 0:01Justin Murphy
- 0:15Background
- 10:51Challenges with S-Bomb
- 15:05Do We Actually Know What Is in Our Software
- 16:52Dependency Graph
- 20:30Depth Matters
- 21:15The Executive Order
- 24:05Vulnerable versus Exploitable
- 25:20Not all Vulnerabilities Are Going To Be Exploitable
- 31:24Active Working Groups
- 40:05Swed Tags
- 44:32Community Efforts
related talks
22mSBOM and Security Transparency - How it all fits together
26mSBOM today: What is the state of SBOMs?
16mKeynote: SBOM is Coming: Why You Should Care and How You Can Help
35mSBOMs: Navigating the Evolving Landscape of Software Bill of Materials
27mSBOM: The Rest Of the Story
40mDBOM and SBOM: New Options For Better Supply Chain Cybersecurity
45mSmarter Than Your Average SBOM!
51mThe Opposite of Transparency