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.

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