Re-match your stored inventories against advisory data every time that data updates, which is usually daily or faster, and run a full source or image rescan on a slower cycle. Rescanning from scratch every hour is wasteful. Never rescanning unchanged code means you learn about new vulnerabilities only when someone next pushes.
Why unchanged code needs attention
A vulnerability is a fact about a package version, and facts get published after the package ships. A component you deployed in March can have an advisory published in October. Nothing in your repository changed. The risk did.
This is the reason scanning on commit alone is not enough. It covers new code you write, but not new knowledge about old code. For services that are stable and rarely touched, the gap can last months.
Two kinds of rescan
| Kind | What it does | Cost | Cadence idea |
|---|---|---|---|
| Re-match | Compares the stored inventory with the current advisory data | Low | On each data update |
| Full rescan | Re-analyses the source or image to rebuild the inventory | High | Weekly to monthly, and after scanner upgrades |
The re-match is the workhorse. It needs a trustworthy stored inventory, which is why SBOMs are useful beyond compliance. Once you have one per deployed artifact, answering "does this new advisory affect us?" is a lookup, not a scan.
Steps to set it up
- Store an inventory for every deployed artifact, keyed by digest or version, with a link to where it runs.
- Subscribe to advisory updates in whatever form your data source offers, and trigger a re-match when it changes.
- Rank results by exposure: internet facing, production, reachable code paths first.
- Notify owners only on new findings, not the whole list again.
- Schedule a full rescan on a slower cycle, and diff its inventory against the stored one. Differences point to inventory drift, such as dependencies installed at runtime.
- Record the date of last full analysis on each artifact so staleness is visible.
Choosing the full rescan interval
Tie it to how often things drift. If you deploy daily from locked builds, the inventory from build time is accurate and a monthly full rescan is a sanity check. If your artifacts install packages at start up or pull base images by moving tags, the stored inventory may be wrong sooner, and a weekly check is reasonable. These are starting points, not standards. Measure how often a full rescan finds something the stored inventory lacked, and tune from there.
What not to do
Do not email every owner when the re-match runs and finds the same old issue. Alert fatigue ruins the value of continuous checks.
Do not treat "no commits in 90 days" as "no risk". Archive or retire repositories you will not maintain, and track them as exceptions with an owner.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a finding appears over time on a component that has not changed.
Safeguard's continuous monitoring and SBOM scanning re-evaluate your inventory as new advisories appear. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is a nightly full rescan of every repository a good default?
Usually not. A nightly re-match of stored inventories gives the same freshness at a fraction of the cost, with a slower full rescan to catch drift.
What if I have no stored inventory?
Start generating an SBOM on every build. Without it you can only rescan from source, which is slow and misses what was actually deployed.
Last reviewed: 19 October 2026.
