1.4 Incremental Scanning and Auto-Resolution
1.4.1 What Incremental Scanning Means in CBOM Secure
A full scan re-examines every target and re-reports everything it finds. An incremental scan reports only what has changed since the last scan of the same scope. The distinction matters for two reasons: scan duration on large estates, and the ability to tell disappearance from absence.
-
Reduced scan window: only changed material is examined and transmitted, so a repeat scan over a large filesystem or repository completes in a fraction of the time.
-
Reduced ingestion load: fewer staged documents per cycle means a shorter deduplication pass.
-
Accurate lifecycle: because the platform knows a scan covered a scope completely, it can conclude that a material previously seen in that scope and not reported this time is genuinely gone rather than merely unscanned.
1.4.2 The Scan Cycle
Each scan records its scope and its scan time. On the next scan of the same scope:
The sensor determines what has changed within the scope and reports those items.
Each reported item flows through staging and consolidation as normal. A material already known keeps its canonical identity and has its footprint updated; the last-seen time on the affected deployment advances.
Materials known in the scope but not reported become candidates for resolution.
A history snapshot is written only where the comparison shows a tracked field actually changed, so an incremental scan that finds nothing new writes nothing at all.
Off-grid scans default to full rather than incremental, because the bundle carries no prior-state baseline and the operator cannot be assumed to have run the previous cycle from the same media.
1.4.3 How Auto-Resolution Works
Resolution is how the platform records that a material has gone away without deleting it. Deleting would destroy the audit trail; leaving it active would overstate the estate.
When a scan completes a scope and a previously active material in that scope is not reported, its status moves to resolved.
A history snapshot is appended with change type resolved, so the timeline shows the date it stopped being observed.
The material stays in the inventory and stays queryable. Dashboards and reports filter on status, so resolved material drops out of current-state views while remaining available for historical and point-in-time analysis.
The point-in-time analysis widgets depend on this. Because status changes are versioned rather than overwritten, the platform can reconstruct what the estate looked like on an arbitrary past date — inheriting state across intervals where nothing was scanned, and honouring resolution and reactivation at the dates they actually occurred.
1.4.4 Reactivation
If a resolved material is reported again — the certificate was reinstalled, or the host came back — it is not created afresh. Its canonical identity is unchanged, so consolidation finds the existing record, moves its status back to active, and appends a snapshot with change type reactivated. The timeline therefore shows a gap rather than two unrelated materials, which is what makes a recurring finding visible as recurring.