SBOMs: Are They A Threat Or A Menace?

The talk starts from the growing number of third-party packages in modern software, where a commercial application can pull in ten thousand components and spreadsheets stop being useful for tracking them. It introduces the software bill of materials, borrowed from manufacturing, as a machine-readable inventory of the components used to build a product, covering where each one comes from, its name, its version and optionally its license. The speaker walks through ways to produce one: parsing manifests and lock files, reading package databases, matching files by checksum or approximate similarity, instrumenting builds, and comparing binaries against source.

The middle section covers the two main formats, SPDX and CycloneDX, which the speaker treats as interchangeable containers rather than something to fight over. It also explains the package URL identifier, which maps components to vulnerability databases more cleanly than the older CPE scheme. The speaker argues that keeping component lists secret does not provide real security, and that exchange documents such as VEX are needed to state which known issues actually apply to a given product. Regulatory pressure is covered too, including a recent US executive order and upcoming European rules that could require disclosure, even for some open-source projects.

The closing part identifies the gaps. Few tools can ingest SBOMs on the receiving end, commercial vulnerability feeds often contain invented versions and packages, and the current curation process does not scale. The takeaway is that SBOMs are moving toward becoming a mandate, that the community needs better and more reliable vulnerability data, and that open-source maintainers face a compliance burden they did not sign up for and have no funding to cover.