A software bill of materials is an inventory of all software components (proprietary and open source), open source licenses, and dependencies in a given product. A software bill of materials (SBOM) provides visibility into the software supply chain and any license compliance, security, and quality risks that may exist.
SBOMs have become increasingly relevant and valuable in light of the fact that today's applications are generally built with many individual software components, often from a variety of open source and proprietary source packages. Given these complexities, it can be difficult for organizations and individuals involved with the product (manufacturers, operators, buyers) to have full visibility into the software supply chain and any license compliance, security, and quality risks that may exist.
By providing key insights in these areas, SBOMs help organizations quickly identify and remediate potential security vulnerabilities, fulfill licensing requirements, and apply version control best practices.
In this blog, we’ll explore a variety of topics related to a software bill of materials, including benefits, important elements, and tools and templates to help create one.
Elements of a Software Bill of Materials
Although there’s no single standard format for a software bill of materials, elements of an SBOM can be generally broken down into two categories:
- A description of all proprietary and open source components that comprise the software
- A summary of the involved open source licenses
As the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) sees it, there are seven data points that organizations should consider including to describe the nature of software components in a given product. (Of course, it might not always be possible to gather all of this data for each component.)
- Supplier Name
- Component Name
- Unique Identifier
- Version String
- Component Hash
- Author Name
In this context, “relationship” means, essentially, how and where different software components fit together. The table below is an example of how relationship data can be communicated.
With open source software now used in over 90% of modern applications, it’s more important than ever for organizations to be mindful of license compliance requirements. Non-compliant products can put manufacturers at legal, reputational, and financial risk. Accordingly, a software bill of materials should list the licenses that govern components in a particular product, the relationship between specific license and specific software component, and bottom-line compliance obligations. (Many applications are built with a wide variety of different open source libraries that are governed by a variety of licenses. The final product, though, will need to be compliant with the strongest copyleft license of the group.)
Of course, a discussion of these two categories (component and licensing information) wouldn’t be complete without a note about software dependencies. This refers to the common occurrence where proprietary and open source software components pull in other software components, which pull in other software components, and so on.
In theory, a software bill of materials could detail layers and layers of license and component information. In reality, that might not be totally necessary. Here’s how the NTIA sees it:
It depends on the intended audience and the medium of communication. In the case of a machine-readable SBOM, the minimum viable model is one layer deep with the goal of recursing up the supply chain. Many use cases (e.g. the FDA Premarket Submissions for Management of Cybersecurity in Medical Devices) would like to see it as complete as possible, but they understand that complete SBOMs will take time. For most use cases, more complete SBOMs result in greater value.
Software Bill of Materials Delivery Formats and Specifications
Organizations can and do create and publish a software bill of materials in a number of different formats. HTML is a logical choice for a company seeking to publish the SBOM on its website. Plain Text might be the better option if the software bill of materials will be included in documentation or source code. And then there are options like Markdown, PDF, and CSV.
In addition to these common formats, there are several methods designed specifically for delivering SBOMs, including SPDX (Software Package Data Exchange), Software Identification (SWID) Tags, and Cyclone DX.
SPDX, a project run by the Linux Foundation, aims to standardize the way organizations share and consume information found in a software bill of materials. SPDX captures data related to provenance, licensing, and security. The image below outlines what data can be found in an SPDX document.
A Software Identification Tag (or “SWID” for short) is a standardized XML format that identifies and contextualizes the components of a software product. There are four types of SWID tags that come into play at different points in the software development lifecycle (SDLC)
- Corpus Tags: These identify and describe software components in a pre-installation state. Per NIST, corpus tags are “intended to be used as inputs to software installation tools and processes.”
- Primary Tags: The intent of a primary tag is to identify and contextualize software products post-installation.
- Patch Tags: As the name implies, patch tags identify and describe the patch (as opposed to the core product itself). Additionally, patch tags can and do include contextual information on the relationship between the patch and other products or patches.
- Supplemental Tags: The SWID format allows only tag creators to modify corpus, primary, and patch tags. Supplemental tags give software users and software management tools the ability to add helpful contextual information of local utility, such as license keys and contact information for relevant parties.
Organizations have some measure of flexibility when it comes to deciding which tags and specific data elements to include with their products. The SWID specification outlines a number of optional elements and attributes in addition to several required fields.
Ultimately, a minimal valid and conforming tag requires only a handful of elements that describe the software product (such as name and Tag ID) and the entity that created it. For the most comprehensive and up-to-date information on SWID Tag data elements, we recommend viewing the full ISO/IEC 19770-2:2015 Standard.
Per its website, Cyclone DX is “is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.” In other words, it aims to achieve a similar objective to SPDX, SWID, and really all SBOM delivery formats in providing key information about the software components that comprise an application.
Cyclone DX supports four categories of data:
- Bill of Materials Metadata: Information on the application/product itself — the supplier, manufacturer, component the SBOM describes, and any tools used to compile an SBOM
- Components: A complete inventory of proprietary and open source components, including licensing information
- Services: External APIs that the software may call along with endpoint URI’s, authentication requirements, and trust boundary traversals
- Dependencies: Both direct and transitive relationships
Other SBOM Formats
Although SPDX and SWID Tags and to a lesser extent Cyclone DX are particularly common software bill of materials delivery formats, they aren’t the only ones. You can reference the NTIA’s Survey of Existing SBOM Formats and Standards report for a comprehensive list.
Benefits of Creating a Software Bill of Materials
The large number of different software components, dependencies, and licenses that are part of modern applications means managing them can be quite difficult. Without a software bill of materials, processes like conducting a risk assessment, doing due diligence around OSS license compliance, and remediating vulnerabilities can be incredibly time-consuming and painful.
The flip side of this, of course, is that a software bill of materials can go a long way toward managing risks in the software supply chain. Specifically, SBOMs help:
- Accelerate the process of identifying and remediating potential vulnerabilities
- Enable manufacturers to meet attribution requirements that come with the use of many open source libraries
- Reduce unnecessary work that could fall on development teams due to ambiguous supply chains
- Provide transparency and build trust with consumers
- Make it easier for manufacturers to identify and address a broken component post-release
- Avoid significant business disruption in the event of an audit
Software Bill of Materials Use Cases
Clearly, there are many compelling reasons why organizations might look to create a software bill of materials. So, it’s recommended that organizations always create SBOMs for all products (and update them for any new release).
With that said, there are a few specific use cases where a software bill of materials may prove particularly valuable.
Fundraising, M&A, and IPO: A software bill of materials is an important part of the technical due diligence process that comes with a potential merger or acquisition, IPO, or fundraising round. Interested parties may request documentation to better understand the software components — and any license compliance, security, or code quality risks — within your products.
Regulatory Compliance: A software bill of materials doesn’t just help organizations satisfy open source licensing requirements. It also might become a mandatory part of complying with U.S. government regulations — a planned Biden administration executive order would require software vendors to publish an SBOM.
Customer Requests: As software supply chain security becomes an increasingly high priority for organizations across the globe, we expect more and more enterprises to require SBOMs as part of the purchasing and/or renewal processes.
Backward Compatibility: Companies that maintain a large volume of old software are often required to make OSS package updates and upgrades. Of course, it’s much easier to do this with a comprehensive inventory of the OSS in those legacy products.
Tools to Help Generate a Software Bill of Materials
It's safe to assume a software bill of materials will play an increasingly important role in the way business is conducted. But given the volume of data required to craft an SBOM, putting the pieces together via manual processes alone can be quite challenging.
Software composition analysis tools like FOSSA go a long way toward helping organizations build a software bill of materials. They:
- Provide comprehensive and accurate data
- Offer customizable reporting formats
- Automate key steps in the SBOM creation process, saving teams significant time
For more information on how FOSSA can help your organization build or update a software bill of materials, feel free to get in touch with our team.