Share
IN-DEPTH TECH
8 min read
Share
In the previous blog post of the series, I shared case studies of top software supply chain attacks and introduced you to SBOM as a preventive measure. In this post, I'll spotlight SBOMs, and discuss the emergence of SBOM as the new security imperative, its architecture, standards, and aid in combating supply chain attacks. Businesses that lack an SBOM strategy lag behind their competition; Getting on the SBOM movement is critical to prevailing! If you have anything to do with the software industry, you want to get this information, so stay with me!
A software bill of materials (SBOM) is a list of all the components, libraries, and other dependencies that make up a software application, along with information about the versions, licenses, and vulnerabilities associated with each component. They are formal, structured documents detailing the components of a software product and its supply chain relationships. As a bottom line, SBOM is your software's ingredient list or nutrition label.
SBOMs became important as organizations increasingly rely on open-source and third-party software components to build and maintain their applications. These components can introduce security vulnerabilities if they must be adequately managed and updated. They provide a way for organizations to understand what open-source and third-party components are used in their applications and identify and address any security vulnerabilities.
Under specific scenarios, generating and publishing SBOMs is mandatory for compliance with regulations and industry standards that require organizations to disclose the use of open-source and third-party software in their products.
On May 12, 2021, President Biden issued the “Executive Order on Improving the Nation's Cybersecurity (14028).” As a result of this legislation, any vendor that supplies software to the Federal Government will soon be required to provide an SBOM to help secure the software supply chain and mitigate risk.
It has become a business imperative to generate and provide SBOM to customers and auditors as a means of component transparency. Since it is no longer optional, business leaders, software producers, consumers, and operators must lean in and thoroughly understand its implications.
Several proposed standards have sprung up, including CycloneDX, SPDX, SWID, and others.
SPDX (Software Package Data Exchange) is a standard format for communicating a software package's components, licenses, and copyrights. It is commonly used to document the open-source components included in a proprietary software product. SPDX files can be easily read and understood by humans and machines, making it easy to track and manage open-source components in a software project. SPDX format is supported by Linux Foundation, and you can learn more about it here.
CycloneDX is an open-source standard for creating software bill of materials files. It is like SPDX in that it documents the components and licenses associated with a software package, but it is specifically designed for use in software supply chain security. CycloneDX is a more lightweight format compared to SPDX, which is intended to be more detailed. CycloneDX format is supported by OWASP, and you can learn more about it here.
SPDX and CycloneDX are both used to document a software package's components and licenses. Still, SPDX focuses more on managing open-source components and licensing views in a software project. On the other hand, CycloneDx is more focused on software supply chain security and tagged with security-rich metadata so that it can be beneficial and extensible to many advanced security insights use cases. Because of its rich metadata, the CycloneDX format can be complex and verbose as a tradeoff. CycloneDX design provides flexibility in the SBOM structure to balance both verbosity and simplicity, allowing organizations to choose the level of detail required. Thus, CycloneDX can be a lightweight and verbose format based on the use case and configuration.
You must choose a suitable format based on your organization’s unique needs. Using Figure-2 below as a quick summary, we can see how the two standards compare:
A typical SBOM architecture can be laid out as a tree-like dependency graph with the following key elements:
Figure-3 below shows a conceptual SBOM tree of an Acme application
The architecture of an SBOM should be flexible and scalable, allowing it to continuously update to accommodate different types of software and levels of detail to serve the needs of dynamic supply chains.
A typical SBOM can be generated in two ways - during the build process or post-build and deployment using a Software Composition Analysis tool. Trivy and Syft are two noteworthy open-source generators among many other generators, including open-source and commercial. Both use CycloneDX format. It is also important to note that not all SBOMs can be generated equally. Each generator may pick up a few language libraries better than the others based on its implementation. It might take multiple runs through a few different types of generators to draw comprehensive insights.
When one does not suffice, leverage multiple. To create a comprehensive view of your software's ingredients, look for tools to merge the results of multiple SBOMs. Merging heterogeneous outputs and normalizing is a crucial undertaking when using multiple generators, and this is where KubeClarity shines. KubeClarity can set up SBOM generators to run in parallel and unify results to generate a more accurate document.
KubeClarity provides a wrapper for multiple SBOMS, compiles a merged SBOM from multiple open-source analyzers, and delivers a comprehensive SBOM document report. Although KubeClarity does not generate SBOMs, it integrates with popular generators so that a combined document can provide amplified inputs that can be further analyzed using vulnerability scanners. Leveraging multiple SBOM documents can improve visibility into software dependency posture. As an extension, KubeClarity can merge vulnerability scans from various sources like Grype and Trivy to generate a robust vulnerability scan report.
In Figure-4 below, notice the right column, two Analyzers (Trivy and Syft) have discovered the same application resources. In the next processing phase, KubeClarity combines the analysis of these two discrete SBOMs and formats the merged SBOM to comply with the input requirements per vulnerability scanner before kickstarting the vulnerability scans.
SBOMs are a means to an end. While they can serve as a disclosure of all the software components that make up your software and improve transparency, a practical use of SBOM documents is to feed them to vulnerability scanners, which will then analyze the SBOMs and generate a vulnerability report detailing all known and fixed CVEs in the software components listed by SBOM. Once the vulnerabilities have been identified, organizations can take action to address them. We will learn more about CVEs and vulnerability management in our next blog.
Putting it all together, a mental map of SBOM in Figure-5 below summarizes what it is, what it is not, and where it is valuable.
Check back on the next post to see how SBOMs serve as vital inputs to vulnerability scanners and lead you to insightful cyber security risk management reports.
---------------------------------
Pallavi Kalapatapu is a Principal Engineer and open-source advocate in Cisco’s Emerging Technology & Incubation organization.
Get emerging insights on innovative technology straight to your inbox.
Outshift is leading the way in building an open, interoperable, agent-first, quantum-safe infrastructure for the future of artificial intelligence.
* No email required
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on agentic AI, quantum, next-gen infra, and other groundbreaking innovations shaping the future of technology straight to your inbox.
