Trivy vulnerability scan workflow is no longer completing

[lukeheath]

Actual behavior

We use Trivy to scan our code for vulnerabilities. It's worked pretty reliably with an occasional failure, but a few days ago it started failing every day.

More info

The workflow is failing with a rate limit:

2024-11-06T04:04:39.432Z	FATAL	init error: DB error: failed to download vulnerability DB: database download error: oci download error: failed to fetch the layer: GET https://ghcr.io/v2/aquasecurity/trivy-db/blobs/sha256:51753a1cb7763a459a1d99c9696ed82a2f4403b20806b7c485aff5a0d3b024b9: TOOMANYREQUESTS: retry-after: 178.188µs, allowed: 44000/minute

But we only run our workflow once per day. Seems like it might be rate limiting at the domain level? Need to determine if this is an us or them problem and track until it is resolved.

[lucasmrod]

Related: aquasecurity/trivy-action#430

[sgress454]

Yes, a lot of interesting chatter on this one. The culprit is Github's container registry, which seems to be lumping all users together for rate-limiting purposes. It seems that Trivy has tried to alleviate this by providing the files on their own public AWS ECR, but unless we authenticate to ECR first we again get lumped in with all the other anonymous requests and can hit rate limits again. Some folks have gone the extra step of setting up their own ECR pull-through cache, which is neat but seems like overkill for us as we do run this scan a few times a day at most. If using the credentials helper to authenticate to AWS is an option for us, then switching the config to point to Trivy's public ECR seems like the best bet.

[fleet-release]

Scans halted, code waits,
Trivy's rate limit gates,
Secure paths update.