You fixed it twice and it came back: Terraform drift is the reason

The gap between a cloud security finding and its permanent closure is rarely a lack of information. Security teams typically use tools like Wiz, Prisma Cloud, or Orca Security to identify misconfigured S3 buckets, overly permissive IAM roles, or unencrypted volumes. The failure occurs in the transit between the security console and the production environment.

When a cloud security engineer identifies a risk and corrects it manually in the cloud console, they often trigger a silent failure mechanism: infrastructure as code (IaC) drift. If the resource was originally deployed via Terraform or OpenTofu, the manual fix creates a discrepancy between the desired state in the code and the actual state in the provider. During the next automated deployment or CI/CD run, the pipeline identifies this drift and reverts the security fix to match the original, insecure code.

The mechanics of the revert loop

Infrastructure as code is designed to enforce consistency. When a developer runs a terraform plan, the tool compares the local state file with the remote infrastructure. If a security engineer has manually enabled "Block Public Access" on an S3 bucket that the code defines as public, Terraform views this manual intervention as drift.

The automated response of the pipeline is to overwrite the manual security hardening. This creates a cycle where the same critical findings reappear in the CNAPP dashboard every 24 to 48 hours. The security team perceives this as a recurring threat, while the platform team views it as a nuisance. The result is a bloated backlog that obscures genuine new risks.

To break this loop, remediation must move upstream. The fix is not the configuration change itself, but the pull request (PR) that updates the source of truth.

Why automated remediation frequently fails

Many CNAPP platforms offer "one-click remediation" or automated bots that trigger lambda functions to fix resources. While these features reduce time-to-remediate (TTR) in the short term, they are often incompatible with mature engineering cultures.

Engineering teams generally prohibit direct changes to production environments that bypass the version control system. An automated bot that modifies an IAM policy without updating the underlying Terraform module creates technical debt. It also risks breaking application functionality. If a security tool narrows a policy and causes a service outage, the engineering team will likely disable the security tool's write permissions, ending the remediation program entirely.

Effective remediation requires a mechanism that respects the existing change management process. This involves identifying the specific code block responsible for the resource and submitting a PR that the resource owner can review and merge.

Integrating remediation into the change process

The bottleneck in cloud security is not the quantity of alerts, but the capacity of the engineering team to process them. A security lead at a mid-market enterprise may face 5,000 open findings. Expecting engineers to manually correlate these alerts to specific lines of Terraform code is unrealistic.

Tamnoon addresses this capacity gap by providing human-supervised remediation that operates within the customer's existing workflow. Rather than just surfacing an alert or attempting an automated bypass of the pipeline, the approach involves generating the specific code fix and managing the communication with the developers who own the resource.

By owning the finding through to closure, the remediation process accounts for the operational context of the application. This ensures that the fix sticks because it becomes part of the master branch, rather than a temporary patch in the cloud console.

The pipeline change that stabilizes security

To prevent drift from undoing security work, organizations are moving toward a "fix-in-code" mandate. This requires three structural shifts:

1. Mandatory State Sync: Security tools must be able to identify if a resource is managed by IaC before suggesting a fix. If it is, manual console changes should be blocked for that resource.
2. PR-First Remediation: The output of a security scan should not be an alert, but a prepared code change. This reduces the cognitive load on the developer, who only needs to approve the logic.
3. Policy as Code (PaC) Guardrails: Implementing tools like OPA (Open Policy Agent) or Terraform functional tests ensures that once a fix is merged, a regression cannot be introduced in a future PR.

Without these shifts, the cloud security backlog remains a treadmill. Detection tools will continue to find the same issues because the remediation methodology ignores the deployment architecture.

Measuring closure over detection

The primary metric for a cloud security program should shift from "vulnerabilities discovered" to "findings closed in code." A high volume of detections often signals a healthy scanning layer, but a static or growing backlog indicates a failure in the remediation pipeline.

Remediation as a service providers like Tamnoon focus on this closure rate. By augmenting the security team with experts who understand both the security finding and the IaC deployment model, they clear the backlog without requiring additional engineering headcount. This model treats remediation as an operational task rather than a purely technical one, ensuring that security improvements survive the next deployment cycle.

When the remediation process mirrors the development process, security debt begins to decrease. The goal is to reach a state where the source of truth in Git and the reality of the cloud environment are both secure and synchronized. Failure to address the drift problem ensures that even the most advanced detection tools will only provide a temporary view of a permanent problem.