Misconfiguration: the doors nobody meant to leave open

A credential door needs a stolen thing. A supply-chain door needs code that runs. A misconfiguration door needs a URL. There is no login event, because nothing logged in; there is no query, because nothing queried. The data was simply reachable, and reachable data gets reached.

That is why the bench counts the export bucket as a path with no undetected-to-detected transition available: query logging moves eight paths from unseen to seen and leaves this one exactly where it was. The only way to see a bucket being read is a log on the bucket, and the only way to stop it is a setting on the bucket.

• Bucket - an object store container. It has its own access model, separate from the warehouse's, and usually weaker because fewer people look at it.
• Public access - two distinct settings: whether an unauthenticated principal can list the objects, and whether it can read them. Listing without reading still tells an attacker the file names and the nightly cadence; reading without listing still works for anyone who has ever seen a URL.
• External stage - the warehouse's pointer to a bucket, used to load from it or unload to it. The stage's location is a bucket path, which makes show stages the fastest way to find buckets the warehouse touches.
• Share - a grant of read access on warehouse objects to another account. Its grantee list is a second set of doors, one per account, each of which has its own users and its own hygiene you do not control.
• Network policy - the allowlist of addresses a credential is allowed to authenticate from. A missing or wide-open policy is the setting that turns a leaked key into a key usable from anywhere.
• Configuration drift - the gap between the setting somebody chose and the setting in force today. Drift is not usually malicious. It is a vendor onboarding that never got its offboarding.

Ironwood's export bucket holds a nightly extract of the customers table, written by the ETL job for the agency. Two settings on the bucket were wrong: anyone could list the objects, and anyone could read them. The first tells a stranger that a file called customers_2026-09-07.csv exists and that a new one arrives every night. The second lets them download it.

On the graph the bucket is two edges: internet to bucket, because it is listable without authentication, and bucket to crown jewels, because the object is the table. Making the bucket private removes both. That is the 5 to 4 rung on the ladder, and the count is one because the path is one; its weight, if the bench weighted by records reached, would be the whole table.

A share granted wider than intended. Ironwood shares a sales summary with a partner. The share's grantee list has two accounts on it: the partner, and an agency whose contract ended fourteen months ago. The agency's account is still live, still has users, and still reads the share on a schedule nobody at Ironwood set. An external stage has the same shape from the other side: its location is a bucket, and whoever can write to that bucket can put objects where the warehouse will load them.

A network policy that allows everywhere. The ETL service key authenticates from any address. Session 2 rotated it, so the copy in git history no longer works. The current key still works from anywhere, which means a future leak is a full door again. An allowlist that restricts the key to the pipeline's own address range turns that future leak into a refused login. It closes exactly one edge on the graph, the service key to the warehouse when used from outside, and it is the one edge the "perimeter firewall only" over-correction actually closes.

Eight of the nine paths pass through the warehouse. A query log on the customers table sees all eight; least privilege narrows what several of them can read; MFA removes the three that start with a phished human. The ninth reads a file from a bucket. It never authenticates to the warehouse, never runs a query, never uses a role. So no warehouse control, not logging, not least privilege, not MFA, has any effect on it. The bench confirms it: switch on every warehouse control and leave the bucket public, and one unseen path remains that is not the insider.

The general rule follows. Every copy of the crown jewels outside the warehouse, every export, share, replica, stage and backup, needs its own inventory row, its own control and its own log. A copy without those three is an open door in a room with no camera, and the warehouse's excellent camera is pointed at a different room.

The job lists four things: every bucket's public-access setting, every share's grantee list, every stage's location, and every network policy's allowlist. It writes them to a dated file and diffs the file against last week's. A new line is a new object somebody created; a changed line is a setting somebody changed. Both go to a human, with the name of whoever made the change if the platform records it.

Two properties make it work. It runs without anyone remembering to run it, so the finding does not depend on the audit calendar. And it compares against last week rather than against a policy document, so it catches the drift the policy never anticipated. A bucket that was private for two years and became public on Tuesday is a one-line diff on Monday.

Every new bucket starts with public access blocked at the account level, so an individual bucket cannot be made public by a policy statement alone; the block has to be lifted deliberately, by someone with the right to do it, in a change that leaves a record. Every new share starts with an empty grantee list and an expiry date. Every new service account starts attached to a network policy.

The cost is real and worth naming. A team that needs a public bucket for a static site has to ask, and the ask takes a day. A vendor onboarding that used to be an afternoon becomes an afternoon plus a ticket. The friction is the control: the day the ask takes is the day somebody writes down why the door exists and when it closes. Ironwood's export bucket had no ticket, because nothing required one.

Nearly every misconfiguration on a data estate has the same origin story. A vendor, agency, contractor or partner needed access; somebody granted it in the fastest way that worked; the engagement ended; nobody owned taking it back. The bucket, the share grantee and the wide-open policy are all this story at different lanes.

The access-control course sets the expiry rule for grants: every grant to a human or an external party carries a date, and on that date it is revoked unless someone renews it in writing. The same rule applies without change to shares, to bucket grants for external accounts, and to network policy exceptions. An expiry that is written into the inventory turns "never removed" into "removed on the date, or renewed by a named person". The weekly diff then flags any share past its expiry as a changed line, whether or not anyone remembered.

• Grant to a named account, never to the public. The agency has its own cloud account; the bucket grants that account read on the prefix it needs. Nothing anonymous.
• Write the expiry next to the grant. In the inventory file, and in the share's comment or the bucket's tags if the platform allows it.
• Name the owner. The person who renews or lets it lapse. A grant without an owner is a grant the diff job will flag every week until someone claims it.

An allowlist on the warehouse says a credential may authenticate only from these addresses. For a service key that is always used by the same pipeline on the same hosts, the allowlist is nearly free and closes a whole class of future incident: the key leaks again, someone tries it from outside, and the login is refused before any query runs.

The bench is honest about how much that is worth on its own. The "perimeter firewall only" over-correction is exactly this control with nothing else, and it leaves 7 paths, 7 undetected, 0 recoverable. It closes one door, the leaked key used from outside. A phished analyst logs in from their own laptop inside the range. The malicious package runs on the CI runner, which is inside the range because it has to be. The export bucket sits outside the warehouse altogether, so the warehouse's allowlist never sees the read. And both insiders were never outside.

So the allowlist belongs on the estate, as the third part of the service-account pattern from session 2, and it belongs in the weekly diff so a detached policy is a flagged line. It does not belong at the top of anyone's list of what to buy, and the number that says so is 7.