Understanding SBOM Consumption

Defining SBOM Consumption

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 Key Concepts

Understanding SBOMs

Software Bill of Material has finally been recognized as an essential tool in the security toolbox. In this article, we review what to know about Software Bill of Materials.

SBOM Management

SBOM management is the process of tracking Software Bill of Material reports as they are generated across the DevOps pipeline.

SBOM Automation

SBOM automation automatically generates a list of all software components, libraries, and dependencies that make up a software application as part of your DevOps Pipeline and then consuming the data.

Federated SBOMs

View a Federated SBOM for a decoupled microservice application. DeployHub aggregates ‘logical’ application SBOMs for every service release.

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.

Conclusion: SBOM Consumption

SBOMs are key to improving the cybersecurity readiness of the software we produce. The issue with SBOMs is that the data they produce is not consumed or used.

If the data is not being exploited, there is no motivation to generate SBOMs which results in a lack of SBOM adoption. Forcing development teams and vendors to generate SBOMs without SBOM consumption becomes simply busy work with no actionable results. Methods for SBOM consumption is the next journey in application security and will be the basis for establishing zero trust policies and development practices that improve the safety and quality of the global software supply chain.


Centralizing all SBOM Data with DeployHub

DeployHub’s SBOM automation tool centralizes ‘evidence store’ SBOM data and continuously aggregates the information to the critical level, the ‘logical Application.’ DeployHub provides the insights needed to harden the security of the software your end users consume. DeployHub’s Dashboard provides a view into each Component Version’s SBOM and each “logical’ Application Version’s SBOM, even in a decoupled microservices architecture.

Aggregated Application SBOM and CVE


DeployHub Aggregates SBOM Data Across the Organization

By gathering the SBOM data, DeployHub makes it easy to show where a particular package is being consumed and where it is running. In other words, DeployHub can easily answer the question, “Where is log4J running?” A simple query against the DeployHub data store will provide the answer:

log4j search


Log4J results


Further Reading on Supply Chain Security:

Get Started – Give DeployHub a Try: