Scan freshness is the age of the most recent completed, successful scan for each asset or repository. Measure it per asset as now minus last successful scan time, report the distribution rather than one average, and set separate limits for high exposure and low exposure systems.
Define the terms first
Three words get mixed up. Scan time is when a scan finished. Data time is when the advisory information used by that scan was last updated. Display time is when the dashboard last refreshed. Freshness should be based on a completed, successful scan time, because a scan that started and failed tells you nothing about the asset.
| Term | Question it answers |
|---|---|
| Last successful scan age | How old is what we know about this asset? |
| Advisory data age | How current were the advisories that scan used? |
| Dashboard lag | How long after a scan does a number appear? |
Why the average is a trap
Say that one hundred repositories scan nightly and five have not scanned in months. The average age looks fine. The five stale repositories may be the ones nobody watches. Report the share of assets over each age limit, and the oldest ten, so that the tail is visible.
Setting limits
Pick limits by exposure and change rate, not by one number for all. A service that ships daily and faces the internet needs a short window. A frozen internal tool can have a longer one. Write the limit down, assign an owner, and treat a breach as a finding in its own right.
A simple scheme:
- Tier assets by exposure and criticality.
- Give each tier a maximum scan age.
- Show, per tier, the share of assets inside the limit.
- List every asset outside it, with the owner.
The newly published advisory problem
A scan is a snapshot of an asset against the advisories known at that moment. An asset scanned yesterday can become vulnerable today without any change to it, because a new advisory arrived. That is why advisory data age matters, and why point in time results age even when the scan is recent. Continuous matching of stored inventories against new advisories closes this gap better than rescanning everything more often.
Checking your own numbers
Pull the raw list of last successful scan times and compute ages yourself. Compare the result with the dashboard. Look for three common errors: assets with no scan time at all being dropped from the calculation, failed scans counted as successful, and time zones mixed in the timestamps. Missing values are the most dangerous, since an asset that has never been scanned usually vanishes from averages. Show it as its own bucket named "never scanned".
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Continuous monitoring re-checks stored inventory when new advisories arrive. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Is scanning daily always enough?
Not necessarily. Daily scans still leave a gap between an advisory being published and the next run. Matching stored inventory against new advisories narrows it.
What should happen to an asset that has never been scanned?
Show it as its own bucket, assign an owner, and treat it as the first item to fix, because it is invisible in any average.
Last reviewed: 19 October 2026.
