trivy scan results are unstable even when air-gapped

[dmivankov]

Description

while true; do 
  rm -rf ~/.cache/trivy/fanal/
  trivy i --skip-update -i SOME_IMAGE.tar --ignorefile IGNORE_FILE --exit-code 1 && break;
done

this script can run for tens of iterations reporting a finding in the image until on one of the runs it says image is cve-free.
There are no concurrent trivy invocations running, db updates are disabled and image tar is fixed, each scan takes around 6 seconds, so not a timeout issue either.

What did you expect to happen?

scan results should be reproducible

What happened instead?

scan results are flaky

Output of run with -debug:

(pending)

Output of trivy -v:

Version: 0.19.1
Vulnerability DB:
  Type: Light
  Version: 1
  UpdatedAt: 2021-09-14 12:05:26.334155039 +0000 UTC
  NextUpdate: 2021-09-14 18:05:26.334154639 +0000 UTC
  DownloadedAt: 2021-09-14 13:43:40.563573963 +0000 UTC

Additional details (base image name, container registry info...):

[dmivankov]

the issue seems to be that scan isn't air-gapped and doesn't fail on network errors
lines like following are present on abnormal scans

Analysis error: jar/war/ear parse error: failed to search by SHA1: status 403 Forbidden from http://search.maven.org/solrsearch/select?q=1%3A%22fc219a023416a6fe6172f61d0d7bf64ed3645969%22&rows=1&wt=json

[dmivankov]

similar reports
#1185
#1173
#1057

[dmivankov]

this seems to be the line that says - something failed in analyzer - great, let's report scan target is clean
https://github.com/aquasecurity/fanal/blob/45c48ce8280d04572d4fabbaca4fddc030883a1b/analyzer/analyzer.go#L214
and line that sometimes fails in analyzer is around
https://github.com/aquasecurity/go-dep-parser/blob/main/pkg/java/jar/parse.go#L158

[dmivankov]

another thing to consider is moving sha1->artifactid resolution inside trivy db (how much data is that?)

• helps with air-gapping
• reduces load on maven hosting
• makes scans more reproducible

[dmivankov]

workaround for java would be to use some other tool (github security scan for example)

[dmivankov]

sadly env http_proxy=nothing https_proxy=nothing trivy image --skip-update -i SOME_IMAGE.tar doesn't help as trivy tries and retries to connect to proxy. Running inside linux network namespace aka network sandbox also makes trivy retry for a long time rather than give up quickly. Setting --timeout 1s makes it terminate fast but with scan failure rather than ignoring artifact resolution which it does in case of 403 responses

[dmivankov]

also related #1191

[github-actions]

This issue is stale because it has been labeled with inactivity.

[dmivankov]

this is still an issue with trivy 0.34.0