skip to content

With `trivy image --sbom-sources oci`, Trivy 0.74 reports an image's vulnerabilities in seconds without analysing its layers — what did it scan, and when is that a problem?

level: seniorimportance: nice to knowfreq 5%

answer

  1. someone else's inventory, found by digest
  2. a registry API or a transparency log
  3. an experimental flag with two values
  4. what happens when nothing is found
  5. no layer analysis, no signer check

basics

~20 s

Trivy found an SBOM attached to the image's digest through the registry's referrers API and scanned that document instead of the layers. The result is only as complete and trustworthy as that SBOM, and Trivy does not check who signed it.

solid answer

~40 s

`--sbom-sources` is an experimental flag that takes `oci` and `rekor`. With `oci`, Trivy resolves the image's repository digest, lists referrers that carry a CycloneDX JSON, SPDX JSON or Sigstore-bundle artifact type, takes the first one it can parse and scans that SBOM. With `rekor` it searches a Rekor log, `https://rekor.sigstore.dev` unless `--rekor-url` says otherwise, for a CycloneDX attestation of the digest. If nothing is found, it falls back to the normal layer scan. The speed is real, but the findings now depend on whoever produced that SBOM. Packages it missed are invisible, nothing that needs file contents, such as secret scanning, gets looked at, and the discovery code does not verify the signer. I use it only where a trusted pipeline attaches the SBOM, and verify signatures separately.

code

bash · 2 lines
bash
trivy image --sbom-sources oci registry.example.internal/shop/app:1.4.0
trivy image --sbom-sources rekor --rekor-url https://rekor.example.internal registry.example.internal/shop/app:1.4.0

go deeper

for a junior

Recall that --sbom-sources lets Trivy scan an SBOM already attached to an image instead of pulling its layers, with two sources: oci and rekor.

for a middle

Explain the flow: repository digest, referrers or Rekor lookup, the accepted SBOM types, and the fallback to a layer scan when nothing is found.

for a senior

Show the trade-off: speed against a result bounded by someone else's inventory, no layer analysis, no signer verification, and digests sent to a log.

for a principal

Decide where discovered SBOMs are trusted, which producers and verified signers, and what full-scan cadence keeps the estate honest.

## Two discovery sources `--sbom-sources` tells `trivy image` to look for an existing SBOM of the image before analysing it. The flag is marked **experimental** in Trivy 0.74.0 and accepts two values, tried in the order you give them: | Value | Where Trivy looks | What it accepts | |---|---|---| | `oci` | the registry's **Referrers API**, for artifacts that point at the image's repository digest | artifact types `application/vnd.cyclonedx+json`, `application/spdx+json` and the Sigstore bundle type | | `rekor` | a **Rekor** transparency log, searched by digest; default `https://rekor.sigstore.dev`, or your own instance with `--rekor-url` | in-toto attestations whose predicate is CycloneDX | A **referrer** is an artifact stored in the registry with a pointer to another manifest's digest. That pointer is how an SBOM or a signature is attached to an image without changing the image itself. **Rekor** is Sigstore's append-only log of signing events and attestations. ## The decision flow 1. Trivy resolves the image's **repository digest**. A locally built image with no digest for that repository counts as "not found". 2. It queries each source in order. With `oci` it takes the first referrer of a supported type that parses as an SBOM. 3. On success it logs `Found SBOM in the OCI referrers` or `Found SBOM in Rekor`, and scans that SBOM instead of the layers. 4. If no source has an SBOM, it falls back to the usual layer analysis, so you lose the speed-up but nothing breaks. 5. An unexpected error, as opposed to "not found", fails the scan. With `rekor`, Trivy also looks up SBOM attestations for **non-packaged binaries** by their digest. That works in `trivy fs` as well, and the documentation warns that it slows scanning because each such binary is queried online. ## What changes in the result - **The package set is the SBOM's.** Anything its producer missed is invisible to this scan. - **No layer analysis.** Nothing that needs file contents runs against the image, so secret scanning finds nothing to read. - **The producer matters.** The Trivy documentation warns that SBOMs from other tools may detect less accurately. - **No signer check.** The discovery code reads the referrer or log entry and scans it. It does not verify who signed it, so verifying the attestation against an expected identity is a separate step that you must run. - **Data leaves the network.** The `rekor` source sends the image digest, and binary digests, to the configured log. For private images, point `--rekor-url` at your own instance or do not use it. ## Where it fits - Large estates re-scanned on a schedule, where pulling every image is the cost that dominates. - Pipelines that attach **Trivy's own SBOM** at build time, for example by attesting the output of `trivy image --format cyclonedx` with Cosign, so the producer is known. - A complement to, never a replacement for, a periodic full `trivy image` scan, which still reads the layers for secrets and confirms that the attached SBOM matches the image. ## Operating it safely 1. Attach SBOMs only from a pipeline you control, and record which producer wrote them. 2. Verify the attestation against the expected signer identity before trusting what discovery found. 3. Keep `--sbom-sources` out of the one job that must see file contents, such as the secret scan. 4. Schedule full layer scans so that a stale or incomplete attached SBOM is caught. 5. Watch the logs for the `Found SBOM` lines, so you know which results came from a discovered document. ## A worked example A registry holds a few hundred service images, and the nightly re-scan spends most of its time pulling layers. Each image has a CycloneDX SBOM attached as a referrer by the build pipeline. Switching the nightly job to `trivy image --sbom-sources oci` cuts the run to a fraction of its time, and the vulnerability findings match the previous night's. A week later a secret embedded in one image is found by a different tool. The nightly scan had stopped reading layers, so its secret scanner had nothing to look at. The team keeps discovery for the nightly vulnerability pass and adds a weekly full layer scan. ## Version notes In Trivy 0.74.0 the flag is still labelled experimental. Sigstore-bundle SBOMs became discoverable in 0.68.0. The Rekor path reads only CycloneDX predicates.

  • You built the image locally and never pushed it. What does `--sbom-sources oci` do?
    It needs the image's repository digest to ask the registry for referrers. A locally built image has no repo digest for that repository, so discovery counts as not found and Trivy falls back to the normal layer scan, with no error and no speed-up.
  • Why keep a periodic full `trivy image` scan even when discovery works?
    A discovered SBOM replaces layer analysis, so embedded secrets and packages the SBOM's producer missed are never looked at. A scheduled layer scan closes that gap and also checks the attached SBOM against what the image really contains.

saying these in an interview costs you the question

  • --sbom-sources makes Trivy verify the SBOM's signature before using it.
  • If no SBOM is attached, the scan fails.
  • A discovered SBOM is merged with a full layer scan.
  • The rekor source works for private images without sending anything outside.
  • --sbom-sources is a stable, default-on feature.