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.
The Data in SBOMs
SBOMs provide different levels of information, which are key to providing the transparency needed to improve cybersecurity readiness. SBOMS provide:
- 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.
- License information is needed for package dependencies, which is critical for commercial software.
- 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.
- 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.
- SBOMs are the foundation for zero-trust policies. SBOM specifications include showing digital signatures if the package has been signed.
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.
- 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.
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
Start Consuming Your SBOM Insights Today
SBOM Key Concepts
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.
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.
- Software Supply Chain Management Catalogs Explored Whitepaper
- Federated Application Security Intelligence
- Software Supply Chain Management
- Supply Chain Versioning with Historical Trends
- Component Impact and Blast Radius
- Logical Application Views in a Decoupled Architecture
- Federated Software Composition Analysis Data