Profile Applicability:
Level 1
Description:
A Software Bill of Materials (SBOM) listing all components, libraries, and dependencies used in the software must be generated and digitally signed. This signed SBOM should accompany the software release to provide transparency into its composition and to verify the integrity and authenticity of the components.
Rationale:
Supplying a signed SBOM enhances supply chain security by enabling recipients to validate the software’s contents and detect unauthorized or vulnerable components. Digital signing assures the SBOM has not been tampered with and establishes trust in the software release process.
Impact:
Pros:
Improves transparency and trust in software components.
Supports vulnerability management and compliance.
Enables verification of software integrity and provenance.
Facilitates incident response and audit activities.
Cons:
Requires tooling and processes to generate and sign SBOMs.
May introduce additional steps in release workflows.
Default value:
Many projects do not provide signed SBOMs by default, limiting visibility into software composition.
Audit:
Verify that software releases include a complete SBOM with a valid digital signature. Review signing keys and processes to ensure authenticity.
Remediation:
Integrate SBOM generation and signing into build and release pipelines. Use industry standards like SPDX or CycloneDX for SBOM format. Train teams on the importance and processes of SBOM signing.
References:
SPDX Specification: https://spdx.dev/specifications/
CycloneDX SBOM Standard: https://cyclonedx.org/
NTIA Software Component Transparency: https://www.ntia.gov/SBOM
CIS Controls v8, Control 4 - Secure Configuration of Enterprise Assets and Software: https://www.cisecurity.org/controls/secure-configuration-of-enterprise-assets-and-software/