Software Bill Of Materials
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.
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:
What are package SBOMs?
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 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.
SBOM Lifecycle in the Continuous Integration pipeline
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
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
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
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.
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
nameandbom-reffor 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.
For more information, see the sbom-utility tool docs.