The Bucket Nobody Remembered

Public storage left behind by a discontinued project should be treated as an active exposure until someone finds it, removes public access, and verifies what data remains. The practical fix is an ownership process that survives the project, not a cleanup task that depends on someone remembering.

A public bucket can sit quietly through a product launch, a team reorganization, and a change in cloud accounts. Then a customer-data alert arrives on Monday morning and security has to reconstruct a decision nobody documented: who created the resource, what it was meant to hold, whether it still serves anything, and why public access remained available.

The issue is rarely the storage service alone. It is the gap between a project ending and its infrastructure being formally retired.

Discontinued projects leave operating systems behind

Teams usually mark a project complete when the feature is removed, the vendor contract ends, or the engineers move on. Cloud resources follow a different calendar. Buckets, service accounts, access policies, backup copies, and deployment credentials can remain long after the product work has stopped.

That makes “unused” a risky label. A bucket may be empty today but still have a public policy. It may contain a test export created during an incident. It may be fed by a forgotten job that runs once a month. Until an owner checks those details, the resource is an unknown part of the company’s attack surface.

This is why security reviews that focus only on new deployments miss an important category of risk. The oldest resources often have the weakest documentation, the broadest permissions, and the least obvious owner. They were created before current controls existed, or during a deadline when the team intended to “fix it later.”

Later has no calendar invite.

Public access is a governance failure before it becomes a breach

A public storage bucket can expose data because someone made a poor configuration choice. It can also stay exposed because nobody has clear responsibility for detecting and closing that choice after the original work ends.

Microsoft’s reported security progress gives a useful scale for the problem. The company says it has removed public access from more than 732,000 resources, alongside remediation of more than 550,000 critical or high-risk open-source vulnerabilities. Those figures do not tell us what any one organization should expect to find. They do show that access cleanup is ongoing operational work, even in an organization with mature security programs and extensive automation.

The useful question for a founder or technology leader is therefore more specific than, “Do we have public buckets?”

Ask:

• Which public resources exist today, and who can explain why each one must be public?
• Which resources belong to discontinued products, experiments, migrations, or former vendors?
• What data classification applies to every bucket that has ever been reachable from the internet?
• What happens when the designated owner leaves the company or changes teams?

An inventory without an accountable person becomes a list of future alerts. An owner without a review deadline becomes a name in a dashboard.

Retire infrastructure with the same discipline as product code

A better offboarding process starts before a project ends. Put cloud resources, identities, repositories, third-party integrations, and data stores on the project’s closeout checklist. The goal is to create a short, reviewable record while the people who built the system can still answer basic questions.

For each storage resource, record its purpose, owner, data type, access model, retention requirement, and planned retirement date. If the bucket must remain public, document the reason and the exact objects or paths that require it. Broad public access should need an explicit exception, renewed on a schedule.

Then make the cleanup verifiable. Delete a resource when policy allows. Otherwise, remove public access, rotate any related credentials, disable scheduled jobs, and test whether a dependent system fails. That final check matters. Teams often preserve an unnecessary public setting because they are afraid to break an unknown dependency. A controlled test turns that fear into an answer.

The same discipline applies to identities. A bucket with private access can still be exposed through an old service account, a stale deployment token, or a role granted during a migration. Microsoft’s report of 99.97% phishing-resistant MFA coverage across user and device pairs points to a broader lesson: controls work best when coverage is measured, not assumed. Track the remaining exceptions and give each one an owner.

Make forgotten resources visible before an alert does

The goal is not a perfect asset inventory on day one. It is a system that steadily reduces the number of resources nobody can explain.

Start with a weekly report of internet-reachable storage and services. Group the results by owner, environment, creation date, and last activity. Flag resources with no owner, no recent deployment history, or names tied to archived projects. Those flags are prompts for review, not proof that a resource is safe to delete.

Pair that report with a simple decision deadline. An owner should either confirm the resource’s purpose, move it behind the right controls, or retire it. If no one can claim it, escalate the decision instead of letting uncertainty preserve the exposure.

This work can feel unglamorous beside feature delivery or a new AI pilot. It prevents the kind of Monday morning where the first task is explaining why customer data was still sitting in a bucket that belonged to a project everyone believed had ended. For a related look at security blocking a project before rollout, see Monday, 9:07 AM: Security Rejects the Pilot.

Sources

Microsoft security reporting provided in the event context.