---
name: devsecops-devsecops-sbom
title: Software Bill Of Materials
description: A SBOM (Software Bill Of Materials) is a structured inventory of all components, dependencies, and licenses in a software application. It provides detailed metadata, including component names, versions, licenses, vulnerabilities, and dependencies, helping organizations track open source and third-party software for security, compliance, and risk management.
last-updated: 2025-04-17
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/devsecops?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Software Bill Of Materials
{: #devsecops-sbom}

A SBOM (Software Bill Of Materials) is a structured inventory of all components, dependencies, and licenses in a software application. It provides detailed metadata, including component names, versions, licenses, vulnerabilities, and dependencies, helping organizations track open source and third-party software for security, compliance, and risk management.
{: shortdesc}

You can easily export your SBOM in standardized formats (SPDX, CycloneDX), and import third-party SBOMs while using VEX data to meet government and customer requirements.



During the pipeline run, there are certain tools that are used to generate SBOMs. The tool currently available to generate a SBOM is:

- [Code Risk Analyzer](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-cra-sbom-generate&format=markdown)

## What are package SBOMs?
{: #package-sbom}

A package SBOM details all information about all the packages that are used in a software project. It provides information on the versions, licenses, and vulnerabilities of each package used. Package SBOMs are generated at a microservice level, a SBOM is generated for each microservice in an architecture.

## SBOM Lifecycle
{: #sbom-lifecycle}

SBOM lifecycle spans across all the steps of microservice deployment (the CI,CD,CC pipeline runs).

- Continuous Integration(CI) pipeline - During the CI pipeline run, a SBOM is generated for each built microservice. 
- Continuous Deployment(CD) pipeline - During the CD pipeline run, a release SBOM is generated for all deployed microservice.
- Continuous Compliance(CC) pipeline - After the CD pipeline run is completed, the CC pipeline continuously monitors the deployed application. During the run of the CC pipeline, the SBOMs generated for each microservice in the CI pipeline are retrieved and scanned. 

![Lifecycle of a SBOM](/images/sbom-lifecycle.png){: caption="Lifecycle of a SBOM" caption-side="bottom"}

### SBOM Lifecycle in the Continuous Integration pipeline
{: #ci-pipeline-sbom}

The Continuous Integration pipeline builds the deployable artifacts from the application repositories. 

When the CI pipeline runs at the `code-compliance-checks` step,  CRA runs and creates a package SBOM for the repository from which the deployed artifact is created. This package SBOM contains information about the packages that are used by each microservice that is being built in the CI pipeline. It gives information about the license, version, and vulnerabilities of each package. 

This package SBOM is stored in the evidence locker of the pipeline for further use during deployment to production.

### SBOM Lifecycle in the Continuous Deployment pipeline
{: #cd-pipeline-sbom}

The continuous deployment pipeline gathers all evidence and generates the change request summary content.

When the deployment to production takes place through the CD pipeline, the package SBOMs that are stored in the evidence locker are fetched. These SBOMs are aggregated to form a release SBOM. The release SBOM is added as an attachment in the change request.

### SBOM Lifecycle in the Continuous Compliance pipeline
{: #cc-pipeline-sbom}

The continuous compliance pipeline periodically scans the deployed artifacts and their source repositories for vulnerabilities, post deployment to production. 

When the CC pipeline runs, it retrieves the previously stored package SBOM that was generated during the CI pipeline run from the evidence locker. The CC pipeline does not re-create the Package SBOMs. 

## SBOM utility for SBOM validation
{: #generate-cyclonedx-sbom-ci-pipeline}

When the pipeline is run, the `SBOM` is added as an attachment to the `com.ibm.code_bom_check` evidence in both `standard` and `cyclonedx` format.
{: note}

The `sbom-utility` tool validates the SBOM by completing a series of default and custom checks to see whether the metadata contains:

* A component at the root level of the SBOM that contains data
* A timestamp
* A `name` and `bom-ref` for each component field
    
To collect evidence for SBOM validation, set `sbom-validation-collect-evidence` to `1`. The evidence is collected as an attachment to `com.ibm.code_bom_check` with the evidence type and tool type as `sbom-utility`. 
{: note}

For more information, see the [`sbom-utility` tool docs](https://github.com/CycloneDX/sbom-utility/blob/main/sbom-validation-tests.md).