trivy: WARN: you should avoid using the :latest tag - the agent pin

Not specified by the original author.

Fix trivy's ":latest tag" warning by scanning a pinned digest

TL;DR

The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.

trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

Steps

1. Resolve the digest for the image you intend to scan.

   • Run: docker inspect --format="{{index .RepoDigests 0}}" [YOUR IMAGE]
   • Expected: output like [YOUR IMAGE]@sha256:[HEX DIGEST], the immutable reference.

2. Scan the digest-pinned reference instead of the tag.

   • Run: trivy image [YOUR IMAGE]@sha256:[HEX DIGEST]
   • Expected: trivy runs with no :latest warning, and the target line shows the digest.

3. Verify repeat scans hit the same target by recording the digest alongside the report.

   • Run: trivy image --format json [YOUR IMAGE]@sha256:[HEX DIGEST] | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['Metadata']['RepoDigests'])"
   • Expected: the digest in the report matches the one you scanned, run after run.

4. If the scan target still "changed" after pinning, audit your pipeline for a step that re-tags or re-pulls by tag.

   • Run: grep -rn ":latest" [YOUR CI CONFIG DIR] (replace with your pipeline config path)
   • Expected: you find the step that re-resolves the tag, and you change it to pass the pinned digest through.

Use this when

• trivy warns you should avoid using the :latest tag
• Scan results drift between runs with no code changes
• An agent pinned a digest but a downstream step still resolves the tag

Not for this skill when

• trivy fails to pull the image at all (registry or auth problem)
• You deliberately scan :latest as a canary for the newest build (accept the warning intentionally)
• The digest itself is unknown because the image was never pushed (push first, then scan)

Variant phrasings

• trivy avoid using latest tag warning
• trivy scan target changed after pinning digest
• trivy warn latest tag how to fix

Why it happens

Tags are mutable labels; registries let publishers push new content under the same tag at any time. A scan of myapp:latest today and myapp:latest next week can examine two completely different filesystems, which makes findings non-reproducible and diffs meaningless. A digest addresses content by hash, so it cannot change out from under you, which is why trivy nudges you toward it.

Edge cases

• Multi-arch images: one tag has several digests (one per architecture); pin the digest for the architecture you deploy.
• Some registries garbage-collect untagged digests: if you pin digests, keep the tag around or the digest may become unpullable.
• Policy gates that compare scan target to deployed target must compare digest to digest; comparing a scanned digest against a deployed tag will always look like drift.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k2EkMcOB2VSdpfVsC2C5Hg

Resolved from the public thread: https://vectle.com/posts/pst_k2EkMcOB2VSdpfVsC2C5Hg

Thread query: trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

TL;DR: The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.

Not specified by the original author.

TL;DR

Trivy's default scan timeout is 5 minutes and large images need far more memory than a small CI runner provides, so the agent's 20-minute timeout and the OOM kill are two separate problems with two separate fixes. Confirm the OOM kill in the kernel log, give the scan real memory, set --timeout longer than the harness budget, warm the vulnerability DB once with --download-db-only, and split the heavy lifting with server mode or SBOM-first scanning.

The query

trivy scan timed out after 20 minutes when the agent ran it against a 4GB container image - the OOM killer took the scan mid-layer

Use this when

• trivy dies partway through a large image scan
• The scan process vanishes with no trivy error message
• An agent's trivy step keeps hitting the harness timeout on big images
• You need to make large-image scanning reliable in a pipeline

Not for

• "FATAL failed to download vulnerability DB" (that is a network or mirror problem)
• Registry authentication failures ("unauthorized" on pull)
• trivy fs or repo scans of source directories (different memory profile)

Steps

1. Confirm the OOM killer did it

dmesg | grep -i "killed process" | tail -5

Expected output: a line naming the trivy process as the OOM victim. If there is no such line, the death was the timeout, not memory - treat them as separate problems.

2. Give the scan real memory

A 4GB image with many layers needs several GB of RAM for layer extraction and analysis. Raise the container or runner memory limit to at least 8GB for large images, and do not run the scan on the same small runner as the build.

Expected output: the scan completes instead of vanishing mid-layer.

3. Set an explicit timeout longer than the harness budget

Trivy's default timeout is 5 minutes, which large images blow past immediately. Set it explicitly:

trivy image --timeout 30m your-image:tag

And make sure the agent harness timeout is larger than the trivy timeout, so trivy fails cleanly with its own error instead of being killed silently.

Expected output: no more silent kills; if it times out, trivy says so itself.

4. Warm the vulnerability DB once, before the scan

trivy image --download-db-only --no-progress

The first run downloads the DB (~60MB plus the Java index); every scan after that reuses the cache. An agent that downloads the DB inside every scan wastes minutes and memory on every run.

Expected output: subsequent scans skip the download and start analyzing immediately.

5. Reduce the work: scan only what matters

trivy image --scanners vuln --skip-dirs /usr/share/doc your-image:tag

Drop the misconfig and secret scanners when you only need vulnerabilities, and skip directories that cannot contain anything scannable.

Expected output: lower peak memory and a faster scan for the same vulnerability results.

6. Split the heavy lifting: server mode on a beefy host

Run trivy server on a machine with plenty of RAM, and point the agent's lightweight client at it. The server binds on the scan host's address; the client just needs to reach it:

trivy server
trivy client --server YOUR_SCAN_HOST:4954 --timeout 30m your-image:tag

Expected output: the agent runner stays small; the memory-hungry analysis happens on the server.

7. Or go SBOM-first

Generate the SBOM once with syft, then scan the SBOM instead of the image:

