SBOM (software bill of materials)
A machine-readable ingredient list for one software release, recording the exact packages and components you actually shipped.
See it
What it is
An SBOM is a machine-readable inventory of the components in one software release: names, versions, identifiers, suppliers, and dependency relationships. SPDX and CycloneDX are the common formats. The useful part is the exact version tied to an artifact, not a hand-written list of top-level libraries. US Executive Order 14028 in 2021 is why procurement teams started asking for one by name.
Generate it in the release pipeline from the final container, binary, or deployed bundle, then store it beside that artifact. When a vulnerability such as Log4Shell lands, the inventory lets you search every shipped product for the affected component instead of asking each team to remember its tree.
An SBOM is not a security scan or proof of safety. It tells you what is present, not whether a component is vulnerable or reachable. An SBOM built only from a manifest can also miss vendored code, native libraries, and files added in later container layers, so generate and verify it against the thing you actually release.
Ask AI for it
Add SBOM generation to this project's release pipeline with Anchore Syft. Scan the final container image or release artifact, not only the source manifest, and emit CycloneDX JSON plus SPDX JSON with package versions, Package URLs, licenses, suppliers, hashes, and dependency relationships. Validate the CycloneDX file with cyclonedx-cli, attach both SBOMs to the matching immutable release artifact, and retain them under the same version and digest. Add a CI check that regenerates the SBOM on every release and fails if validation fails. Run Syft now, then report components missing a version, supplier, license, or Package URL without inventing metadata.