What is an SBOM?

Today’s software is complex. Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. According to the 2021 Open Source Security and Risk Analysis report, on average, 75% of codebases are made up of open source software. That’s where an SBOM, or software bill-of-materials, comes in.

An SBOM is a structured list of components, modules, and libraries that are included in a given piece of software. Think of them like a list of ingredients that evolves throughout the software development lifecycle as you add new code or components. To ensure the security of the software you create, it is imperative that you maintain a comprehensive list of the components in each release of a software application in order to identify vulnerable and outdated code. You can also use an SBOM to monitor the security of each application post-deployment by identifying the potential impact of new vulnerabilities.

What is an SBOM standard?

To facilitate this widespread adoption of SBOMs, several SBOM standards have been developed to provide a unified structure for both generating SBOMs internally and sharing them upstream with end-users and customers. An SBOM standard is a schema designed to provide a common format for describing the composition of software in a way that is consumable by other tools, such as vulnerability scanners. CycloneDX and Software Product Data Exchange (SPDX) are the most commonly used standards.

CycloneDX

CycloneDX is a lightweight SBOM standard useful for application security contexts and supply chain component analysis. CycloneDX is an open source project that originated in the OWASP community and is guided by a Core Team that provides strategic direction and maintenance of the standard.

The full CycloneDX specification is available online at GitHub or the CycloneDX site.

SPDX

The Software Product Data Exchange (SPDX) is an international open standard (ISO/IEC 5962:2021) format for communicating the components, licenses, and copyrights associated with a software package. The SPDX standard is developed by a grassroots open source project hosted by the Linux Foundation. It draws representatives from vendors, foundations, and system integrators.

A tech team and legal team do the work behind the project. SPDX holds a scheduled monthly status call about their progress.

The full SPDX specification and archives are available on the SPDX site. There’s also an SPDX GitHub repo available.

SBOM Standard Formats, Features, and Use Cases

SPDX CycloneDX
Organization SPDX Workgroup (~20 orgs) under the Linux Foundation A “meritocratic, consensus-based community project” with a Industry Working Group
Initial draft 2010 2017
Format RDF, XLS, SPDX, YAML, JSON XML, JSON
Spec spdx.github.io/spdx-spec

BS ISO/IEC 5962 - 2020

 github.com/CycloneDX/specification
Original use cases License management For use with OWASP Dependency-Track
Unique features Extensive support for expressing license details Extensible format and integrates SPDX license IDs,  pURL, and other external identifiers
Use cases of latest format versions
  • Tracking attributes of multiple software components (e.g. vendor, license, version, etc)
  • Generically describe packages, containers, os distributions, archives, etc
  •  Integrity verification of software components and sub-components

Who uses SBOMs?

Historically SBOMs were used mainly by compliance teams for audits, license monitoring, and to comply with industry-specific regulations, but the rise of software supply chain attacks, including the SolarWinds hack and the recent Log4Shell vulnerability in Log4j, put SBOM use on the radar for both security and development teams alike.

  • Security Teams
    SBOMs play a critical role for security teams, especially when it comes to vulnerability scanning. It is much quicker and easier to scan a library of SBOMs than it is to scan your entire infrastructure from scratch, and in the event of a zero-day, as we recently saw (and continue to see) with Log4Shell, every minute counts. SBOMs can also be leveraged by security teams to prioritize issues for remediation based on their presence and location and to create policies specific to component attributes such as vendor, version, or package type to name a few.
  • Development Teams
    Development teams use SBOMS to track the open source, commercial, and custom-built software components that they use across the applications they develop, manage, and operate. This assists development teams by reducing time spent on rework by helping to manage dependencies, identify security issues for remediation early, and ensure that developers are using approved code and sources.

Fueling the cross-functional use of SBOMs, is the Executive Order on Improving the Nation’s Cybersecurity, in which the SBOM requirement plays a prominent role in securing software supply chains.

Going Forward

Over the course of just a few short years, we have seen the role of SBOMs transition from a “nice to have” to a “need to have” for both development and security teams who have been forced to recognize in a post-Solarwinds world that the software they build is part of a bigger chain that goes beyond the confines of their containers. The use of SBOMs will continue to expand and become the foundational element in securing and managing software supply chains.