PO.3.2 / PS.3.1 NIST SSDF v1.1

SBOM generated per build (CycloneDX / SPDX)

Demonstrate that the organization automatically generates a complete, standards-compliant SBOM in CycloneDX or SPDX format for every software build, ensuring traceability and transparency of all software components.

Description

What this control does

This control requires that a Software Bill of Materials (SBOM) in CycloneDX or SPDX format be automatically generated for every software build. The SBOM inventories all components, libraries, dependencies, and their versions, creating a machine-readable artifact that accompanies each build artifact. This enables supply chain risk management, vulnerability tracking, license compliance, and rapid response to disclosed vulnerabilities in third-party components.

Control objective

What auditing this proves

Associated risks

Risks this control addresses

Inability to identify affected systems when a critical vulnerability is disclosed in a third-party library or dependency
Use of components with known vulnerabilities that remain undetected due to lack of visibility into the software supply chain
License compliance violations from undocumented or improperly licensed open-source components embedded in production software
Delayed incident response due to inability to quickly determine which applications contain a compromised component
Exploitation of transitive dependencies with security flaws that were not directly reviewed or approved
Regulatory non-compliance with emerging software transparency requirements such as Executive Order 14028 and EU Cyber Resilience Act
Inability to enforce component approval policies or block use of deprecated, unsupported, or insecure libraries

Testing procedure

How an auditor verifies this control

Identify all build pipelines and CI/CD systems used to compile and package software artifacts across the organization
Review build pipeline configuration files to verify SBOM generation tools (e.g., Syft, CycloneDX Gradle/Maven plugins, SPDX generators) are integrated into each pipeline stage
Select a representative sample of recent builds across different applications, languages, and build systems
For each sampled build, retrieve the corresponding SBOM artifact from the artifact repository, build system output, or release package
Validate that each SBOM is in a standards-compliant format by parsing it with an independent validator tool for CycloneDX or SPDX specifications
Cross-reference SBOM contents against the actual deployed artifact by comparing listed components to those extracted from the binary or container image using a scanning tool
Verify that SBOMs capture both direct and transitive dependencies with accurate version information by spot-checking deep dependency chains
Interview DevOps personnel to confirm processes for handling build failures when SBOM generation fails and verify evidence of enforcement actions

Evidence required The auditor collects build pipeline configuration files (YAML, Jenkinsfiles, GitHub Actions workflows) showing SBOM generation steps, a sample of generated SBOM files in CycloneDX or SPDX format from recent production builds, artifact repository metadata linking SBOMs to build artifacts, validation tool outputs confirming SBOM schema compliance, and comparison reports demonstrating SBOM accuracy against actual deployed components.

Pass criteria Every sampled build has an associated, standards-compliant SBOM in CycloneDX or SPDX format that accurately reflects all direct and transitive dependencies, and the build pipeline configuration enforces SBOM generation as a mandatory step.

Where this control is tested

Audit programs including this control

Dependency & Supply Chain Audit

Most apps are 90% open-source dependencies. Quick check on SBOM, scanning, pinning, and what happens when a high-CVE…