Software Engineering Institute (SEI) Podcast Series · Members of Technical Staff at the Software Engineering Institute

Getting Your Software Supply Chain In Tune with SBOM Harmonization

·23 min·1 clip

Different SBOM producers and consumers disagree on what counts as a dependency.

1. SEI’s Software Engineering Institute (SEI) podcast episode centers on SBOM harmonization and software supply-chain risk. 2. Matthew Bukovic, Technical Director for Cyber Risk and Resilience in the SEI CERT Division, hosts; Dr. Jesse Jamison, a cybersecurity engineer in the SEI CERT Division, explains the SBOM research. 3. The episode asks how SBOMs can become comparable across tools when software supply-chain decisions depend on them. 4. Jamison says he has a PhD in mathematics, published medical-journal work, and internships at Oak Ridge National Laboratory and NASA Goddard. 5. He describes first encountering cybersecurity through a SOC at Oak Ridge National Laboratory. 6. Bukovic connects SBOM work to interdisciplinary problem-solving and Jamison’s background in graph theory, combinatorics, PDE theory, and functional analysis. 7. Jamison explains SBOMs as a nutritional label or shipping manifest for software. 8. He says an SBOM should let users know exactly what is in a software package before it enters an environment. 9. Bukovic reframes SBOMs as traceability and risk-decision support for specific threats. 10. Jamison describes the 2024 SBOM harmonization plugfest, which Dr. Alan Friedman initiated to compare SBOM tools on standardized software targets. 11. He says the team froze software at certain commits and asked participants to generate SBOMs at the same lifecycle stage. 12. Jamison reports that the SBOMs did not agree, even under those controlled conditions. 13. He identifies minimum SBOM fields as a source of variance, including version strings written as 0.2, V2, or spelled-out formats. 14. He says dependency structure also varied because some tools included build-time or runtime submodules while others did not. 15. Jamison notes that different SBOM use cases, such as asset management and vulnerability management, drive different information needs. 16. He says CISA’s call for information on minimum SBOM elements reflects several findings from the SEI work. 17. Jamison proposes future experiments using a software package with known contents so the team can compare tools against ground truth. 18. He also wants to study how dependency structure affects risk flow, single points of failure, and whether risk percolates uphill. 19. The conversation is technical but conversational, with Bukovic asking explanatory follow-ups and Jamison using practical examples from software and mathematics. 20. Listeners interested in SBOMs, supply-chain risk, or machine-readable standards should listen; listeners wanting a light nontechnical overview may skip it.

As heard by us

SBOM comparability can turn on version strings and dependency choices that different tools, producers, and consumers handle differently.

SBOMs come through here as a practical way to understand software supply-chain risk, but the episode is most useful when it shows how fragile comparison can be. Matthew Bukovic of the SEI CERT Division speaks with Dr.

Read the full review in PlayNext →

Why you'd press play

Want to know why two SBOMs can describe the same software differently?

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from Software Engineering Institute (SEI) Podcast Series