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

Data from the 2024 Unit 42 Cloud Threat Report indicates that 70 percent of organizations have at least one publicly accessible S3 bucket. Despite the maturity of Cloud Native Application Protection Platforms (CNAPP) like Wiz, Orca Security, or Prisma Cloud, which flag these exposures within minutes of creation, the mean time to remediate (MTTR) for such findings often exceeds 150 days.

For a Cloud Security Lead at a North American enterprise managing thousands of cloud accounts, this delay is not a failure of detection. It is a failure of the remediation workflow. The technical visibility provided by a CNAPP identifies the risk but does not resolve the institutional and technical friction required to close it.

The ownership vacuum in multi-cloud environments

The primary reason a critical S3 exposure remains open is the lack of reliable asset metadata. In a typical AWS environment, a bucket might be tagged with a project code that no longer exists or an owner who has left the company. When a CNAPP surfaces a "Public S3 Bucket" alert, the security engineer must first determine which engineering team owns the resource before they can ask for a fix.

In large organizations, this identification process often stalls in Jira or ServiceNow. If the security team lacks the context to prove a bucket is not intentionally public (for example, hosting static assets for a marketing site), they risk breaking production by forcing a private policy. This fear of breaking revenue-generating services leads to a "verification paralysis" where tickets sit in a backlog while engineers manually investigate the traffic patterns of the bucket.

Why generic remediation guidance fails in production

Most CNAPPs provide remediation guidance in the form of generic CLI commands or documentation links. For a cloud security operator, these are insufficient. Applying PutBucketPublicAccessBlock sounds simple, but in a complex environment with existing Bucket Policies and IAM roles, the blast radius of such a change is not always clear from the console.

Standard tools do not account for:

1. The specific Infrastructure as Code (IaC) tool (Terraform, CloudFormation, or Pulumi) used to deploy the bucket.
2. The presence of downstream consumers that might rely on the public access, even if that access was originally a configuration error.
3. The organizational change management process that requires a peer-reviewed pull request rather than a manual click in the AWS Console.

Because the CNAPP is a detection engine, its job ends when the alert is generated. The operator is left to bridge the gap between a security finding and a production-ready code change.

Remediation-as-a-Service: Closing the loop

The bottleneck in cloud security is no longer finding the risk; it is the capacity to execute the fix. This has led to the emergence of Remediation-as-a-Service (RaaS), a model that focuses on the "last mile" of the security lifecycle.

Tamnoon addresses this by moving beyond the simple "alert and report" cycle. Instead of handing a raw finding to a developer, the Tamnoon platform analyzes the specific environment context to provide a verified remediation path. This includes identifying the actual asset owner, assessing the blast radius of a fix, and generating the exact IaC code required to close the hole.

The Tamnoon model incorporates human-supervised remediation through CloudPros who work within the customer's existing change management process. By providing Remediation Confidence Indicators (labeled as SAFE, RISKY, or AWAITING DATA), the platform removes the fear of breaking production. This allows the security team to move from managing a backlog of 5,000 alerts to executing verified fixes that are measured by findings closed rather than findings surfaced.

Overcoming the automated agent objection

A common objection to automated remediation tools is the refusal to grant a third-party agent write access to live production environments. This is a valid concern for CISOs at highly regulated financial services or healthcare firms.

Tamnoon mitigates this by operating on a read-only investigation layer. The platform does not unilaterally change production settings. Instead, it provides the engineering team with the precise, validated code changes needed to remediate the risk through their established CI/CD pipeline. This preserves the integrity of the production environment while accelerating the time to closure.

Operationalizing the cloud security backlog

To reduce MTTR from 150 days to under 24 hours, the focus must shift from detection to orchestrated remediation. Enterprises that have invested heavily in CNAPP tools but still face audit failures or high-risk exposure are typically missing the process layer.

The transition to a remediation-centric strategy involves:

1. Prioritizing findings based on actual reachability and business impact, not just CVSS scores.
2. Automating the discovery of asset owners through historical API logs and IAM analysis.
3. Providing developers with ready-to-merge code instead of links to documentation.

When the security team becomes a provider of solutions rather than a source of tickets, the friction between security and engineering dissolves. This shift is the only way to manage the scale of modern cloud environments without a linear increase in security headcount.