This is a follow-up to
From 70 CVEs to 0: a hands-on VEX suppression workflow with Trivy.
The original demo covered Trivy's VEX repository and the filesystem-embed
approach. This update adds Docker Scout attestations as a first-class
distribution channel and surfaces three new gotchas that aren't in the docs.

The demo repo is the same:
github.com/darkedges/trivy-vex-demo

• pull the latest and the new steps are already in run.sh / run.ps1.

What changed

The demo now has three distribution channels for the same OpenVEX statements:

Channels 1 and 2 are independent; updating one does not update the other.
They use different product PURLs and different packaging, but start from
the same vexctl create output.

Gotcha 4: Docker Scout won't match pkg:oci/

The original demo used a pkg:oci purl pinned to the image digest:

pkg:oci/pingaccess@sha256:51689e8c…

Docker Scout ignores it. Scout expects the pkg:docker/ form with the
full org/name path and the tag as the version component, separated by @:

pkg:docker/pingidentity/pingaccess@8.3.4-edge

So the generate-vex.sh script now runs two loops: one producing
.openvex.json files with a pkg:oci digest purl for Trivy/Wiz, and a
second producing .vex.json files with the pkg:docker tag purl for Scout.
Same CVE set, different product identifiers, different output directories.

# Trivy/Wiz channel - digest-pinned
vexctl create \
  --product="pkg:oci/pingaccess@sha256:51689e8ccf1ec6bef28c855a2f2fafdd3556f753609adad2e258580e3bc9397c" \
  --vuln="CVE-2022-46337" \
  --file="vex/statements/CVE-2022-46337.openvex.json" ...

# Scout channel - tag-based
vexctl create \
  --product="pkg:docker/pingidentity/pingaccess@8.3.4-edge" \
  --vuln="CVE-2022-46337" \
  --file="vex/statements-scout/CVE-2022-46337.vex.json" ...

The dry-run check before attaching anything is:

docker scout cves pingidentity/pingaccess:8.3.4-edge \
  --vex-location ./vex

If not_affected CVEs still appear, the first thing to check is the PURL
prefix - pkg:oci/ in a Scout context is a silent no-match.

Gotcha 5: attestations and filesystem VEX are mutually exclusive (Scout)

In the original post I mentioned that Trivy doesn't auto-discover VEX
embedded in the image filesystem. Scout has a related but different rule that
is much easier to trigger accidentally:

If an image has any attestation, Scout reads only attestations and ignores
all filesystem-embedded VEX documents entirely.

"Any attestation" includes the provenance and SBOM attestations that modern
BuildKit adds automatically when you docker build without explicitly opting
out. So this build:

docker build -f embed/Dockerfile -t myimage:latest .

…will silently have provenance attached (BuildKit default since Docker Desktop
4.11), and Scout will never read the *.vex.json files you COPYd into
/usr/share/vex/. You won't get an error; Scout just returns unfiltered
results.

To actually use the filesystem path you must suppress both:

docker build --provenance=false --sbom=false \
  -f embed/Dockerfile -t myimage:latest .

In practice: prefer attestations. They travel with the image in the
registry, require no extraction, and don't silently vanish because BuildKit
added something. The filesystem path is useful when you can't push to a
registry at all.

Gotcha 6: Scout attestations need the containerd image store

Running docker scout attestation add against a local registry:2 requires
the containerd image store to be active in your Docker daemon. With the
default overlay2 store the command may succeed but Scout won't resolve the
attestation manifest correctly when reading it back.

Check with:

docker info | grep 'containerd-snapshotter'
# containerd-snapshotter: true  ← you're good
# (nothing)                     ← not enabled

To enable it, add to /etc/docker/daemon.json and restart Docker:

{
  "features": { "containerd-snapshotter": true }
}

⚠️ Enabling the containerd image store can affect existing local images - they
won't be visible in the new store until re-pulled. Enable it in a dev
environment before hitting production.

The run.sh / run.ps1 scripts now detect this automatically and skip
steps 9–11 (the Scout attestation flow) rather than blocking, so the rest
of the demo - Trivy VEX repo, filesystem fallback, suppression proofs - runs
uninterrupted regardless of your daemon config.

The attestation flow end-to-end

Once the containerd store is active:

# 1. Verify suppression locally before attaching anything
docker scout cves pingidentity/pingaccess:8.3.4-edge \
  --vex-location ./vex

# 2. Push to a local registry:2 (no public push)
docker run -d -p 5000:5000 --name vex-registry registry:2
docker tag pingidentity/pingaccess:8.3.4-edge \
  localhost:5000/pingidentity/pingaccess:8.3.4-edge
docker push localhost:5000/pingidentity/pingaccess:8.3.4-edge

# 3. Attach each VEX document as an in-toto attestation
for f in vex/statements-scout/*.vex.json; do
  docker scout attestation add \
    --file "$f" \
    --predicate-type https://openvex.dev/ns/v0.2.0 \
    localhost:5000/pingidentity/pingaccess:8.3.4-edge
done

# 4. Re-scan to prove suppression
docker scout cves localhost:5000/pingidentity/pingaccess:8.3.4-edge

A few operational notes:

• Attestations cannot be removed once attached; re-attaching a new document for the same CVE overwrites it.
• docker scout attestation add works without a rebuild - the image is already in the registry.
• A plain registry:2 supports OCI artifact manifests (used by attestations) from Docker Registry API v2.9 onward; if yours is older you'll need to upgrade or fall back to the filesystem path.

Updated toolchain image

The toolchain/Dockerfile now includes docker-cli and the Docker Scout
plugin installed via the official install.sh:

RUN apk add --no-cache ca-certificates curl jq bash docker-cli

# Docker Scout CLI - verify latest at https://docs.docker.com/scout/install/
RUN curl -fsSL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | bash

This lets the toolchain container run Scout commands when the Docker socket is
mounted, as a self-contained alternative to installing Scout on the host.

Summary: which mechanism to use when

The full demo still runs in one command and nothing leaves the host (local
registry:2 stands in for a real registry):

./run.sh        # pauses after each step
./run.sh -y     # unattended

Questions on PURL matching, CycloneDX VEX, or Grype's behaviour with any of
this? Drop them in the comments.