SBOM and provenance

Do this

1. Generate the SBOM from what you ship

   Scan the released artifact by digest, such as the image for each platform you ship, with a generator such as Syft or Trivy, not the repository alone: a lockfile and an image list different components. Keep package-manager SBOMs, such as npm sbom, as build evidence, and add components the scanner cannot see, such as statically linked libraries, from build records.

2. Use a format your consumers can read

   Write SPDX or CycloneDX JSON, and agree the version with the people who consume it. In practice that means CycloneDX 1.7 or SPDX 2.3: Syft, Trivy and BuildKit still write SPDX 2.3 rather than 3.0.1. Pin the generator version and record it in the SBOM.

3. Fill the fields generators leave out

   Check the SBOM against CISA's 2026 Minimum Elements, which replaced the 2021 NTIA list. Add the SBOM author (your organization, not the tool vendor) and the generation context, such as post-build for an image scan, and prefer SHA-256 or stronger component hashes. SBOM checker flags missing versions, suppliers and hashes.

4. Have the build platform produce provenance

   Let the hosted build platform, not a build step, generate and sign SLSA provenance naming the artifact digest, builder, build type and parameters, for example GitHub artifact attestations or the SLSA GitHub generator; check what your CI platform offers. SLSA Build L2 needs a hosted platform that signs provenance; L3 also isolates runs and keeps signing secrets away from build steps.

5. Bind both to the artifact digest

   Sign the SBOM as an attestation whose subject is the artifact digest, for example cosign attest --type cyclonedx, so a consumer can tell which artifact it describes and who wrote it. An SBOM file sitting next to an image proves neither.

6. Archive them with the release

   Store the artifact, SBOM, provenance and signatures together under the release record, with read-only access for the people who need it, as SSDF PS.3.1 describes. Regenerate on every rebuild, since PS.3.2 asks you to update provenance data whenever a component changes, and publish corrections as a new SBOM version for the same artifact.

7. Verify them before you rely on them

   At deploy, and for customers, verify the attestations against the expected signer (cosign verify-attestation or gh attestation verify). Then check the provenance: predicate type https://slsa.dev/provenance/v1, subject digest, builder ID, buildType and externalParameters, against expected values, as SLSA's verification guidance asks. Artifact signing covers the deploy gate.

Common mistakes

• Generating the SBOM from the repository instead of the shipped artifact. It lists test tools you do not ship and misses operating system packages you do.
• Reading a clean scan as a complete inventory. An image scanner cannot see a statically linked library unless build metadata records it.
• Publishing an unsigned SBOM beside the image. Nothing ties it to a digest or an author, so nobody can match it to what is running or trust who wrote it.
• Letting build steps write and sign their own provenance. If user-defined steps can reach the signing secrets, the statement says whatever an attacker wants; SLSA Build L3 keeps those secrets away from them.
• Treating provenance as proof of review or safety. It records where and how an artifact was built, not that the source was reviewed or is free of vulnerabilities.
• Converting between formats without checking. The CycloneDX and SPDX files Syft writes from one scan state dependencies in opposite directions, so a careless converter reverses every edge.

SPDX or CycloneDX?

Choose the one your consumers validate, and test any conversion by comparing components and dependency edges, not by whether the output parses.

Tools and guides

• Tool: SBOM checker
• Tool: OSV dependency lookup
• Generate an SBOM for the software you actually release

  Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.

• Read SLSA provenance and verify the claim you need

  Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls.

• Choose SBOM formats and identify components accurately

  Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning.

• Review SBOM changes between releases

  Turn inventory differences into explainable release decisions without confusing generator changes with software changes.

• Use VEX without losing vulnerability evidence

  Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence.

Standards

NIST SSDF 1.1

PS.3 Archive and Protect Each Software Release

OWASP SAMM 2

Secure Build

Sources

1. CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM). 29 July 2026.
2. CycloneDX specification overview. Version 1.7 (October 2025).
3. SPDX specifications
4. SPDX specification 3.0.1
5. Syft: SBOM generation for container images and filesystems
6. SLSA 1.2: Build track basics
7. SLSA 1.2: Verifying artifacts
8. GitHub CLI manual: gh attestation verify
9. OWASP SAMM: Secure Build, Software Dependencies stream
10. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.