Schema drift: appeared, came back, disappeared
Findings answer whether a rule matches right now. Drift answers a quieter question: did the shape of the schema change since the last scan? Tables, columns, policies, indexes and storage buckets are all compared snapshot against snapshot, and every difference is recorded as a drift event with its own wording.
Because drift is diffed rather than inferred, it catches the changes nobody announced — the migration that ran in staging but not production, the column dropped by hand during an incident, the policy rewritten in a console at midnight.
What counts as drift
Each scan captures the structure of the database: tables and their columns, the policies attached to them, the indexes backing them, and the storage buckets with their publicity settings. The scanner compares this capture with the previous one object by object.
Only differences become drift events. A schema that has not moved generates nothing, for the same reason unchanged findings generate nothing — repetition is noise, and the interesting sentence is always about the delta. Comparisons happen at capture time inside the scanner, so what reaches you is already reduced to named objects and movements rather than raw catalog output.
Reading the wording on an event
Appeared means the object is new since the last scan: a table added by this morning’s deploy, a bucket created by a script. Came back means the object was seen before, went away, and has returned — the drift equivalent of a regression, and usually a sign that something reintroduced an old pattern. Disappeared means the object is gone: sometimes deliberate cleanup, sometimes evidence that a migration half-ran.
A drift event names the object precisely — schema, table, column or bucket — so the diff reads as a sentence rather than a puzzle. Reading a long diff is easiest in order of risk: policies and buckets first, because they guard data; tables and columns second, because they usually track deploys; indexes last, because they mostly affect performance rather than exposure. If a change was intentional, no action is needed; drift asks you to look, and looking costs seconds when the object is named.
How drift reaches your channels
Drift events travel to your destinations through the same pipeline as findings: transitions only, subject to each destination’s severity threshold, idempotent across retried scans. They also appear in the live scan stream and on the project page, so a quiet channel still leaves a readable trail.
Drift is descriptive, not a verdict. An appeared event is an invitation to look — the accompanying findings tell you whether the new object is actually exposed, and the generated SQL tells you how to close it if so.
Related questions
- Is a drift event itself a security problem?
- Not necessarily. Drift records that structure changed; the rules decide whether the new structure is exposed. A new internal table may be harmless, but the same event would have caught a public bucket before anyone thought to check.
- Can I see drift for a period longer than one scan back?
- Yes. Each project keeps its history, so the dashboard can show when an object first appeared and whether it has come and gone before — often the detail that turns a mystery into a story about a deploy process.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.