Exit 0 and no warning when no OS packages are detected, so --exit-code gates pass images Trivy could not read

[heyvaldemar]

Description

Scanning an image whose OS Trivy does not detect, such as busybox, produces a report with no Results, no warning in the log, and exit code 0 even with --exit-code 1 --severity CRITICAL. A CI gate built on the exit code cannot tell "scanned, nothing critical" from "nothing scanned". The same happens in the cosign-vuln output, which is signed and attached as a vulnerability attestation, so the absence becomes a signed record that reads as clean.

Reproduce with Trivy 0.75.0:

trivy image --exit-code 1 --severity CRITICAL docker.io/library/busybox:1.37; echo "exit $?"
# exit 0, no warning

trivy image --format cosign-vuln docker.io/library/busybox:1.37 | jq '.scanner.result | keys'
# ["ArtifactID","ArtifactName","ArtifactType","CreatedAt","Metadata","ReportID","SchemaVersion","Trivy"]: no Results, and Metadata has no OS

For contrast, alpine:3.10 exits 1 on CVE-2021-36159.

The idea, in any of three forms:

• a warning in the log when no OS is detected and no language packages are found, since the image produced no findings because nothing was read;
• an option to fail when nothing was scanned, as Add option to treat unsupported OS as a failure #1082 asked in 2021 (closed as stale); or
• a field in the JSON and cosign-vuln output that says whether OS packages were detected, so a policy can require it without inferring it from an absent key.

The downstream workaround used in https://github.com/heyvaldemar/kubernetes-supply-chain-admission is to require a Results entry of class os-pkgs before counting severities.

Target

Container Image

Scanner

Vulnerability