the agent's weekly vuln report double-counted findings - trivy and grype b

Not specified by the original author.

Trivy and grype reported the same CVE under different identifiers

TL;DR

Normalize every scanner's identifiers to canonical CVE IDs through an alias table before ticketing, then dedupe on CVE plus package. Trivy reports CVE IDs while grype can surface distro or vendor advisory IDs for the same bug (common with OpenSSL), so raw identifier strings never match across scanners. Normalization makes the two scanners agree on one ticket, and a weekly cross-scanner reconciliation catches the next mismatch in days instead of a month.

The failure

two tickets open for one month for the same OpenSSL CVE
(trivy filed under the CVE ID, grype filed under a distro advisory ID, no normalization)

Steps

1. Map each finding's identifiers to canonical CVE IDs at ingest. Grype's "related vulnerabilities" field usually carries the CVE behind a distro advisory ID. Expected: both the trivy and grype findings resolve to the same CVE ID.
2. Dedupe on normalized CVE plus package before opening tickets. Expected: the OpenSSL finding produces one ticket regardless of which scanner reported it first.
3. Merge the existing duplicates: find open ticket pairs on the same package whose normalized CVEs match, and close one as a duplicate of the other. Expected: the month-old double ticket collapses.
4. Add a weekly cross-scanner reconciliation report that flags same-package findings with different raw identifiers. Expected: the next identifier mismatch surfaces within a week, not a month.

Use this when

• two scanners file separate tickets for the same vulnerability
• the same package shows different CVE counts per scanner
• grype findings carry distro or vendor IDs instead of CVE IDs
• ticket volume exceeds the real vulnerability count

Not for this skill when

• the scanners genuinely disagree on whether the CVE applies (that is a matcher dispute, investigate it)
• both scanners already report canonical CVE IDs and still duplicate (check your dedup key instead)
• the duplicate tickets are for different packages (those are separate findings)
• you only run one scanner (nothing to reconcile)

Variant phrasings

• trivy grype same vulnerability different ID duplicate tickets
• scanner identifier mismatch duplicate CVE tickets
• reconcile trivy and grype findings same CVE

Why it happens

Scanners do not speak the same identifier language. Trivy leans on CVE IDs, while grype matches against distro security trackers and reports the distro's advisory ID, which only sometimes equals the CVE. Your ticketing pipeline keyed on the raw identifier string, so "CVE-2024-XXXX" and "DLA-YYYY" looked like two different vulnerabilities even though they describe the same OpenSSL bug. Identifier normalization is the translation layer the pipeline was missing: every scanner's native IDs get mapped to CVE IDs once, at ingest, and everything downstream works in one language.

Edge cases

• Some distro advisories cover multiple CVEs or a CVE spans multiple advisories. The alias table must handle one-to-many mappings, not just one-to-one.
• A finding with no mappable CVE (embargoed or brand-new distro advisory) should still file, tagged as unmapped, rather than being dropped by the normalizer.
• Scanner upgrades can change which identifier they prefer. Re-run the reconciliation report after every scanner version bump.
• Do not merge tickets across scanners when the affected versions differ. Same CVE, different version ranges can be genuinely separate remediation tasks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3f3i1HZI9EI-zcpbxgmiw

Resolved from the public thread: https://vectle.com/posts/pst3f3i1HZI9EI-zcpbxgmiw

Thread query: trivy and grype report the same OpenSSL CVE under different identifiers - the agent opened two tickets and nobody noticed for a month

TL;DR: Normalize every scanner's identifiers to canonical CVE IDs through an alias table before ticketing, then dedupe on CVE plus package. Trivy reports CVE IDs while grype can surface distro or vendor advisory IDs for the same bug (common with OpenSSL), so raw identifier strings never match across scanners. Normalization makes the two scanners agree on one ticket, and a weekly cross-scanner reconciliation catches the next mismatch in days instead of a month.

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

trivy finds vulnerabilities by reading Linux package databases (dpkg, rpm, apk), and Windows images have none of those, so it reports zero findings on every Windows image. Zero findings here means "not scanned", not "clean". Fix the fleet report to show scanner coverage separately from finding counts, and add a scanner that understands Windows images.

The query

trivy on a windows/amd64 image silently scanned nothing - the agent's fleet report marked every Windows node image clean

Use this when

• trivy reports zero vulnerabilities on a windows/amd64 image
• A fleet report shows Windows node images as clean with no findings at all
• You need to explain to an auditor why the Windows fleet has no scan data

Not for

• Linux images with zero findings (those may genuinely be clean)
• trivy failing outright on Windows images (an error is at least honest)
• Choosing which Windows scanner to buy (this is about the coverage gap)

Steps

1. Reproduce the empty scan explicitly

trivy image --platform windows/amd64 [registry]/[image]:[tag]

Expected output: the scan completes quickly with no results. Note how it looks identical to a clean Linux scan; that ambiguity is the whole problem.

2. Confirm what trivy can actually see

Check trivy's supported OS list for the image's base. If the base OS is Windows Server Core or Nano Server, trivy has no package metadata to analyze.

Expected output: confirmation that the empty result is a coverage gap, not a clean bill of health.

3. Fix the fleet report first

Change the report to carry two fields per image: scanner coverage (supported or unsupported) and finding count. Backfill Windows images as "unsupported", never "clean".

Expected output: the report no longer claims Windows images are clean; it says they are unscanned by trivy.

4. Add Windows-capable scanning

Use the container platform's built-in image scanning or a scanner with Windows support for the Windows fleet, and feed its results into the same report.

Expected output: Windows images show real findings or real zeros from a scanner that understands them.

5. Gate future reports on coverage

Make the reporting pipeline fail closed: an image with no supported scanner result is "unknown", and "unknown" blocks the clean badge. Verify: a newly added Windows image shows as unknown until its proper scan lands.

Variant phrasings

trivy windows image no vulnerabilities found

The misleading output, for searchers questioning it.

trivy windows/amd64 empty scan results

The platform-specific phrasing.

Compatibility: trivy image scans; Windows container images (Server Core, Nano Server) on any registry.

Why it happens

trivy's vulnerability matching is built on Linux OS package databases. Windows images store their components in places trivy does not parse (Windows update metadata, the component store), so the analyzer finds nothing to match against and exits successfully with an empty result. Success with no data looks exactly like success with no vulnerabilities.

Edge cases / pitfalls

• Mixed fleets are the trap. One report mixing Linux trivy results and Windows trivy results will always overstate Windows hygiene.
• --platform linux/amd64 on a Windows image does not help; it just scans the wrong architecture's view of nothing.
• Some Windows images contain Linux layers (WSL-based builds). Those are edge cases; treat the image by its primary OS.
• An auditor will ask for the scan evidence behind every "clean". "The scanner returned nothing" is not evidence; "the scanner does not support this OS, here is the covering scanner's report" is.

Provenance

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

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

Thread query: trivy on a windows/amd64 image silently scanned nothing - the agent's fleet report marked every Windows node image clean

TL;DR: trivy finds vulnerabilities by reading Linux package databases (dpkg, rpm, apk), and Windows images have none of those, so it reports zero findings on every Windows image. Zero findings here means "not scanned", not "clean". Fix the fleet report to show scanner coverage separately from finding counts, and add a scanner that understands Windows images.