The Software Bill of Materials (SBOM) has made quite a stir lately. From President Biden’s executive order to further secure our infrastructure to the NHS in Britain, emulating the mandate to improve security and transparency for England’s healthcare system.
Given the sudden popularity of the SBOM and the resulting demand to create one, we feel that it’s essential to understand the ingredients required to formulate an accurate SBOM. After all, if your software bill of materials is missing some of the same data it’s intended to supply, it’s far less valuable. It puts the consumer of that data at a greater security risk.
What is an SBOM?
The formal definition of an SBOM is “A list of components in a piece of software.” More formally, it can be defined as “A complete inventory of 3rd party software used to construct or compose a larger, more complex, product.”
For organizations that build software, commercial or otherwise, 3rd party software is used for various reasons. Most often, however, it’s to save time and resources by leveraging existing open source software to more quickly construct their own and bring their product to market. The use of 3rd party software saves valuable time and resources as up to 90% of any software project is constructed from software sourced through the software supply chain.
The supply chain for today’s open-source dependencies is complicated because developers have multiple options for consuming open source.
- Whole components through dependency managers, known as direct dependencies.
- Transitive dependencies, those dependencies that your direct dependencies require to function and become part of your dependency tree.
- Whole components as libraries through manual download by developer
- Entire projects by forking through SCM
- Whole components as a dynamically downloaded static reference, standard from within HTML files with a <script> tag
- Entire components are imported as code markup languages files typically in HTML within a <script> tag.
- Entire project files are typically imported as they contain source code that is holistically relevant to the project (a Bluetooth driver, encryption algorithm, etc.).
- The snippets of code or embedded open source code are used by developers to fulfill a particular need.
The complexity of the software supply chain leads most companies to use an automated tool to produce the SBOM. Since all Software Composition Analysis (SCA) tools aren’t created equal, it’s essential to understand what value you’re seeking from an SBOM and select your tooling accordingly.
What value does an SBOM provide?
Third-party software as consumed through the open source software supply chain carries inherent risk. These risks are derived from known security vulnerabilities in your projects’ components and legal risks involving the license(s) used to release the software.
A software bill of materials provides an accounting of 3rd party software used in your project and the known vulnerabilities and licenses associated with that software. The resulting report should allow your team to assess the risk of those components.
The goal of your SBOM should be to provide the data your organization requires to assess the risk associated with all of the software sourced through your software supply chain. While risk remediation advice is not included within the SPDX or CycloneDX SBOM formats, most software composition analysis tools offer remediation suggestions. Some offer the ability to upgrade components and even annotate your source code for licenses that require such actions to meet compliance.
What’s in an SBOM?
A software bill of materials should provide you with a complete inventory of all of the 3rd party software in use by your project. As noted above, the list of supply chain resources by which a developer can consume open source is quite extensive. For this reason, it’s essential to understand the complicated nature of producing an accurate software bill of materials.
The accuracy of your SBOM and its format is related to the tool or method used to report, detect and correlate the open source software with its provenance to accurately report the associated licenses and vulnerabilities. SCA tools, their detection capabilities, and resulting SBOM accuracy vary considerably.
SPDX and CycloneDX are both commonly used formats for a software bill of materials, but only SPDX supports granular reporting of the software snippets included in your code. Be sure to choose an SBOM format that supports the level of granularity necessary for your company, your industry, and the intended consumer of the data.
SBOM Formats and Standards
Two standard formats exist today, with more options sure to follow. Each form has its advantages and disadvantages, which are beyond the scope of this article. We encourage you to do your research to ensure that the format you choose meets your needs.
SPDX
The Linux Foundation introduced the SPDX format in February 2010. It’s currently in version 2.2 and, as of August 2021, is an official ISO standard, ISO/IEC 5962:2021.
SPDX is the only format that supports reporting for snippets or embedded open source, which is critically important for those concerned with the legal implications of their software supply chain.
Creating an Accurate SBOM
As previously discussed, developers’ multitude of software sourcing options makes detecting 3rd party software from every supply chain channel extremely challenging. Many organizations today will employ a spreadsheet in an attempt to document their use of 3rd party software. This effort is in vain because they’re missing much of their open source. The information collected only provides for a moment-in-time reference. The 3rd party software is, however, probably changing daily.Various tools exist to create an ad hoc bill of materials. Some are language-specific and offer plugins for your dependency managers to provide a bill of materials upon request. While these plugins are easy to implement, they have a few shortcomings:
- The SBOM is a point-in-time reference.
- The format, while human-readable, must be consumed by another tool to make the results actionable.
- Plugins that focus on the data provided by dependency managers are missing much of the open source in some projects.
A better option is to employ a software composition analysis tool. However, similar to the plugin approach, most modern software composition analysis tools focus exclusively on the data provided by package managers. While this approach, in some cases, provides for an accurate bill of materials, more often than not, it falls significantly short. The reason is that they’re simply ignoring the remaining software supply chain channels, which means these tools are missing all of those associated open source data and potentially exposing your organization to undue risk.When selecting an SCA vendor, the most critical performance indicator is accuracy. Vendors that ignore portions of your software supply chain and miss 3rd party software means your software bill of materials is incomplete, significantly diminishing the value of your SBOM report.Recently Tesla released a large portion of their Autopilot intellectual property due to the use of open source code licensed under the GPL. Tesla uses a high percentage of open source in their vehicles, and it’s pretty standard for embedded software to contain portions of the Linux kernel or tools, such as Buildroot, which is GPL licensed, requiring that the licensee open source their software.
Sadly, most of today’s SCA vendors are focused too heavily on security and ignore the challenging aspects of the legal side of open source software. Your SCA vendor should perform well in both security and license compliance.Lastly, consider a vendor that can produce a holistic SBOM in build-time to ensure that your organization continually monitors and manages your risk rather than relying on a point in time reference that’s quickly outdated. An advanced SCA tool will help you automatically monitor, manage and mitigate the risks associated with your use of 3rd party software. As the market matures, standards and organizations adopt the requirements set forth by the executive order; we predict that the sharing of build-time SBOMs will become standard operating procedures.
The Future of the Software Bill of Materials
In my next article, we’ll discuss the future of the SBOM and how it will be used to share information with consumers of your software as part of the complete, end-to-end software supply chain.
Learn More
For more details on SBOMs and SCA tooling, Click here for our webinar; SBOM Accuracy – Measuring up your SCA Vendor.
Threatrix software supply chain security and compliance risk management platform is a cutting-edge software composition analysis solution. With support for more than 400 languages and embedded open source detection in build time, the Threatrix Truematch algorithm ensures the fastest and most accurate software bill of materials allowing our customers to make immediate use of actionable risk data to reduce MTTR by more than 80%.
