Key Concept

SBOM Consumption

Aggregating SBOM Data for Federated Reporting and Actionable Results

What is SBOM Consumption?

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

Software supply chain practices emphasize generating a Software Bill of Materials (SBOMs) for every component release. But what good is the data if it is not put to work? Most SBOM results are left in a text file stored under the build directory. Some teams may add the SBOM to Git as a historical record. If it is stored in Git, it can be found if needed. But most IT teams do little with the SBOM. SBOMs have just become a compliance checkmark. The data generated by SBOMs is critical in the defense of software. For this reason, the cybersecurity industry should focus on generating SBOMs and consuming the data to be used efficiently.

 

SBOM Sources

The Data in SBOMs

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 allows teams to know who to contact for an issue or where to obtain a fix, which improves incident response. 
  2. License information is needed for package dependencies, which is critical for commercial software. 
  3. Viewing dependencies across the ecosystem. Federated SBOM intelligence will show all infected logical applications, making it easier to contain the risk across the organization’s entire software supply chain. 
  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. DeployHub consumes and leverages SBOM data to provide a high level of intelligence for responding to threats and anomalies.

Key SBOM Data Elements

Here are some key elements that are typically included in an aggregated SBOM report:

  • Software Component List: A list of all software components used in the application, including libraries, frameworks, and third-party modules.
  • Version Information: The version number of each software component to track the specific version being used.
  • Dependencies: Information about how different components depend on each other, including the relationships between components and open-source packages.
  • Licensing Information: Details about the licenses associated with each component, which is important for ensuring compliance with open-source licenses and other licensing agreements.
  • Vulnerability Information: Any known security vulnerabilities associated with the software components, if available. This information is crucial for assessing and mitigating security risks.
  • Origin and Provenance: Information on where each component was sourced. This data can help track the software supply chain and identify potential security risks.

SBOMs and Software Supply Chain Risk Management

Software supply chain management requires exposing all hidden open-source objects and dependencies. Software systems consume hundreds, if not thousands, of open-source components. Software systems cannot be properly protected from security issues and cybersecurity threats when these components are unknown. Software Supply chain risk management mitigates risk and exposes software dependencies, allowing for zero-trust policies and practices to be consistently implemented across the organization. Supply chain risk management addresses the lowest security risk level, the open-source packages themselves.

In a software supply chain management practice, the process of code scanning and data gathering is automated by the DevOps Pipeline. Critical in this process is generating the binary or container image’s SBOM (Software Bill Of Materials) report. There are many different levels of SBOMs, from hardware scans to full Application SBOMs with aggregated data.

SBOMs expose:

  • Packages
  • Provenance
  • Secured References
  • Declared Licenses
  • Discovered Licenses
  • License Header or Full License Text

Once the SBOM exposes the low-level package dependencies, the Common Vulnerabilities and Exposures (CVEs) scan information can be easily applied. Adding this process to the DevOps Pipeline hardens cybersecurity and provides the intelligence needed to determine proper mitigation policies and procedures.

Conclusion

SBOMs are key to improving the cybersecurity readiness of digital assets delivered to end users. But to leverage SBOM data, it must be consumed and aggregated with context to the logical application. If SBOM data is not exploited, there is no motivation for IT teams to generate them in the first place. A huge missed opportunity. It is time for the IT and Cybersecurity professionals to leverage SBOM data, and making it usable to software developers can access the information quickly when needed.

DeployHub Aggregates SBOM Data to Produce Decoupled Application SBOM Reports

DeployHub’s open source software supply chain security platform consumes SBOM information. DeployHub aggregates SBOM reports to the application level, providing normalized, detailed information about each component a logical application uses.

Learn More

Start Consuming Your SBOM Insights Today

Signup for DeployHub Team and Begin Leveraging Your SBOM Intelligence for Free

Signup for DeployHub Team, the free SaaS software supply chain security platform. DeployHub Team is based on the Ortelius Open Source project incubating at the Continuous Delivery Foundation.

Signup Today

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 collects Software Bill of Material reports as they are generated across the DevOps pipeline with data aggregation.

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.

SBOMs and Cybersecurity

SBOMs play a key role in solving the cybersecurity challenge. Learn why generating SBOMs is essential to harden the software supply chain.

SBOM Requirements

Learn the US Government’s SBOM requirements and how DeployHub can generate a federated SBOM in a decoupled environment to meet the standards.

Suggested Whitepaper

Aggregating SBOM data to the ‘logical’ Application level is required if you need to produce an Application SBOM in a decoupled architecture. Learn how DeployHub provides aggregated SBOM reports from hundreds of component SBOMs.

Get the Whitepaper

SBOMs in a decoupled architecture

Further Reading