An introduction to software bill of materials
Software systems have become more complex, and organizations increasingly rely on third-party components, open-source libraries, and external dependencies to build their applications. While this approach accelerates development, it also introduces risks related to security vulnerabilities, licensing issues, and supply chain attacks. With the complex web of software dependencies and the attack surfaces it opens up, security and compliance have become ever more important. Enter the Software Bill of Materials (SBOM), a critical tool for managing these risks and ensuring the integrity of software products.
What is the Software Bill of Materials?
Bill of materials is a common term used in many other industries. A bill of materials (BOM) is an extensive list of raw materials, components, and instructions required to construct, manufacture, or repair a product or service. There are manufacturing BOM, engineering bills of materials, etc. In software, an SBOM or software bill materials includes all software components used to make a final software product. The SBOM will include details of the software version, patches, dependencies, vulnerabilities, licenses, etc. SBOM has emerged as a critical element of software security and software supply chain risk management.
Why is SBOM important?
There have been several high-profile attacks on the software supply chain over the past decade. The attacks like Codecov, Kaseya, Solarwinds, and most recently the XZ Utils backdoor attack of this year all point to the need for a better understanding of software product dependencies, and the security posture of the entire chain of software dependencies. Identifying such vulnerabilities and mitigating them has a certain cost associated with it, and with more than 80% of any software containing open-source dependencies, this becomes a very critical problem to solve.
It is not just the software industry, but governments also have been taking note of the supply chain security issues and their impact on national security and the economy in general. A pivotal moment in this domain was the US Executive Order 14028 for Improving the Nation’s Cybersecurity. The order outlines how government agencies and vendors should approach protecting their software and the software supply chain, one of the major recommendations being the use of the Software Bill of Materials for greater transparency. Governments across the globe are also enacting similar legislations or guidelines, like the EU Parleament’s NIS2 Directive of 2023 or the CERT-IN ( Computer Emergency Response Team of India ) guideline on SBOMs ( 2024 ).
Key Features and Benefits of SBOM
Component Transparency: SBOM offers complete transparency into the components used in a software application, which helps identify potential security vulnerabilities or licensing issues related to third-party dependencies.
Vulnerability Management: By knowing all the components and their versions, organizations can quickly identify if any part of the software is affected by known vulnerabilities and take appropriate remediation measures. Think of the log4shell vulnerability, any organization that had SBOMs would have been able to quickly protect them because they would know which components of their software infrastructure would be impacted.
Compliance and Risk Assessment: SBOM aids in complying with industry regulations and standards that mandate transparency and disclosure of third-party components. It also helps in evaluating the potential security and legal risks associated with the software.
Supply Chain Security: SBOM enables organizations to better understand and manage their software supply chain, reducing the risk of supply chain attacks and ensuring that components are sourced from trusted vendors.
SBOM Formats
SBOM is a document describing the chain of dependencies, their versions, licenses, vulnerabilities, etc. Organizations use and produce a large number of software products and the only way to generate and maintain SBOMs at scale is if the process is automated. Given that multiple parties will be involved in the generation and maintenance of software dependencies, it works best when everybody uses a common standard to represent SBOMs. Having a standard format for SBOM helps with interoperability, automation, and adoption of industry best practices.
SPDX
SPDX stands for Software Package Data Exchange and was developed by the Linux Foundation's SPDX Workgroup. It was launched in 2010 to address software supply chain challenges. The primary focus is on licenses and other compliances in mind. The current version of SPDX specification is 3.0.1 ( https://spdx.github.io/spdx-spec/v3.0.1/). SPDX is a very comprehensive specification and has been around for a very long time. It is already being used by many industries and products including automotive and healthcare.
CycloneDX
CycloneDX is a standard that provides advanced supply chain capabilities for cyber risk reduction. Predominantly focused on vulnerability and security, CycloneDX was created by the OWASP foundation. The latest specification version is 1.6 and was published in 2024 (https://cyclonedx.org/specification/overview/ ). It is estimated to be in use in over 100,000 organizations
SBOM Classifications
SBOMs can be generated at various stages of SDLC and have different classifications and purposes. CISA - the US cyber security agency classifies the SBOMs into 6 categories as follows
Design - SBOM of software that is in the planning/design phase. Derived from RFC/Design Docs.
Source - Created from the development environment and source files. Usually generated from software composition analysis
Build - SBOM for a release artifact being built in a build environment.
Analyzed - SBOM from analysis of the build artifact with external tooling
Deployed - An sBOM providing the inventory of software existing in a production system.
Runtime - Generates SBOM from the deployed software, its external dependencies, and runtime-loaded components
There are other types of classifications as well, like SaaS BOM, ML BOMs, Hardware BOMs, etc.
SBOM Adoption and DevSecOps
SBOM is a critical tool in the arsenal of DevSecOps teams. So with this knowledge of SBOMs, what should DevSecOps do to adopt them?
SBOM is a new topic for most engineering organizations, so understand it first and then assess and document the use cases within the organization. Evangelize if necessary. Then evaluate tools, there are open source as well as vendor tools, many of which are SaaS-based. An assorted list of tools can be found at the CycloneDX tool center- https://cyclonedx.org/tool-center/
Once you pick the tools, integrate them into your SDLC through CI/CD and automate SBOM generation. There are tools that will help you to save the SBOM data and analyze them. Also, remember that this is not a one-time task and is part of your SDLC. Once you have the SBOM data collected, continuously analyze it, make reports, and share it with the right stakeholders. Also, set alerts and reports on vulnerabilities/licenses/compliances, etc.
This article will give you a fundamental understanding of SBOMs and its uses. In a subsequent article, we will see how to generate SBOMs using open-source tools and examine the SBOM document generated.
