Software Bill of Materials Guide: Build and Use an SBOM

A Software Bill of Materials lists the components included in a software product and how they relate. During a new vulnerability or license issue, an accurate SBOM helps answer whether the affected package is present, which version shipped, and which products depend on it.

A file generated once and forgotten is not enough. The SBOM must be tied to a specific source revision and build artifact, updated in the pipeline, retained with releases, and connected to vulnerability and ownership workflows.

What the topic means

SBOM formats such as SPDX and CycloneDX represent components, versions, suppliers, package identifiers, hashes, licenses, and dependency relationships. Completeness varies by ecosystem and generator. An SBOM describes composition; it does not prove that a component is exploitable, safe, or built from trusted source.

Core principles

Tie the SBOM to an artifact

Record source revision, build identifier, artifact digest, generator, format version, and creation time so the document has a precise subject.

Include transitive dependencies

Indirect packages often carry the vulnerable code. Generate from resolved build state, not only top-level manifest declarations.

Preserve relationships

Knowing that a component exists is less useful without understanding which application, image, library, or service contains it.

Treat accuracy as a pipeline control

Compare SBOM output with lockfiles, images, packages, and runtime evidence; investigate missing or unexpected components.

Step-by-step workflow

1. Define coverage. List applications, containers, libraries, firmware, operating-system packages, vendored code, and build tools that need inventories.
2. Select a standard and generator. Choose a supported SPDX or CycloneDX workflow that understands the ecosystems and artifact types in use.
3. Generate in the trusted build. Create the SBOM from resolved dependencies and final artifacts, then record the source and artifact identities.
4. Validate structure and content. Parse the file, check identifiers and relationships, compare package counts, and review unknown suppliers or versions.
5. Store and distribute safely. Publish with release metadata where appropriate, sign or attest it, control sensitive internal details, and retain historical versions.
6. Connect operational workflows. Use SBOM data for vulnerability triage, license review, customer requests, incident response, and dependency retirement.

Practical example

A container release produces a CycloneDX JSON SBOM after the image is built. The pipeline records the image digest and source commit, validates the document, signs an attestation, and stores both with the release. When a library advisory appears, the team searches shipped SBOMs before opening remediation work.

How to test the control

Test this workflow in a controlled environment before relying on it in production. Begin with “Define coverage” and create three cases: an expected success, a safe rejection, and a degraded or unavailable dependency. Continue through “Select a standard and generator” and “Generate in the trusted build,” recording timestamps, identifiers, logs, and the operator decision. Repeat the exercise after meaningful changes to providers, permissions, dependencies, or architecture. A control is operational only when another team member can follow the documented process and obtain the expected result without hidden knowledge.

Metrics and review cadence

Measure completion and outcome separately. For this topic, track evidence that “Coverage includes direct and transitive components,” “A supported standard is used,” and “The SBOM identifies source and artifact” remain true, then pair those checks with operational signals such as unexpected changes, denied actions, stale ownership, error volume, recovery time, or unreviewed exceptions as appropriate. Review trends rather than celebrating a single pass. A growing exception count may show the workflow is too difficult, while zero alerts may mean the detection path is not functioning.

Operating this in production

Supply-chain defense depends on traceability from source to dependency, build, artifact, and deployment. Pin what must be reproducible, verify integrity at boundaries, minimize publishing privileges, and retain enough provenance to rebuild from trusted inputs. Review the workflow after incidents, major releases, access changes, and meaningful growth. Assign an owner and keep evidence that the control works instead of recording only that it exists.

Common mistakes

• Generating only from package manifests.
• Omitting operating-system and vendored components.
• Reusing one SBOM across different builds.
• Assuming component presence proves exploitability.
• Publishing internal paths and metadata without review.

Duck Cloud tools for the workflow

Inspect JSON SBOMs with the JSON Viewer, validate syntax with the JSON Validator, compare release inventories using JSON Diff, format XML variants with the XML Formatter, and calculate text digests using the SHA-256 Generator.

Review checklist

• [ ] Coverage includes direct and transitive components
• [ ] A supported standard is used
• [ ] The SBOM identifies source and artifact
• [ ] Relationships are present
• [ ] The document parses and passes validation
• [ ] Historical release SBOMs are retained
• [ ] Integrity or attestation is available
• [ ] Vulnerability workflows consume the data

Conclusion

Software Bill of Materials Guide becomes valuable when it is repeatable, owned, and verified. Start with the highest-impact boundary, document the expected state, test realistic failure cases, and fix the gaps that evidence reveals. Small controls maintained consistently are more reliable than a large policy that nobody exercises.