• A complete list of software supply chain dependencies, including all transitive dependencies including shared libraries such as those written in C and other languages.
• Details about each open source and commercial software component, such as the author/vendor, software license, release version, etc.
• A machine-readable format that can enable organizations to automate SBOM consumption, and integrate it with their existing processes.

In today’s digital landscape, development teams face mounting threats from cyberattacks due to the proliferation of open source licenses, heightening the potential risks associated with unmanaged software components and emphasizing the urgent need for comprehensive Software Bill of Materials (SBOM) solutions to mitigate vulnerabilities and protect against security breaches.

What are SBOMs used for?

Like a standard manufacturing Bill Of Materials (BOM), SBOMs are meant to provide detailed information about how to build a product from its component parts/source code. In manufacturing, the BOM lets manufacturers more easily identify and trace defective and non-compliant parts throughout a product’s lifecycle. Similarly, SBOMs let DevOps and software engineers more easily identify and trace vulnerable or non-compliant components.

For example, SBOMs can be used as a key risk management tool to help:

• Identify and mitigate potential vectors of attack.
• Achieve regulatory compliance.
• Provide compatibility between old software packages and OSS updates.
• Protect customers in the event of a software supply chain attack.
• Ensure that security protections are in place throughout the software development process.
• Manage license compliance.

SBOMs are also a key requirement for software vendors that want to sell to US federal governments and agencies, as first proposed in President Biden’s Executive Order and detailed in a number of documents from the National Institute of Standards and Technologies (NIST) designed to enhance the nation’s cybersecurity.

What are the different types Of SBOMs?

SBOMs adhere to a common format and structure that can be used to describe the composition of any software. The three most popular SBOM standards include:

• CycloneDX – a lightweight SBOM standard from OWASP that’s useful in application security contexts and supply chain component analysis. It aims to provide guiding principles on how to reinforce a risk-based approach to standard development. The CycloneDX SBOM specification provides:
  • Support for XML, JSON, and Protocol Buffers.
  • A large collection of official and community-supported tools that create or interoperate with the standard.
• Software Identification (SWID) tag – contains information about a particular software product version. SWID tags are supported by both the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF). The SWID tag is an established standard for maintaining the security posture of software composition through:
  • Information management
  • Identification of vulnerabilities
  • Compliance support
  • Ensuring secure configurations for computing services
• Software Package Data Exchange (SPDX) – provides a format for communicating the components, licenses, and copyrights of software packages. Originally a grassroots open-source software project hosted by the Linux Foundation, it is now driven by a consortium of vendors, system integrators, and other foundations. The SPDX SBOM is available in a variety of formats, including RDF, XLS, SPDX, YAML, and JSON.

How can SBOMs be used in the software development process?

SBOMs do not track or display known vulnerabilities, generate a risk or compliance score, or even indicate the datedness of components. However, SBOMs do provide key information in a programmatically consumable way (typically JSON, CSV, SPDX or other formats) that can be fed into vulnerability, compliance and risk measurement workflow to ensure the creation of more secure software.

For example, consider the following use cases:

• The name and version of a component listed in an SBOM can be referenced against vulnerability database providers like the US Government’s National Vulnerability Database (NVD).
• The licenses listed in an SBOM can be compared to the overall license for a product’s codebase in order to identify (for example) non-commercially licensed components in a commercially licensed product.
• The name and version of a component can also be used to compare against public repositories/open source ecosystems to identify how recent a release may be, or whether it’s multiple releases behind.

In this way, software vendors can programmatically pull in an SBOM and generate a risk analysis report specific to their organization’s software supply chain security criteria.

How can I generate an SBOM?

Now that the US government has mandated that all US agencies must obtain SBOMs for the software they purchase, a number of software vendors have begun offering both commercial and open source SBOM creation tools:

• FOSSA’s open source SBOM tool is designed to be integrated with version control systems such as GitHub, BitBucket or GitLab.
• The open source SPDX SBOM Generator creates SBOMs in SPDX format from a wide range of package managers and build systems.
• Tern is an open source project that uses the functionality of a SCA tool and Python library to generate an SPDX SBOM for container images and Dockerfiles.
• Artifact repository vendors like JFrog and Sonatype have add-ons to their existing software composition analysis (SCA) vulnerability scanning capabilities that allow them to generate an SBOM via automation.
• The ActiveState Platform lets you create a free account that you can use to generate SPDX SBOMs for your open source language runtime environments. The SBOM includes:
  • Supplier – the name of the software vendor/author
  • Version – the published version of the component
  • Name – the name of the component
  • Relationship – which component is dependent upon other component(s)
  • License – the high-level license of the component

At ActiveState, we understand the critical importance of Software Bill of Materials (SBOM) data in identifying and managing third-party components, enabling organizations to proactively address security vulnerabilities and ensure the integrity of their software supply chain.