Yes, but cache the right thing. The list of components inside an image or lockfile never changes for a given digest or hash, so cache that. The list of vulnerabilities affecting those components changes whenever new advisories land, so recompute it against current data.
Two layers, two lifetimes
A scan has two steps. First, analysis: unpack the artifact and work out which packages and versions are inside. Second, matching: compare that inventory to advisory data and policy.
Analysis is expensive and deterministic. Given the same image digest, the same layers produce the same package list. Matching is cheap and time dependent. If you cache the combined verdict, you will tell a team "clean" on day 30 about an image that picked up three advisories on day 12.
| What | Key | Cache lifetime |
|---|---|---|
| Package inventory (SBOM) | Content digest or file hash | Indefinite |
| Layer analysis | Layer digest | Indefinite |
| Vulnerability matches | Inventory hash plus database build | Until database changes |
| Policy verdict | Matches plus policy version | Until either changes |
Why digests work
A container image digest identifies content, so the same digest means the same bytes. Tags do not: a tag can move. Always key on digest, never tag. Layer level caching is even better, because most images share base layers. Trivy's documentation describes a scan cache that stores analysis results such as package lists, with file system, memory and Redis backends and a configurable time to live, which is the same two-layer idea in practice.
For lockfiles, hash the file contents. Two repositories with an identical lockfile can share inventory. Be careful if resolution happens at install time: a lockfile with loose version ranges does not pin what actually gets built.
Steps to implement
- Compute a content digest for every artifact before analysis.
- Look up the inventory by digest. On a hit, skip unpacking.
- On a miss, analyse, then store the inventory.
- Always rerun matching against the current database build and policy version.
- Store the database build ID with each result so you can later answer "which data was this verdict based on?"
- Provide a purge for the cache, for the day the analyser has a bug and produced a wrong inventory.
What breaks it
Analyser upgrades. If a new scanner version detects more package types, an old cached inventory is incomplete. Include the analyser version in the cache key, or purge on upgrade.
Cache poisoning. A cache that any build can write to lets a bad actor store a clean looking inventory for a malicious digest. Make the cache write path trusted, and verify digests when storing.
Secrets and private data. Inventories contain package names, which may reveal internal components. Apply the same access controls as the SBOM itself.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the split between what is inside the image and what is wrong with it. That split is what you cache and what you recompute.
Safeguard stores SBOMs and re-evaluates them against new advisories, so a stored inventory keeps producing fresh answers. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is it safe to cache a clean verdict for a week?
Not without a reason. New advisories can make a clean artifact vulnerable overnight, so recompute matching against current data.
Should I key on image tag?
No. Tags move. Key on digest.
Sources
Last reviewed: 19 October 2026.
