Understanding SBOM Consumption

• Defining SBOM Consumption
• SBOMs and Cybersecurity Readiness
• SBOMs Do Little Without SBOM Consumption
• SBOM Consumption from Multiple Sources
• SBOM Key Concepts
• SBOM Consumption – Why the Data is Important
• Conclusion
• Centralizing all SBOM Data with DeployHub
• DeployHub Aggregates SBOM Data Across the Organization

Why Generate an SBOM if You Don’t Use the Data?

Generating an SBOM is only useful if you consume and act upon the SBOM data. SBOM’s provide little use sitting in a text file under the build directory, or even stored in Git as an historical record. When a serious cyber hack occurs in your software supply chain, you need to rapidly respond to the attack. Knowing who uses the nefarious package or code is required. SBOMs can tell you that, but if the information is not federated, you may be looking at a long process to sort out where all the SBOMs are, and sort through the data.

SBOM Consumption (Software Bill of Materials) is the process of harvesting, storing, and using the data derived from SBOMs generated or received across the entire organization. Consuming SBOM data provides a comprehensive view of an organization’s security profile and provides the basis for security policies and actions. Discussions around SBOMs have focused on the generation of the data, not the consumption of the data. There is little purpose in generating SBOMs if the data is not leveraged. This article explores why SBOM consumption is critical in building a safer and more secure software supply chain.

SBOM Consumption – Why the Data is Important

SBOMs provide different levels of information, which are key to providing the transparency needed to improve cybersecurity readiness. SBOMS provide: 

1. The provenance of the package dependencies, allowing teams to know who to contact for an issue, or where to obtain a fix from, which improves incident response. 
2. License information for package dependencies which is something critical for commercial software. 
3. Graphing of your dependency ecosystem. SBOM graphs will show where you may have multiple dependencies doing the same thing, the concentration of risk associated with one package across the organization, or better management of the procurement of external components. 
4. An SBOM generated during the build step will expose all source and package dependencies used to create your artifact (.jar, .exe, .npm, etc.). An SBOM generated at this level shows what source code you need to address when an anomaly is found in the artifact (source to artifact SBOM). It also provides a level of accuracy that cannot be obtained by scanning applications after they’re built.
5. SBOMs are the foundation for zero-trust policies. SBOM specifications include showing digital signatures if the package has been signed. 

Source: OpenSSF “SBOMs, So Far, So Good, So What?” by Vincent Danen and Tracy Ragan

Knowing the above, it is clear why SBOM consumption is so critical. It is time to move beyond just generating SBOMs and instead begin the journey of consuming and leveraging the data that SBOMs provide.