A software bill of materials, or SBOM, is a structured inventory of software components and their relationships. Its usefulness depends on what was inspected. An inventory generated from a source tree can tell you what a project declares. An inventory generated from a final container image can tell you which recognizable components are present in that image.
Choose the input before the format
Suppose a build stage installs a compiler and a large set of development libraries. The production image contains only the application binary and a smaller set of runtime packages. A source or build-stage SBOM and a final-image SBOM will naturally describe different things. Label each inventory with its scope so that recipients know how to interpret it.
For delivery, confirm whether the recipient expects SPDX or CycloneDX, which schema version it accepts, and which identifiers it uses to match packages. Import a real file into the downstream system before committing to a format. A document that passes schema validation can still lose information during ingestion.
Choose a generator around your build
- Syft suits an artifact-first inventory workflow built around container images or filesystems. Test coverage for the packages and binaries you actually ship.
- Trivy is worth evaluating when teams want inventory generation and related scanning in one workflow. Validate how an externally generated SBOM behaves when you feed it back into the scanner.
- cdxgen is a CycloneDX-oriented option for source and artifact workflows. Check the dependency relationships it produces for your build and package ecosystems.
Generate the release SBOM after producing the final artifact. Store it alongside the artifact’s immutable digest, record the generator configuration, and validate both the document and its downstream import. Then use a past release to rehearse an advisory lookup. The inventory should let you identify the affected artifact without rebuilding it or guessing what its tag once pointed to.