Generate SBOMs

SBOM generation is the entry point to the producer workflow. Downstream activities (validation, signing, distribution, consumer risk assessment) all depend on what the generation step captures. Misidentify a component here, and consumers inherit the error in their risk assessments.

Why and when to generate

Generate an SBOM for every software release. Release-aligned generation is the minimum viable approach. Three other events trigger regeneration:

• Upstream dependency SBOM correction. A supplier fixes a misidentified component or updates license data in their SBOM. Your SBOM inherits the error until you regenerate.
• Metadata or content correction. You discover a wrong version, missing component, or incorrect license in your own SBOM. Fix the data, regenerate, publish a corrected version.
• Generation tool update. A new tooling version produces materially different output for the same input. Regenerate affected SBOMs to capture the improvement.

The EU Cyber Resilience Act will require producers to maintain current SBOMs throughout a product's support period. Generation is not a one-time event; producers regenerate as the software changes.

Lifecycle phases and generation context

The lifecycle phase determines what information is available to the generation tool:

ENISA recommends build-time generation as the primary approach. At build time, the generation tool has access to source code, resolved dependencies, and build artifacts simultaneously. Other phases supplement build-time generation for specific gaps (runtime dependencies, deployed configuration).

Generate from resolved or locked dependencies, not declared version ranges. A manifest declaring ^1.2.0 records what was requested; the lock file records what was built.

Build environment components that contribute material to the build artifact (compilers, linkers, source code generators) belong in the SBOM. Mark them as excluded from the deliverable (e.g., CycloneDX scope: excluded) so consumers can distinguish build tooling from shipped components.

When dependency management is manual (legacy systems, embedded firmware), generation involves manual steps. Capture resolved versions from whatever source is authoritative, document completeness gaps, and store the result in the system of record.

The SBOM generation pipeline

The SBOM generation pipeline is analogous to, but separate from, the CI/CD build pipeline. One produces software artifacts; the other produces the SBOM that describes them. They may share infrastructure and triggers, but their outputs and verification steps differ.

Each generation approach has blind spots:

• Build plugins resolve declared dependencies but miss vendored code and binaries not managed by the build system
• SCA tools detect components through file signatures but may misidentify modified forks
• Binary analysis works from compiled output, identifying components without source-level context
• Runtime instrumentation captures active code paths but requires a running system and misses inactive paths

Layered approaches catch what any single tool misses. A typical pipeline combines a build plugin for dependency resolution with binary analysis for verification. Each additional approach increases confidence at the cost of pipeline complexity.

Verification and correction

Cross-check the generated SBOM against build artifacts immediately after generation. Generation tools misidentify components, miss version changes, and overlook patches or forks of open source projects. A scanner may report the upstream project name when your organization ships a modified version. Correct these errors before handing off to validation.

Composition completeness and authorship

Every generated SBOM should declare whether its component inventory is complete, incomplete, or unknown. Generation tools that skip certain component types or fail to resolve transitive dependencies produce incomplete inventories. Declaring this upfront prevents consumers from treating a partial scan as a full picture.

Record which tools and authors produced the SBOM. Consumers use this metadata to assess scope, expected accuracy, and known limitations of the generation method. See SBOM Requirements for the specific metadata fields.

Incorporating upstream SBOMs

When a supplier provides an SBOM for their component, use it rather than re-scanning the component with your own tools. The supplier has access to build-time information your scanner does not.

Two strategies for incorporating supplier SBOMs:

• Merge. Combine the supplier's component inventory into your product SBOM, producing a single document. Suited for consolidated views where consumers expect one SBOM per product.
• Reference. Link to the supplier's SBOM as an external document, keeping inventories separate. Works well when supplier SBOMs are large or updated independently.

See SBOM Requirements for how to represent third-party SBOMs in your document structure.

Versioning generated SBOMs

SBOM versioning is independent of software versioning. Correcting a misidentified component in the SBOM for software version 2.1.0 produces a new SBOM version, not a new software release.

Each SBOM generation produces a new version with:

• A unique document identifier (e.g., serial number) that persists across versions of the same SBOM
• A version number that increments with each regeneration
• A creation timestamp
• Generation context: what triggered this version, which tools and approaches produced it

Track what changed between SBOM versions. Consumers who received a previous version need to know whether a new version reflects a software update, a data correction, or improved tooling output.

System of record

Store the canonical SBOM in a system of record after generation. Three categories:

• Dedicated SBOM platform (e.g., Dependency-Track). Purpose-built for SBOM lifecycle management: search, versioning, vulnerability correlation, API access. Suited for organizations managing SBOMs across many products.
• Artifact or release repository. Stores the SBOM alongside the software artifacts it describes. Keeps generation output and distribution in one place.
• Source code repository. Version-controlled alongside code. Works for small portfolios or teams with commit-aligned generation workflows.

Choose based on portfolio size, distribution model, and existing infrastructure. Five products? An artifact repository works. Dozens of products across teams benefit from a dedicated platform.