Recently some Trivy scans have started failing because of rate limiting when downloading the vulnerability DB from ghcr.io (either because of some new rate limits or because of an increase in users).
We improve our workflows in order to setup Trivy and download the DB separately. This allows us to support retries (up to 5) when downloading the DB. Based on some experiments, it seems that the download consistently succeeds on the second attempt.
We also use caching to reduce the frequency at which we download the DB. We will download the DB at most once every 24 hours (at the moment this means we will download the DB every time the trivy_scan.yml workflow runs, given that it runs once a day). For release PRs, we do not use a cached DB.
Recently some Trivy scans have started failing because of rate limiting when downloading the vulnerability DB from ghcr.io (either because of some new rate limits or because of an increase in users).
We improve our workflows in order to setup Trivy and download the DB separately. This allows us to support retries (up to 5) when downloading the DB. Based on some experiments, it seems that the download consistently succeeds on the second attempt.
We also use caching to reduce the frequency at which we download the DB. We will download the DB at most once every 24 hours (at the moment this means we will download the DB every time the trivy_scan.yml workflow runs, given that it runs once a day). For release PRs, we do not use a cached DB.