Yes, rescan it. The code in an old release is frozen, but the vulnerability records about its dependencies keep growing. A clean result from last year only tells you what was known last year. Match the stored inventory of that build against today's advisories, and you do not need to rebuild.
Why old builds get new findings
A scan is a comparison between two things: what is inside the build, and what is publicly known about it. Only the second thing moves. Advisories get published for old versions, and existing records are corrected, widened or withdrawn. NVD says submissions rose 263 percent from 2020 to 2025, so the volume of records to compare against keeps climbing.
So a release that was clean at ship time can carry several open advisories today without a single line changing.
Which old builds deserve a rescan
You will not rescan everything with equal urgency. Rank by exposure.
- Anything still deployed and reachable from the internet.
- Anything shipped to customers who run it themselves, such as installers, appliances and mobile apps.
- Long term support branches you still patch.
- Archived releases you no longer support. Rescan these rarely, and record the result so a customer question has an answer.
How to rescan without rebuilding
The cheapest method is to keep an SBOM for every release and match it again later. An SBOM is a list of the components in a build, in a standard format. Matching a list is fast, and it does not need the source tree or the build environment.
If you have no SBOM for an old release, you have two options. Rebuild from the tagged source in a clean environment and generate one, or scan the shipped artifact or container image directly. Be aware that a rebuild can pull different transitive versions unless the lockfile is pinned, so treat that result as an approximation.
What to do with the results
| Finding in an old build | Sensible response |
|---|---|
| Reachable, exploited in the wild | Treat as urgent, patch the supported line |
| Present but code path not used | Record the reasoning, schedule a fix |
| In an unsupported release | Notify customers if they still run it, document end of life |
Write down the decision either way. Auditors and customers care more about a dated, reasoned record than a perfect number.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how a stored inventory is checked again when new advisory data arrives.
Where Safeguard fits
Safeguard's SBOM and dependency scanning stores what each build contains, and reachability analysis helps separate findings in code paths you call from ones you never run. A free scan shows the inventory view for a project.
Quick check
Do I need the original source to rescan an old release?
Not if you kept an SBOM or the shipped artifact. Matching the component list against current advisories is enough for a first pass.
How often should archived releases be rescanned?
Often enough to answer a customer question with a dated result. Quarterly is a common starting point, but pick a rhythm you will keep.
Sources
Last reviewed: 19 October 2026.
