#SBOM is here: making progress (not excuses)

The panel opens with why software bill of materials (SBOM) matter, especially in safety-critical sectors such as medical devices and industrial control systems. Patching is hard there, and buyers often cannot see what components a product contains. The speakers compare an SBOM to an ingredient list: it does not fix anything by itself, but it lets organizations judge risk, including the transitive dependencies that no one tracks by hand.

The discussion then traces several years of multi-stakeholder working groups that moved from defining SBOMs to making them usable. Topics include the SPDX and CycloneDX data formats, VEX statements about whether a vulnerability actually affects a product, cloud and SaaS scope, and ways to share SBOMs with customers without exposing them publicly. A hospital team presents DaggerBoard, an open-source analysis tool that ingests SPDX or CycloneDX files, maps packages to known vulnerabilities, assigns each SBOM a grade, and supports LDAP sign-in and adjustable grading. A recorded demo walks through the dashboard, vendor grouping and admin settings. The roadmap adds VEX support, an API for asset management and CI/CD systems, and global CVE search across stored SBOMs.

The closing advice is practical. Ask vendors for machine-readable SBOMs during procurement, use standard questionnaires where possible, and treat SBOMs as a basis for ongoing risk decisions. The panelists also stress that smaller, resource-poor organizations need simple tools and guidance, and they invite developers to contribute to open projects.