Operations
Snapshot freshness: why 'last seen' timestamps matter for Linux evidence
· ~6 min read · Jamie, Founder, Blackglass
Blackglass is not a real-time IDS. It is a scheduled (or push-triggered) integrity product — which means every finding carries a timestamp that really means “as of the last successful scan”. That is good enough for change control and most incident triage, but only if we are honest about the lag. This post explains how we document freshness, why auditors ask, and where the hard limits sit.
What “fresh” means here
For each host we show last check-in time, last successful scan completion, and the baseline version the diff ran against. The console never implies sub-second visibility unless you are on a tier that supports continuous collection and the agent is actually heartbeating. When a push agent misses windows, the UI surfaces stale state explicitly — greyed rows, banners, and webhook payloads that include the same metadata so automation does not silently assume freshness.
Why this shows up in audits
ITGC reviewers increasingly ask: “if this screenshot was taken at 14:32, how do we know the server had not changed at 14:31?” The answer is always contractual: you either claim continuous instrumentation, or you claim bounded staleness. We chose the latter and wrote it down in the public snapshot freshness doc so security teams can paste a link into the evidence pack instead of inventing prose in Word.