Retention by subtraction: what is never stored
The safest data to hold is data never collected. RowShield’s retention policy is a list of subtractions, decided in advance so that no codepath has to make the right choice under pressure later.
Here is exactly what is kept thin, item by item, with the reason each subtraction exists.
Findings carry shapes, never contents
When the probe finds a table answering unauthenticated requests, the finding records which columns were exposed and how many rows came back — names and a count, never the values themselves. Counts are exact integers rather than bands, because a count is a fact about exposure while a sample would be the exposure itself. Storing a copy of the leak inside the tool that found it would compound the incident, so the record proves exposure without possessing the goods.
Discovered keys fare likewise. An exposed service_role key is stored as a fingerprint: the first six characters plus a length. Enough for a later scan to recognise the same key and avoid re-alarming, and for you to confirm which credential to rotate; not enough to reconstruct or misuse.
Configuration details stay masked
Webhook URLs are stored masked before they reach any browser, because a destination URL frequently embeds a secret token of its own — anyone who can read the alerts page should not thereby acquire the ability to post forged alerts into your Slack.
Network failures resolve to a fixed set of phrases rather than raw driver output. Connection error strings routinely embed hostnames, ports and internal addressing that has no business appearing on a dashboard; mapping them to fixed phrases keeps diagnostics useful and specifics absent. Log scrubbing backs this up across the system, replacing recognised credential shapes with correlatable fingerprints wherever text approaches a log.
The audit trail completes the picture
Retention is thin by subtraction, and verifiable by inspection: the introspection statements are exported constants, the crypto envelopes are specified in source, and the scrubber runs on the write path. Write to info@getveristria.com if you want a walkthrough of any piece of it.
Related questions
- A table leaked customer rows. Is a copy of those rows in RowShield now?
- No. The finding names the exposed columns and a row count. The values were never captured, so they cannot leak from us, appear in a screenshot of our dashboard, or sit in a backup waiting for our own incident.
- Why store even a fingerprint of an exposed key?
- Recognition, not possession: the fingerprint lets the next scan identify the same leaked credential instead of raising a fresh alarm, and confirms rotation succeeded when it disappears — while remaining useless to anyone who steals our database.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.