An incremental scan analyses only the parts of a target that changed since the last scan and reuses earlier results for the rest. It can safely skip unchanged files, layers and manifests. It cannot skip re-matching against new advisory data or policy changes, because those change without any code change.
Definition
Incremental scanning means a scan reuses stored work. The scanner compares the current state of a target against a recorded earlier state, finds the difference, analyses that difference, and merges it with prior results. Compare that with a full scan, which starts from nothing every time.
The benefit is time. On a large repository or a layered image, most content is identical between runs. Re-analysing it is waste.
What is safe to skip, and what is not
| Part of the scan | Skip when unchanged? | Reason |
|---|---|---|
| Parsing source files | Yes | Same content, same parse |
| Unpacking image layers | Yes | Layer digest identifies the content |
| Dependency resolution from a lockfile | Yes, if the file hash and resolver version match | Deterministic inputs |
| Matching components to advisories | No | New advisories arrive daily |
| Policy evaluation | No | Policies change |
| Rules or analysers that look across files | Not safely | A change in one file can alter results elsewhere |
That last row is where incremental scans go wrong. Some analyses, such as data flow across modules, depend on more than the changed file. A scanner that only re-reads the changed file can miss a new path that passes through unchanged code. Good implementations track dependencies between files and re-analyse affected neighbours, or they fall back to a full scan when they cannot be sure.
How to decide on a cadence
Most platforms run incremental scans on every change and a full scan on a longer cycle. The full scan acts as a correctness check and catches state that drifted. A common pattern:
- Pull request: incremental, diff based, fast feedback.
- Merge to the main branch: incremental against the last main scan.
- Weekly or monthly: full scan, compare against the incremental result.
- After a scanner upgrade: full scan, since analysers may have changed.
- After a rule or policy change: re-evaluate stored results, and full scan if the rule needs source.
If the periodic full scan finds issues the incremental scans missed, treat that as a bug report about your incremental logic.
Questions to ask about any incremental feature
- What is the unit of change: file, layer, package, commit?
- Does it handle renames and moves, or does it treat them as delete plus add?
- What happens when the baseline is lost or corrupted?
- Is the scanner version part of the baseline, so an upgrade forces a rebuild?
- Can you force a full scan on demand?
Try it yourself
Click through it at your own pace, or open it full screen. Pay attention to what the pull request check reports about the change itself, which is the incremental view.
Safeguard scans pull requests with policies and gates, and it keeps inventory so dependency findings are re-evaluated as advisories change. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is an incremental scan less accurate than a full scan?
It can be, if the analysis crosses file boundaries and the tool does not track those dependencies. A scheduled full scan is the safety net.
Do I still need to rescan unchanged code?
Yes, at the matching step. The code did not change, but the advisory data did.
Last reviewed: 19 October 2026.
