How to Scale SBOM Creation and Consumption

TL;DR

Scaling software bills of materials requires machine-readable dependency data and a robust ecosystem of creation and consumption tools. An effective SBOM identifies components, suppliers, versions, relationships, data sources, and known gaps, enabling developers, buyers, and operators to assess supply chain risks and respond efficiently when new vulnerabilities emerge.

Transcript

Thank you. Pretty exciting to see folks here, uh, bright and early to talk about SBOM. I'm Alan Friedman, otherwise known as the guy who doesn't shut up about SBOM. Uh, very excited to be here today with Kate. And I'm Kate Stewart. Um, and really excited to actually be back in person and seeing people in person and having hallway tracks as well as ... Read More

Key Insights

• An SBOM is fundamentally a dependency graph that identifies software components and their relationships. Its essential fields include the supplier, component name, version, identifiers for connecting external data, and the source from which the SBOM information was obtained.
• SBOM transparency is comparable to an ingredient list because it reveals what a product contains. The list alone does not protect an organization, however, because users still need tools and processes that transform component data into security, procurement, development, and operational decisions.
• Known unknowns are an important part of accurate SBOM data. A dependency graph should distinguish components known to have no further dependencies from components whose contents remain unexamined, preventing incomplete information from being mistaken for a complete software inventory.
• SBOMs support the entire software life cycle by helping creators track dependencies, buyers assess supply chain and vulnerability risks, and operators respond to newly discovered threats. Many organizations occupy all three roles, making consistent component information useful across multiple internal functions.
• Open source software is central to the scaling challenge because ninety-eight percent of surveyed companies reported already using it. Tooling therefore needs to work effectively for open source communities and make information available close to upstream projects, where fixes can be easier to implement.
• SBOM adoption was expected by roughly seventy-eight percent of surveyed companies during the referenced year. This level of anticipated use creates demand for automation, practical tool discovery, transparent evaluation, and a marketplace that accommodates both open source and commercial solutions.
• Format neutrality is necessary for a healthy SBOM tooling ecosystem. The presenters identify SPDX and CycloneDX as widely used formats, mention SWID, and argue that computers can translate and process the basics because SBOM formats contain well-structured data with substantial interoperability.
• SBOMs can describe different points in the software life cycle, including incoming source or libraries, the output of a final build, built components, and configured or deployed systems. Tool selection must account for which artifact, stage, quality level, and operational task the SBOM is intended to support.

Questions & Answers

Q: What is an SBOM and what information does it contain?

A software bill of materials, or SBOM, is fundamentally a machine-readable dependency graph. It identifies software components and describes how they relate to one another. Core data can include each component's supplier, name, version, identifiers used to connect it with other information sources, and the origin of the data, such as a supplier, an upstream open source project, or a security vendor.

Q: Why is an SBOM compared with an ingredient list?

An SBOM resembles an ingredient list because it provides transparency about what a software product contains. The comparison also illustrates an important limitation: an ingredient list does not independently prevent allergies or enforce a diet. Similarly, SBOM data does not secure software by itself. Organizations need tools and processes that interpret the information and convert it into development, purchasing, security, and operational actions.

Q: How should an SBOM represent unknown dependencies?

An SBOM should explicitly state what is unknown rather than presenting an incomplete dependency tree as complete. For example, it may show that one component contains no additional dependencies while indicating that the contents of another component have not been determined. Recording these known unknowns preserves the distinction between verified absence and missing information, helping downstream users judge the quality and completeness of the data.

Q: How do SBOMs support the software life cycle?

SBOMs help software creators track dependencies during secure development, help buyers and selectors understand supply chain and vulnerability risks, and help operators respond when new risks appear. These uses are connected because many organizations create, choose, and operate software simultaneously. A structured inventory gives each group a shared basis for determining what is present and what may require investigation or action.

Q: Why are scalable SBOM tools necessary?

Scalable tools are necessary because organizations want software transparency quickly and must handle SBOM information across many products and life-cycle stages. Automation is needed for both creation and consumption of machine-readable data. A robust ecosystem must help people locate suitable tools, compare options fairly, support specific tasks, and accommodate open source and proprietary solutions as new tools continue to emerge.

Q: Why must SBOM tooling support open source projects?

SBOM tooling must support open source projects because ninety-eight percent of the surveyed companies reported already using open source software, which flows into the products they assemble and distribute. Solutions designed only for company boundaries would miss a major part of the supply chain. The presenters also emphasize that working close to the source matters because identifying issues upstream can make them easier to fix.

Q: Should SBOM tools support multiple data formats?

SBOM tools should remain neutral across widely used data formats and support practical interoperability. The discussion identifies SPDX and CycloneDX as the two widely used formats at that time and also mentions SWID. The presenters argue that the basics are fairly interoperable and that computers are well suited to handling structured data, making translation and support across communities both possible and desirable.

Q: When can an SBOM be created during software development?

An SBOM can be associated with several points in the software life cycle. It may describe source files or incoming libraries, record what emerges from a final build, document built components, or reflect software as configured and deployed in a system. Because each artifact can be called an SBOM, users must clarify the stage, intended task, quality, and scope before selecting or evaluating tooling.

Summary & Key Takeaways

• An SBOM provides software transparency by documenting what components are present and how they depend on one another. Its basic information includes suppliers, component names, versions, useful identifiers, and data provenance. It should also explicitly represent known unknowns, such as a component whose deeper dependency tree has not yet been determined.

• SBOM data supports decisions throughout the software life cycle. Developers can track dependencies as part of secure development, buyers can evaluate supply chain and vulnerability risks, and operators can identify affected software when new risks emerge. Because organizations often create, choose, and operate software, the same SBOM data can serve multiple responsibilities.

• Broad SBOM adoption requires scalable tools for generating and consuming structured data at source, build, component, configuration, and deployment stages. The ecosystem must include open source and proprietary options, remain neutral among widely used formats, support interoperability, provide transparent tool discovery, and leave room for tools and projects that do not yet exist.