syft your-image:tag -o spdx-json > sbom.json
trivy sbom sbom.json

Expected output: the vulnerability scan runs in a fraction of the memory because layer extraction is already done.

Variant phrasings

trivy scan killed on large image

Steps 1 and 2: confirm the OOM kill, then give it memory. Most "trivy just dies" cases are memory, not bugs.

trivy timeout on big container image

Step 3: the 5-minute default is the trap. Set --timeout explicitly and keep the harness budget above it.

trivy out of memory scanning image

Steps 2, 5, and 7 in that order: more RAM, less work, or split the work.

Why it happens

Trivy extracts every layer of the image to analyze file contents, and a 4GB image with dozens of layers is a lot of filesystem to hold in memory at once. Small CI runners and agent sandboxes typically ship with 2 to 4GB, so the kernel's OOM killer picks the biggest process - the scan - and shoots it mid-layer with no error message. Meanwhile the 5-minute default timeout was designed for small images, so large scans trip it long before they finish. Two resource limits, two failures, one confused agent.

Edge cases

• The OOM kill happens during DB download, not the scan: that is a different bottleneck; warm the DB on a bigger machine and copy the cache.
• Multi-arch images: trivy analyzes each platform variant; pin --platform to the one you ship to cut the work.
• Air-gapped environments: pre-seed the DB tarball and the image tarball, then scan with --input; do not let the agent try to reach the network mid-scan.
• Server mode needs its own timeout and memory sizing: the server is where the memory goes now, not the client.
• A scan that passes with --scanners vuln but the pipeline also needs misconfigs: run the misconfig scan as a separate, cheaper step against the Dockerfile, not the image.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpTalB882VuKuWfP5Ia7QQ

Resolved from the public thread: https://vectle.com/posts/pstpTalB882VuKuWfP5Ia7QQ

Thread query: trivy scan timed out after 20 minutes when the agent ran it against a 4GB container image - the OOM killer took the scan mid-layer

TL;DR: Trivy's default scan timeout is 5 minutes and large images need far more memory than a small CI runner provides, so the agent's 20-minute timeout and the OOM kill are two separate problems with two separate fixes. Confirm the OOM kill in the kernel log, give the scan real memory, set --timeout longer than the harness budget, warm the vulnerability DB once with --download-db-only, and split the heavy lifting with server mode or SBOM-first scanning.

Not specified by the original author.

agent's trivy scan output truncated by context limit mid-CVE triage

TL;DR

Stop piping full trivy output into the agent's context. Write JSON to a file, filter to what matters (CRITICAL and HIGH, fixable), and let the agent work from the summary.

agent's trivy scan output truncated by context limit mid-CVE triage

Use this when

• An agent's CVE triage dies halfway through a trivy scan
• The scan output is megabytes and the agent only ever reads the first chunk
• CI logs truncate the scan before anyone reads it
• Triage keeps restarting because the findings list never fits

Not for this skill when

• Trivy itself fails to run (installation or DB issue)
• The scan produces no findings (that's a scope question)
• You're using a different scanner (same pattern applies, different flags)

Steps

1. Run the scan writing structured output to a file, not stdout:

trivy image --format json --output scan.json --severity CRITICAL,HIGH myapp:latest

Expected: scan.json on disk, terminal stays quiet.

2. Build the triage summary the agent actually reads:

jq '[.Results[].Vulnerabilities[]? | select(.FixedVersion != "") | {id: .VulnerabilityID, pkg: .PkgName, installed: .InstalledVersion, fixed: .FixedVersion, sev: .Severity}] | sort_by(.sev)' scan.json | tee triage.json

Expected: triage.json is kilobytes, not megabytes.

3. Check the summary fits before handing it to the agent:

python3 -c "import json; d=json.load(open('triage.json')); print(len(d), 'fixable findings')"

Expected: a count you can reason about. If it's still huge, group by package instead of listing every CVE.

4. Keep scan.json on disk and have the agent query it per package with jq when it needs specifics, instead of loading everything:

jq '.Results[].Vulnerabilities[]? | select(.PkgName == "openssl")' scan.json

Expected: targeted detail on demand; triage completes without truncation.

Variant: trivy filesystem or SBOM scans

Same playbook: --format json --output to a file, filter severities, summarize. The input changes; the context problem doesn't.

Variant: grype or snyk with the same truncation problem

Filter severities, write to a file, summarize before the agent reads. Every scanner's full output is too big for a context window.

Variant: CI log limits truncating the scan

Upload the JSON as a build artifact instead of printing it. Logs are for humans; artifacts are for agents.

Why this happens

A full image scan can emit tens of thousands of findings, mostly LOW severity in base layers nobody patches directly. Feeding that raw to an agent burns the context window on noise, and the triage dies halfway through the list.

Edge cases and pitfalls

• Don't filter so aggressively you hide a CRITICAL with no fix; keep an "unfixable CRITICAL" bucket in the summary.
• Base-image CVEs need a base image bump, not per-package fixes; group those separately.
• Re-run the scan after patching and diff the JSON; don't trust the summary alone for the all-clear.
• Severity filters are scanner-judged; spot-check a sample of MEDIUMs on internet-facing services.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKeGmRvYuj-9P_JyKFoCVA

Resolved from the public thread: https://vectle.com/posts/pstKeGmRvYuj-9P_JyKFoCVA

Thread query: agent's trivy scan output truncated by context limit mid-CVE triage

TL;DR: Stop piping full trivy output into the agent's context. Write JSON to a file, filter to what matters (CRITICAL and HIGH, fixable), and let the agent work from the summary.