What is a Software Bill of Materials (SBOM)?

Managing the components that make up software systems is crucial for security, compliance, and operational transparency. One essential tool for achieving this is the Software Bill of Materials (SBOM). Understand the definition of SBOM, its common formats, types according to CISA, minimum requirements by NTIA, regulatory aspects globally, and how Software Composition Analysis (SCA) tools support SBOM management.

A Software Bill of Materials (SBOM) is a comprehensive list that enumerates all components used in building a software product. It provides transparency into the software supply chain, detailing dependencies, libraries, frameworks, and other third-party software components. SBOMs typically include information such as component names, versions, suppliers, and licenses.

Common Formats

Several standards and initiatives govern the creation and use of SBOMs, ensuring consistency and interoperability across different industries and regions. Some common SBOM standards include:

SPDX (Software Package Data Exchange): Developed by the Linux Foundation, SPDX is an open standard for SBOMs that facilitates sharing and collaboration on software components’ licensing and compliance information.

CycloneDX: An industry-driven standard supported by the OWASP Foundation, CycloneDX provides a lightweight SBOM format to improve software supply chain integrity.

SWID (Software Identification): Managed by ISO/IEC, SWID tags provide a standardized format for identifying software components and their associated metadata, including versioning and installation details.

Types of SBOM According to CISA

According to the Cybersecurity and Infrastructure Security Agency (CISA), SBOMs can be categorized into six types that coincide with a specific phase of the software development lifecycle (SDLC).

1. A Design SBOM an “SBOM of intended design of included components (some of which may not exist) for a new software artifact.” It is typically derived from a software solution architecture specification, request for proposal (RFP), or another initial concept.
2. A Source SBOM is described by CISA as an “SBOM created directly from the development environment, source files, and included dependencies used to build a product artifact.” A Source SBOM is typically generated from Software Composition Analysis (SCA) tooling with manual clarifications. This manual activity is also called an audit.
3. CISA describes a Build SBOM as an “SBOM generated through the analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its Build, and such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.”
4. The Analyzed SBOM is “generated through analysis of artifacts (i.e. Executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.” This type is typically generated through analysis of artifacts by 3rd party tooling.
5. A Deployed SBOM “provides an inventory of software that is present on a system. This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment.” This type is typically generated by recording the SBOMs and configuration information of artifacts installed on systems.
6. Lastly, the Runtime SBOM is defined as an “SBOM generated through instrumenting the system running the software, to capture only components present in the system, as well as external call-outs or dynamically loaded components. In some contexts, this may also be referred to as an “Instrumented” or “Dynamic” SBOM.”

Another way to categorize SBOM types is based on the level of detail and scope of the software components listed:

1. Package Manifest SBOM: Lists high-level components and versions.
2. File Level SBOM: Includes all files and directories associated with a software package.
3. Component Level SBOM: Provides detailed information about each software component.
4. Compile Time SBOM: Documents components used during the compilation process.
5. Build Time SBOM: Details components used during the software build process.
6. Binary SBOM: Lists components found in the binary executable of the software.

Minimum Requirements According to NTIA

The National Telecommunications and Information Administration (NTIA) recommends minimum requirements for SBOMs, which include:

• Clear identification of all software components and dependencies.
• Accurate versioning information for each component.
• Licensing information for all software components.
• Supply chain information, such as suppliers and sources of software components.

Regulatory Requirements Around the Globe

Regulatory bodies worldwide are increasingly recognizing the importance of SBOMs for enhancing software transparency and security. For example:

United States: Initiatives like the Executive Order on Improving the Nation’s Cybersecurity mandate federal agencies to adopt SBOMs to enhance cybersecurity resilience. US government agencies like the Food & Drug Administration (FDA) that governs medical devices also has SBOM-related regulations of their own.

European Union: Regulations such as the Cybersecurity Act, EU Cybersecurity Strategy, and EU Cyber Resilience Act emphasize the importance of transparency and accountability in software supply chains.

Other Regions: Countries like Japan, Australia, and Canada are also exploring or implementing regulations that require or encourage the use of SBOMs for software security and compliance.

How Software Composition Analysis (SCA) Supports SBOM Management

Software Composition Analysis (SCA) tools play a crucial role in generating and managing SBOMs:

Automated Component Identification: SCA tools automatically identify and catalog all components within a software project, including their versions and dependencies.

License Compliance: SCA tools help ensure that all components in the SBOM comply with relevant licenses, alerting organizations to any potential licensing issues.

Vulnerability Management: By integrating vulnerability databases, SCA tools provide insights into security vulnerabilities associated with each component, enabling proactive risk mitigation.

Integration and Automation: SCA tools facilitate the integration of SBOM generation into DevOps pipelines, ensuring that SBOMs are continuously updated and accurate throughout the software development lifecycle.

In conclusion, a Software Bill of Materials (SBOM) serves as a critical tool for enhancing transparency, security, and compliance in software supply chains. By adopting SBOM practices and leveraging Software Composition Analysis tools, organizations can mitigate risks associated with third-party software components, comply with regulatory requirements, and bolster overall cybersecurity resilience in an increasingly complex digital landscape.