Why can Trivy 0.74's `trivy image` scan a different copy of the same tag on a laptop than in CI, and which flags pin that choice?

## The search order `trivy image` takes an image **name**, not a location. Trivy 0.74 resolves the name against a list of **image sources** and scans the first copy it finds: 1. **`docker`**: the local Docker Engine, skipped if no engine is running. 2. **`containerd`**: the local containerd, skipped if it is not running. 3. **`podman`**: local Podman 2.0 or later through its socket; a remote Podman is not supported. 4. **`remote`**: the container registry named in the reference. The list is the `--image-src` flag (`image.source` in `trivy.yaml`), default `docker,containerd,podman,remote`. Passing it **replaces** the order: `--image-src podman,containerd` searches Podman, then containerd, and fails if neither has the image, without falling back to the registry. ## Why a laptop and CI disagree - **A stale local copy.** A developer pulled `registry.example.com/shop/api:1.4` last month; the tag has since been rebuilt and re-pushed. The laptop's Docker Engine still has the old copy, and because `docker` is first in the default order, that is what gets scanned. - **No daemon in CI.** A typical CI container has no engine, so the same command falls through to `remote` and scans the current registry copy. - **A different architecture.** For a multi-arch index pulled from a registry, Trivy loads `linux/amd64` unless told otherwise. A laptop on another CPU architecture usually holds its native variant locally, so the package builds and even the versions can differ. ## Pinning the source | Source | How to point Trivy at it | |---|---| | Docker Engine | `--docker-host` or `DOCKER_HOST` | | containerd | `CONTAINERD_ADDRESS` (default socket `/run/containerd/containerd.sock`), `CONTAINERD_NAMESPACE` (default `default`) | | Podman | `--podman-host`, or the `podman.socket` user service | | Registry | credentials through `trivy registry login` | | A tarball or OCI layout | `--input`, which bypasses the source list | On a Kubernetes node whose images were pulled by the kubelet, containerd keeps them in the `k8s.io` namespace, so `CONTAINERD_NAMESPACE=k8s.io` is needed before Trivy can find them. ## Choosing the architecture `--platform` takes `os/arch`, for example `linux/arm64`, and selects that manifest from a multi-arch index. For a single-architecture image it is ignored (Trivy notes this at debug level). In 0.74's code the registry and containerd sources apply the platform, but the Docker Engine source does not: it scans whatever the engine stores under that name. Combine `--platform` with `--image-src remote` when the architecture matters. ## A reproducible invocation For a release gate, remove every source of ambiguity: ```bash trivy image --image-src remote --platform linux/arm64 \ registry.example.com/shop/api@sha256:<digest-from-the-build> ``` The digest fixes the content, `remote` fixes where it comes from, and `--platform` fixes which variant of an index is read. The scan cache is keyed by image ID and layer IDs, so repeating the scan of the same digest is cheap. ## Diagnosing a disagreement 1. Rerun both scans with `--debug`; Trivy logs which source the image was found in. 2. Compare the `Metadata.ImageID` and `Metadata.RepoDigests` fields of the two JSON reports: different IDs mean different images, whatever the tag says. 3. If the images differ by architecture, rerun both with the same explicit `--platform` and `--image-src remote`. 4. Only once both scans read the same image is a remaining difference worth investigating as a database or timing question. ## When the image is not in any registry An image built in a job without pushing can be exported with `docker save` and scanned with `trivy image --input api-1.4.tar`. That also helps in air-gapped review, where the scanning machine has no access to the registry at all.