Repository navigation
ci(trivy): cache Trivy vulnerability DB across runs - #1
Merged
Merged
Conversation
Add an actions/cache step before aquasecurity/trivy-action to persist Trivy's DB cache directory (~/.cache/trivy) between workflow runs. The cache key is date-based (UTC day, written to $GITHUB_ENV by a prior step) rather than run-id-based, since a run-id key never hits on a later run. restore-keys falls back to any prior day's cache as a base, and trivy-action itself validates DB freshness/integrity before trusting a restored cache, so a stale hit just costs a smaller incremental update instead of a full DB download - never a wrong scan. Found via a CI-speed audit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds an
actions/cachestep in.github/workflows/trivy.yml, before theaquasecurity/trivy-actionstep, to persist Trivy's vulnerability/secret DB cache directory (~/.cache/trivy) across workflow runs.Why
Every run of this workflow currently downloads the full Trivy DB from scratch, which is slow and adds unnecessary network load to every push/PR run. Caching it lets most runs reuse a warm DB and only pull an incremental update.
Key design point: the cache key
A naive run-id-based key (e.g.
${{ github.run_id }}) would never hit, since the run id is unique per run and no future run can match it. Instead this uses a coarser, date-based key:$GITHUB_ENV(CACHE_DATE).${{ runner.os }}-trivy-db-${{ env.CACHE_DATE }}.restore-keys: ${{ runner.os }}-trivy-db-lets any prior day's cache be restored as a base when today's exact key hasn't been saved yet.This is safe even when a stale (prior-day) cache is restored, because
trivy-actionvalidates the DB's freshness/integrity itself before trusting a restored cache — a stale hit just costs a smaller incremental update instead of a full download, never a wrong/outdated scan result.Validation
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/trivy.yml'))"— well-formed YAML.actionlint .github/workflows/trivy.yml— clean, no findings.This is a CI-config-only change; no application code, tests, or build pipeline touched.
Found via a CI-speed audit.
🤖 Generated with Claude Code