the agent ran trivy with --severity HIGH,CRITICAL and reported zero findin

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.

Not specified by the original author.

TL;DR

Re-scan locally to see the exact CVEs, then pull a newer patch tag of the same base image - most base-image CVEs are fixed within days upstream. If the image drags in a full distro userland your app never uses, switch to a slimmer variant. Only ignore a CVE via .trivyignore after you have verified it is not exploitable in your deployment.

The error

myapp:pr-123 (debian 12.8)

Total: 21 (HIGH: 14, CRITICAL: 7)

(Trivy prints a table of CVEs above the totals, then exits 1 when findings meet the severity threshold.)

Fix it

1. Reproduce what CI sees. Run trivy image --severity HIGH,CRITICAL [your-image-tag] locally. Expected: the same CVE table and totals CI reported.

2. Check for a patched base image. Pull the newest patch tag of the same distro (for example the latest 12.x point release) and re-scan. Expected: the totals drop, often to zero - upstream rebuilds pick up distro security fixes quickly.

3. Shrink the attack surface. If your app does not need the full distro userland, switch the Dockerfile to a slimmer variant of the image and re-scan. Expected: OS-package CVEs your app never touches disappear from the report.

4. Triage what remains. For each leftover CVE, check whether the vulnerable package is reachable in your deployment. If a CVE has no fix yet and is genuinely not exploitable for you, add its ID (one per line) to a .trivyignore file at the repo root with a comment saying why and when to re-check. Expected: trivy exits 0 with the ignore file committed alongside the Dockerfile.

5. Update the Dockerfile base tag, rebuild, and re-run CI. Expected: the image-scan check goes green.

Use this when

• Trivy fails the PR with HIGH or CRITICAL totals on the base image
• You see "HIGH severity vulnerabilities in base image" in the scan step
• The image-scan check is red and the CVEs are all in OS packages, not your app code

Not for this skill when

• The vulnerabilities are in YOUR application dependencies, not the base OS - bump the dependencies instead (see the snyk and osv-scanner skills)
• Trivy fails with a database download error or network timeout - that is transient infra, retry the job
• The scanner is a different tool (grype, docker scout) - same ideas, different flags and ignore files

Variant phrasings

• trivy HIGH severity vulnerabilities base image
• trivy scan failed exit code 1
• trivyignore how to use
• trivy base image vulnerabilities PR blocked

Why it happens

Base images ship a full Linux userland, and every CVE in any installed package counts at its rated severity even if your app never executes that binary. CVE feeds also update faster than base image rebuilds, so a fresh scan can flag CVEs that were published after your base tag was cut.

Edge cases

• Pin the base image by digest for reproducibility, and refresh the digest on a schedule so pins do not go stale
• .trivyignore entries without a review date become permanent - always note when to re-check
• Distroless and minimal variants remove shells and debug tooling; keep a debug variant for incidents if your team needs one
• In air-gapped CI the vulnerability DB goes stale and trivy can fail closed - make sure the DB refresh step runs before the scan

Provenance

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

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

Thread query: trivy scan fails PR: HIGH severity vulnerabilities in base image

TL;DR: Re-scan locally to see the exact CVEs, then pull a newer patch tag of the same base image - most base-image CVEs are fixed within days upstream. If the image drags in a full distro userland your app never uses, switch to a slimmer variant. Only ignore a CVE via .trivyignore after you have verified it is not exploitable in your deployment.

Not specified by the original author.

TL;DR

Severity filters describe the scanner's opinion; KEV membership describes observed exploitation in the wild. The filter hid a medium that CISA says attackers actually use, and "zero findings" was a lie the filter told. Rescan without the filter, cross-check every finding against KEV regardless of severity, and never let a severity flag suppress a KEV-listed CVE again.

the agent ran trivy with --severity HIGH,CRITICAL and reported zero findings - the medium CVEs it skipped included the KEV one

Use this when

• A filtered scan reports zero but you suspect otherwise.
• A KEV-listed CVE was missed because of its scanner severity.
• Reports say "no HIGH/CRITICAL" and readers hear "no risk".

Not for this skill when

• You are deliberately scoping a report to high severity and everyone understands the scope. Then label the scope, and still check KEV separately.
• The KEV entry does not apply to your stack. Then the miss was harmless, but the process gap remains.

Steps

1. Rescan without the severity filter and list everything. Verify: the full finding set includes the KEV-listed medium.
2. Cross-check the full set against the CISA KEV catalog. Verify: every KEV-listed CVE in your stack is identified by CVE ID, not by severity.
3. Change the agent's rule: severity filters may scope a report, but KEV-listed CVEs are always included and always surfaced first. Verify: rerun the filtered scan and confirm the KEV medium appears with a KEV flag.
4. Switch triage order to KEV-first: KEV-listed findings get remediated before non-KEV highs, because exploitation evidence beats severity estimates. Verify: the backlog sort puts KEV items on top.
5. Fix the report language: "zero HIGH/CRITICAL findings" must never be shortened to "zero findings" or "clean". Verify: the report template states its scope explicitly.

Variant phrasings

trivy severity filter hid KEV

The short phrasing.

medium CVE in KEV missed

The symptom search.

severity filter zero findings wrong

The report-accuracy phrasing.

Compatibility: Trivy, Grype, Snyk; all support severity filters and all need the KEV override.

Why it happens

The agent treated the scanner's severity as the ground truth about risk and the filter as a completeness boundary. But scanner severity is a pre-exploitation estimate, while KEV is post-exploitation fact. Filtering on the estimate hid the fact. "Zero findings" reported the filter's output as if it were the world's state.

Edge cases / pitfalls

• KEV is not exhaustive; a non-KEV medium can still be the one that gets you. KEV-first is a triage order, not a permission to ignore the rest.
• EPSS scores complement KEV for the not-yet-exploited; consider both, but KEV membership is the hard override.
• If the report goes to leadership, the scope line ("filtered to HIGH/CRITICAL, KEV checked separately") prevents the "we were told zero" conversation later.

Provenance

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

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

Thread query: the agent ran trivy with --severity HIGH,CRITICAL and reported zero findings - the medium CVEs it skipped included the KEV one

TL;DR: Severity filters describe the scanner's opinion; KEV membership describes observed exploitation in the wild. The filter hid a medium that CISA says attackers actually use, and "zero findings" was a lie the filter told. Rescan without the filter, cross-check every finding against KEV regardless of severity, and never let a severity flag suppress a KEV-listed CVE again.