Generate an SBOM for the artifact you release

A source manifest describes requested dependencies. A release SBOM should describe the software that the recipient actually receives. Bundling, optional packages, native libraries, and container layers can make those inventories different. Start with one named release artifact and record its digest before collecting component evidence.

Choose the inventory boundary

Decide whether the deliverable is a container image, browser bundle, installer, or server archive. List architectures and platform variants separately when their contents differ. Record whether the inventory includes operating-system packages, application dependencies, embedded code, and bundled tools.

CycloneDX can represent components and direct and transitive dependency relationships. Select a format and schema version that the producer and intended consumers can process. A valid format does not establish that collection found every component.

Attach generation to the release job

Use this procedure as the release record, with links to stored outputs rather than pasted terminal screenshots.

1. Build the approved revision using the release configuration and dependency resolution inputs. Record the build job identifier.
2. Identify the final packaged artifact by cryptographic digest. Do not substitute a mutable tag for this identity.
3. Run the selected inventory tools against that artifact and available build evidence. Record tool versions, options, timestamps, and collection boundaries.
4. Reconcile packaged components with the resolved dependency graph. Investigate embedded libraries, generated bundles, and native files that only one method detects.
5. Validate the document against its declared schema. Check component identities and dependency references with the intended consuming tool.
6. Store the SBOM with its own digest and an explicit association to the release artifact. Retain collection logs and unresolved gaps.

Do not run untrusted package scripts with release credentials simply to obtain an inventory. Keep collection permissions limited and inspect tool failures before accepting an empty result.

Separate inventory from provenance

An SBOM answers what is present within its stated boundary. SLSA provenance describes where, when, and how an artifact was produced. Preserve both records when available, but do not label an unsigned inventory as verified build provenance.

Before publishing the release, select several components from the packaged output and locate their entries in the SBOM. Include a transitive package and a native or system component where applicable. Record exclusions explicitly. The acceptance record should let another engineer locate the same artifact, repeat the collection, and understand why any component remains unidentified.