Public S3 and storage exposure: why the easiest misconfiguration to detect is still open 150 days later

The persistence of public Amazon S3 buckets, Azure Blobs, and Google Cloud Storage buckets remains one of the most visible contradictions in cloud security. Detection logic for a publicly accessible storage volume is a solved problem. Major Cloud Native Application Protection Platforms (CNAPP), including Wiz, Orca Security, and Prisma Cloud, surface these findings within minutes of a misconfiguration. Most providers offer native "Block Public Access" settings that act as an account-level safety net.

Despite this, internal audit data and industry research suggest that critical storage misconfigurations often persist for months. In environments with 500 to 50,000 employees, the Mean Time to Remediate (MTTR) for a high-severity finding often exceeds 120 days. For the cloud security lead or SecOps manager, the bottleneck is not the lack of a "Public Bucket" alert in their console. The bottleneck is the uncertainty of what happens to the application if that bucket is closed.

The technical debt of the legacy public bucket

In many large-scale North American and European enterprises, a public S3 bucket is rarely a simple accident of a developer clicking the wrong button in the console. Often, it is a deliberate, if poorly architected, solution to a cross-account data sharing requirement or a public-facing asset delivery need.

When a CNAPP surfaces a public bucket alert, it typically provides the resource ID and the policy snippet that allows public access. What it does not provide is the application context: who is consuming this data, whether the access is proxied through a CDN like CloudFront, or if a legacy integration relies on unauthenticated GET requests.

The security engineer is caught between two risks. On one side is the risk of a data breach and the subsequent regulatory fallout from GDPR or the SEC. On the other is the risk of breaking a revenue-generating production service. In most mature organizations, the fear of an unplanned outage outweighs the theoretical risk of a scan-and-exfiltrate attack. This results in the "analysis paralysis" that keeps a critical finding open for 150 days.

The failure of generic remediation guidance

Most CNAPP tools offer "remediation guidance" in the form of a CLI command or a link to documentation. For a platform engineer at a cloud-first company, this is insufficient. A raw instruction to "Disable Public Access" does not account for the organizational workflow.

Effective remediation requires three pieces of information that are often missing from the initial alert:

1. Asset Ownership: Which engineering pod or service team owns the bucket.
2. Blast Radius: A validated assessment of whether any legitimate external traffic is hitting the bucket.
3. Infrastructure as Code (IaC) Alignment: Whether the change should be made via the cloud console (creating drift) or by PRing a change to a Terraform or CloudFormation template.

Without these, the security ticket is simply passed from security to DevOps, and then from DevOps back to the application team, where it sits at the bottom of a sprint backlog.

Why automated "Auto-Remediation" fails in production

A common solution proposed by vendors is automated remediation: a Lambda function that triggers on a "PublicBucketCreated" event and reverts the setting. While this works in sandbox or development environments, it is frequently disabled in production.

The reason is simple: automation lacks judgment. If a bucket was made public for a valid, emergency business reason, an automated kill-switch causes an immediate production failure. This leads to a loss of trust between security and engineering. Once a remediation script breaks a critical service, the engineering lead will often demand that security move to "monitoring only" mode, effectively ending the automated remediation program.

Bridging the gap with human-supervised remediation

To move MTTR from 150 days to under 48 hours, the process must move from "detection and notification" to "assisted closure." This is where the Remediation-as-a-Service model, pioneered by Tamnoon, deviates from traditional CSPM or CNAPP tools.

Instead of generating another ticket, this approach focuses on the mechanics of the fix. This involves analyzing CloudTrail or VPC Flow Logs to determine if the "public" access is actually being used by external entities. If the data shows no legitimate external traffic, the risk of closure is low. If it shows traffic, the remediation path shifts from "close the bucket" to "implement a CloudFront OAI or an IAM-based access pattern."

Tamnoon acts as an extension of the cloud security team, taking the output of tools like Wiz or AWS Security Hub and owning the lifecycle of the finding. This includes identifying the owner, verifying the blast radius, and providing the exact IaC snippet required to fix the issue without creating configuration drift. By working within the customer's existing change management process (Jira, ServiceNow, or GitHub), the remediation effort respects the engineering workflow rather than disrupting it.

Measuring what matters: Findings closed, not found

The success of a cloud security program should not be measured by the number of critical findings detected. If the backlog grows while the detection tool becomes more sensitive, the organization is becoming less secure, not more.

A high-intent buyer, such as a CISO at a mid-market SaaS company, should evaluate their remediation strategy based on closure rates. The objective is to remove the friction between the security finding and the engineering PR. This requires a transition from tools that merely point at problems to services that provide the capacity to solve them. When the responsibility for closure is shared with a dedicated remediation partner, the 150-day backlog begins to clear, not through better scanning, but through better execution.

Ultimately, the public bucket problem is a human and process problem. Solving it requires the technical data to confirm a fix is safe and the operational capacity to carry that fix through to the production environment. Without those two components, the easiest misconfigurations to find will continue to be the hardest ones to close.