SBOM generation: build-time, source, container and runtime approaches

Where and when you generate an SBOM determines what it can tell you. This guide compares source, build, analysed, container and runtime generation and shows how to combine them.

Generation stage defines accuracy

CISA's guidance on SBOM types describes six stages at which an SBOM can be produced: design, source, build, analysed, deployed and runtime ^[1]. CERT-In adopts the same classifications ^[2]. Each stage sees a different slice of the truth, which is why the 2026 CISA Minimum Elements require an SBOM to state its generation context, as well as the name and version of the tool that produced it ^[3].

Comparing approaches

Source and build-time generation

For software you build, generate an SBOM in the pipeline for every release. The NTIA minimum elements state that a new build or release requires a new SBOM ^[4], and CERT-In recommends that SBOMs be generated for each new release and updated for upgrades and patches ^[2]. Language-aware generators read lockfiles and package-manager metadata. For example, cdxgen supports npm, pip and Poetry, Maven and Gradle, NuGet, Go modules, Cargo and others ^[5], and Microsoft's SBOM Tool generates SPDX for build outputs ^[6].

Practical points:

• Commit lockfiles. Without them, generators resolve versions at scan time and results drift.
• Generate after dependency resolution but before packaging, then attach the SBOM to the release artefact.
• Separate production from development and test dependencies, or label their scope.
• Sign the SBOM with the artefact. NIST's SSDF practice PS.3.2 calls for safeguarding provenance data for each release ^[7], and SLSA defines levels of build provenance ^[8].

Container and binary analysis

For container images and third-party binaries, analysis tools inspect the artefact. Syft generates SBOMs from OCI and Docker images, filesystems and archives, covering OS packages and many language ecosystems ^[9]. Trivy can generate CycloneDX or SPDX from images and other targets ^[10]. Analysed SBOMs are useful for checking a supplier's SBOM against what was delivered: if the supplier lists fewer components than your analysis finds, ask why.

Deployed and runtime SBOMs

Build SBOMs describe what was shipped, not what is running. Hot fixes, sidecar containers, plugins and dynamically loaded libraries all create drift. cdxgen can produce an operations BOM (OBOM) describing live system or container inventory ^[5]. CERT-In asks software consumers to update their internal SBOM when patches or mitigations are applied ^[2], which in practice means comparing deployed state with delivered SBOMs.

A combined pattern

1. Generate a build SBOM in CI/CD for every release, signed and stored with the artefact.
2. Generate an analysed SBOM of the final container image and reconcile the two.
3. For supplier software, ingest the supplier's SBOM and verify it with your own analysis.
4. Periodically capture deployed or runtime inventories for critical services and diff them against the release SBOM.
5. Validate every SBOM against your field policy on creation; see how to validate an SBOM.

For tool options, see SBOM tools. Cryptographic assets need a different discovery approach, covered in What is a CBOM?

How IntelliXBOM helps

IntelliXBOM generates SBOMs and ingests CycloneDX and SPDX from build, container and supplier sources, keeping each version with its history. Diffs between versions show where deployed inventories differ from what was delivered, and every SBOM is validated against required-field policies on arrival.