During a CI/CD pipeline setup, at which stage should the Software Bill of Materials (SBOM) be generated to provide most valuable insights into dependencies?

The build process is the most effective stage for generating a Software Bill of Materials (SBOM). During this phase, all source code, libraries, and third-party dependencies are definitively resolved and compiled into the final software artifact (e.g., a container image or executable). Generating the SBOM at this point ensures it is an exact, accurate inventory of every component and its specific version included in the deliverable. This provides the most valuable and actionable data for security scanning, license compliance, and vulnerability analysis before the artifact proceeds to testing and deployment, aligning with secure software development lifecycle principles.

A. During testing: Generating an SBOM during testing is suboptimal because the artifact has already been built. The goal is to analyze components as they are assembled, not after the fact.
B. Before committing code: An SBOM generated at this stage would be based on a developer's local environment, which may not accurately reflect the final dependencies resolved by the CI server.
D. After deployment: This is too late in the lifecycle. It negates the primary benefit of an SBOM, which is to proactively identify and mitigate risks before the software is released into a production environment.

1. The Linux Foundation, "Generating a Software Bill of Materials (SBOM)" (2023). This guide explicitly states: "The best place to generate an SBOM is as part of the build process in your continuous integration (CI) pipeline. This ensures that you have an accurate list of all the components that are included in your software, and that the SBOM is always up-to-date." (See section: "When to Generate an SBOM").

2. OpenSSF, "SLSA: Supply-chain Levels for Software Artifacts," Version 1.0 (June 26, 2023). The SLSA framework, which is a project of the Linux Foundation's OpenSSF, requires that the build process generates provenance. This provenance must list the dependencies that were available to the build steps. This directly ties the inventory of dependencies (a core part of an SBOM) to the build stage for ensuring artifact integrity. (See Section: "Requirements," Subsection: "Build requirements," SLSA 3).

3. NIST Special Publication 800-218, "Secure Software Development Framework (SSDF) Version 1.1" (February 2022). The SSDF recommends practices that align with generating SBOMs during the software production phase. Practice PW.5, "Govern and Harden the Build Process," and its task PW.5.2, "Maintain a list of all third-party software components used in each software release," imply that this inventory is created as part of the build process that produces the release. (See Section 4, "The SSDF's Practices").