Deep dive into software bill of materials standards

What is a software bill of materials (SBoM)?

SBoM is a list of tools including libraries, modules, and components that are used in a specific piece of software. It is based on a manufacturing bill of materials, which is an inventory of all the elements involved in a product. Manufacturers in the automotive industry, for example, keep a comprehensive bill of materials for each vehicle. The parts made by the original equipment manufacturer and from third-party vendors are listed in this BoM. When a problematic item is detected, the automaker can determine which vehicles are affected and inform owners of the need for repair or replacement.

It is important to create an SBoM to ensure the security of the software and developers should maintain a complete list of components in each release of a software application to identify vulnerable and obsolete code. Additionally, SBoMs can be used to monitor the security of each application after deployment by identifying the potential impact of new vulnerabilities.

The need for a software bill of materials

The major advantage of having an SBoM is that it allows enterprises to control risk by enabling early identification and mitigation of vulnerable systems or license infringing source code. Maintaining proper SBoMs will help organizations to measure risk from internal as well as external threats. In addition, it helps cybersecurity vendors to introduce solutions that can use the SBoM in a standardized way and protect software solutions and components from known as well as new vulnerabilities. It will also help cybersecurity vendors to provide recommendations for software patching and to provide auto-remediations to block malicious software from running. In addition, SBoMs can help to improve governance over software licenses. Every software consists of a license that indicates the legal use and distribution of the software. Different codes in supply chain applications can have many different licenses for the individual components. The company deploying any particular application has a legal obligation to comply with the licenses. An SBoM guides the deployer to understand what licenses are required and how to comply with them.

SBoM standards

An SBoM standard is a schema designed to provide a uniform language for describing software composition in a way that other tools, such as vulnerability scanners, can understand. Several SBoM standards have been created to facilitate the wider use of SBoMs by providing a common structure for both creating SBoMs internally and sharing them upstream with end-users and consumers. The most widely used standards are CycloneDX, Software Package Data Exchange (SPDX), and SWID Tags.

• CycloneDX:

CycloneDX is an SBoM specification introduced explicitly for software security requirements and related risk analysis. It is written in XML with JSON in development. It’s designed to be adaptable and flexible, with support for popular build systems. The specification supports SPDX license IDs, a license information indicator from package to source code level, and expressions, as well as provenance and external references, and encourages the use of ecosystem-specific naming conventions. It also supports the Package URL specification and the mapping of components to CPEs out of the box.

Figure 1 Integration of CycloneDX with Dependency Track

• Application of CycloneDX

Checkov’s (a static analysis tool) results can be integrated with CycloneDX XML, which can help users to create an infrastructure as code (IaC) SBoM in a standardized format for use in Security Operation Center (SOC) tools.

Figure 2 How to generate an IaC SBOM with Checkov

• SPDX:

The Software Package Data Exchange (SPDX) is an SBoM specification that defines a standard language for sharing software components, licenses, security information, and copyrights across numerous file formats. An SPDX document can be linked to a single software component, a group of software components, a single file, or even a piece of code. SPDX project is primarily introduced to create and extend a “language” to define the data that can be exchanged as part of an SBoM, and to be able to express that language in multiple file formats (RDFa,.xlsx,.spdx, and soon.xml, .json, .yaml) so that information regarding software content and packages can be quickly collected and shared, saving time and increasing accuracy. This SPDX community is sponsored by the Linux Foundation (LF) and SPDX specification has been adopted as one of the key elements of the Linux Foundation’s Open Compliance Program.

Figure 3 Overview of an SPDX document

• Application of SPDX

Synk, a US-based security platform developer, introduced a tool called snyk2spdx to validate the work on the specification. snyk2spdx uses Snyk test data including the SBoM information and outputs it to SPDX v3.0, including the vulnerability profile.

Figure 4 synk2spdx output

• Software Identification (SWID) tag:

SWID tags are transparent software identification tags that allow enterprises to trace the software installed on their managed devices. The International Organization for Standards (ISO) defined it in 2012 and it was updated in 2015 as ISO/IEC 19770-2:2015. SWID tag files include descriptive information about a specific release of a software product. A SWID tag is applied to an endpoint as part of the software product’s installation process, and then erased by the product’s uninstall process, according to the SWID standard. The presence of a certain SWID tag in this lifecycle correlates to the presence of the software product that the tag defines. SWID tags are used by several standards groups, including the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF).

Figure 5: The lifecycle of software on an endpoint documented by SWID tags

Table 1: SBoM standards, use cases, and features

	SPDX	CycloneDX	SWID tag
Organization	SPDX workgroup (~20 orgs) under the Linux Foundation	A “meritocratic, consensus-based community project” with an Industry Working Group	ISO
Initial draft	2010	2017	2012
Format	RDF, XLS, SPDX, YAML, JSON	XML, JSON	XML
Specifications	SPDX specifications	CycloneDX specifications	SWID Tag specifications
Use cases	License management	For use with OWASP Dependency-Track	Descriptive information about the specific release of a software product
Unique features	Extensive support for expressing license details	Extensible format and integrates SPDX license IDs, URL, and other external identifiers	Provides stable software identifiers, standardizes software information, and enables the correlation of information related to software

Major organizations engaged in SBoM standards developments

• NTIA (National Telecommunications and Information Administration)

The US Department of Commerce’s National Telecommunications and Information Administration (NTIA) is developing a multi-stakeholder approach to reach an agreement on an SBoM’s usage and structure by forming multiple working groups that involve stakeholders and collect data. Some of the active NTIAs are found in these working groups:

1. Framing Working Group: Establishing introductory SBoM documentation for framing the concept of an SBoM to interested parties
2. Awareness and Adoption Working Group: Creating an agreed overview of use cases for achieving the benefits of an SBoM
3. Formats & Tooling Working Group: Performing an ongoing survey of SBoM related tooling, data formats, and standards
4. Healthcare Proof of Concept Working Group: Facilitating and reporting on an ongoing Proof of Concept (PoC) on SBoM usage in the healthcare sector (US)

In Jul 2021, the Department of Commerce and NTIA published a report on the minimum elements for an SBoM: “The minimum elements as defined in the report are the essential pieces that support basic SBoM functionality and will serve as the foundation for an evolving approach to software transparency.”

• CISQ and OMG

The CISQ Working Group “Tool-to-Tool Software Bill of Materials Exchange” is a joint working group of CISQ (Consortium for Information & Software Quality) and the OMG (Object Management Group) to define an exchangeable tool-to-tool BoM metamodel for software (SBoMs) and other items needing BoMs. The first purpose of this working group is to trade SBoMs. The study builds on the NTIA’s Software Component Transparency initiative, focusing on the exchange of SBoMs between and among software development tools that produce, update, manage, orchestrate, and/or otherwise alter, assess, or audit software.

• MITRE Corporation and NIST

MITRE Corporation and NIST introduced an approach for using the SBoM to record and validate software “provenance” (chain of custody, ‘the path of the software between organizations’) and pedigree (lineage, ‘record of origin steps in the software supply chain’)

• The future of SBoMs

With rising software complexity and an increasing number of cyber-attacks, SBoMs are expected to grow in popularity and become a critical component of controlling and securing software supply chains. According to President Biden’s Cybersecurity Executive Order 14028 issued in May 2021, it is mandatory to provide SBoMs for any company selling software solutions to the federal government. If we see such mandates globally, SBoMs will become a “need to have” rather than a “nice to have” model for security as well as development teams.