Skip to content
Latchkey

SBOM generation (syft) then scan errors in CI

A common pipeline generates an SBOM with Syft, then scans that SBOM with Grype or Trivy instead of re-cataloging the image. It fails when the SBOM format is not one the scanner reads, or when a stale SBOM from a previous build is scanned, yielding wrong or empty results.

What this error means

The scanner errors on an unsupported SBOM document, or reports zero vulnerabilities because it scanned an old or empty SBOM rather than the current image.

Syft
[0000] ERROR failed to catalog: unable to decode sbom: unable to identify sbom format
# or a stale SBOM yields:
No vulnerabilities found   # but the image actually has CVEs

Common causes

The SBOM format is not one the scanner accepts

Grype and Trivy read specific SBOM formats (CycloneDX, SPDX, Syft JSON). A different or hand-edited document fails to decode.

A stale or empty SBOM is scanned

Scanning an SBOM left over from a previous build, or one generated before packages were installed, produces misleading zero results.

How to fix it

Generate a supported SBOM, then scan it fresh

  1. Produce the SBOM from the current image in a format the scanner reads.
  2. Scan that exact file with sbom: so results match the image.
  3. Regenerate the SBOM on every build, never reuse an old one.
Terminal
syft myimage:latest -o cyclonedx-json=sbom.json
grype sbom:sbom.json --fail-on high

Or scan the image directly to avoid drift

If you do not need a stored SBOM, scan the image so cataloging always reflects the current build.

Terminal
trivy image --exit-code 1 --severity HIGH,CRITICAL myimage:latest

How to prevent it

  • Emit a scanner-supported SBOM format (CycloneDX or SPDX).
  • Regenerate the SBOM per build so it never goes stale.
  • Scan the SBOM you just generated, not a cached artifact.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →