Why CSPM Findings Reappear After You Fix Them and How to Close Them Permanently

The most common cause of CSPM finding reappearance is the simplest: the remediation was applied to the live cloud resource in the AWS console, Azure portal, or GCP console, while the Terraform, CloudFormation, CDK, or Pulumi template that deployed the resource still contains the original misconfigured value.

The next time the infrastructure pipeline runs -- whether for a deployment, a template refresh, or an auto-scaling event -- it redeploys the resource from the unchanged template and overwrites the manual fix.

The indicator that this is your root cause: the finding reappears on the same resource type every time the deployment pipeline runs, not at a random interval.

The fix requires two changes in parallel, not one: update the IaC template to remove the misconfiguration, and apply a configuration change to the currently running resource. Both steps together produce a finding that is closed in the CSPM and that remains closed after the next deployment.

For organizations using Terraform, the workflow is: identify the resource block in the Terraform configuration, change the misconfigured attribute value, run terraform plan to verify the change scope, and apply. The IaC change and the live resource change happen simultaneously through the terraform apply step -- there is no need for a separate manual console change.

For organizations where infrastructure is deployed through an automated pipeline but the IaC templates are maintained by a different team than the security team doing CSPM remediation, this root cause requires a process change: CSPM findings must be routed to the IaC-owning team with the specific template path and attribute change required, not just the CSPM finding description.

The second root cause is related to IaC drift but distinct: the affected resource was not deployed from an IaC template at all. It was manually provisioned in the cloud console, perhaps before the organization adopted IaC practices, and there is no template to update.

In this scenario, there is no automated process overwriting the fix. But there is also no automated process protecting it. The finding reappears because someone else (or the same person, months later) recreates the resource without the security configuration, or because a misconfigured copy of the resource is created by cloning the original.

The fix here is not just remediating the finding but also formalizing the resource as managed IaC. This means: importing the existing resource into the IaC state (terraform import for Terraform), codifying the correct configuration in the template, and ensuring future deployments and modifications go through the IaC pipeline rather than the console.

This is more work than patching the running resource, which is why it is often deferred. But without it, the organization has a class of cloud resources with no formal configuration management -- which means no repeatable security configuration, no audit trail for configuration changes, and no way to enforce consistent security posture across multiple instances of the same resource type.

The operational signal for this root cause: the finding is on a resource that shows no IaC state association in your Terraform or CloudFormation stack inventory.

The third root cause is the most difficult to diagnose: the fix was applied correctly to both the running resource and the IaC template, but the finding reappears because neither the resource nor the template was the actual source of the problem.

This happens when a misconfiguration originates from a module, a shared configuration baseline, or an organizational default that overrides resource-level settings. Common examples:

Terraform modules with misconfigured defaults. A security group module that defaults to 0.0.0.0/0 ingress rules creates the same finding every time any team uses the module, even if the calling team's resource-level configuration is correct. Fixing the calling configuration leaves the module unchanged, so the next resource deployed from the module has the same finding.

AWS Organizations default settings. An S3 account-level public access block setting that is disabled allows all buckets to be created without the block enabled. Enabling it on individual buckets fixes the finding on those buckets but leaves the account default unchanged, so any new bucket created in the account has the finding immediately.

Shared pipeline defaults. A CI/CD pipeline that deploys cloud resources with default security group rules, default IAM permissions, or default encryption settings propagates those defaults to every resource it deploys, regardless of what individual resource configurations specify.

The diagnostic question for this root cause: is the same finding appearing on multiple resources of the same type across different teams? If yes, the source is a shared module, account default, or pipeline default -- not individual resource configurations.

The long-term architectural fix for CSPM finding reappearance is shifting from detection-and-remediation to prevention. Policy-as-code tools enforce security requirements at the deployment stage, preventing misconfigured resources from being deployed in the first place, rather than detecting and reporting them after they are running.

Three enforcement mechanisms, in order of where they act in the deployment pipeline:

IaC-level enforcement with OPA (Open Policy Agent) + Conftest. Conftest runs OPA policies against Terraform plans, CloudFormation templates, and Kubernetes manifests before deployment. A policy that rejects any Terraform plan containing an S3 bucket without server-side encryption enabled prevents the bucket from being deployed with that misconfiguration, rather than detecting it afterward. This enforcement runs in the CI/CD pipeline and fails the pipeline when a policy violation is found.

Cloud-level enforcement with AWS Service Control Policies (SCPs) or Azure Policy. SCPs are organization-level controls that prevent IAM principals from taking specific actions across all accounts in an AWS Organization, regardless of what IAM policies say. An SCP denying s3:PutBucketPublicAccessBlock with a "s3:PublicAccessBlockConfiguration": "false" condition prevents any principal from disabling the public access block, even if they have IAM permissions to do so. Azure Policy equivalents enforce the same controls at the Azure Management Group or subscription level.

Admission control with OPA Gatekeeper (Kubernetes). For containerized workloads, Gatekeeper enforces pod security policies at the admission stage, rejecting deployments that violate defined security constraints before the pod is created.

Even with policy-as-code enforcement in place, CSPM tools remain valuable for detecting drift from resources that existed before enforcement was deployed, resources in accounts or regions not yet covered by enforcement, and configuration changes made outside of automated pipelines.

The verification cycle that closes the loop between CSPM detection and confirmed permanent remediation:

Step 1: CSPM finding identified. Record the finding, the affected resource ARN or ID, the specific misconfigured attribute, and the CSPM finding ID.

Step 2: Root cause identified. Is this IaC template drift, a manually provisioned resource, or a shared module or account default issue? The root cause determines the correct fix path.

Step 3: Fix applied at the correct source. IaC template, Terraform module, shared pipeline configuration, or account-level policy, as appropriate. Do not apply a console fix without a corresponding source fix.

Step 4: Deployment completed. Run the IaC pipeline to redeploy the fixed configuration. Verify the resource configuration matches the fixed template.

Step 5: CSPM re-scan confirmed. Trigger a CSPM rescan of the affected resource. Confirm the finding is closed.

Step 6: Policy enforcement added (if not already present). Create or verify that a policy-as-code check covers this finding class, so future resources in this category are blocked from deploying with the same misconfiguration.

Step 6 is the step that most remediation workflows skip. Without it, the process is purely reactive: CSPM finds a problem, team fixes it, CSPM finds it again on a new resource, team fixes it again. Policy-as-code at Step 6 converts each remediation into a preventive control.

Not every CSPM finding class warrants a policy-as-code enforcement rule. The investment in writing, testing, and maintaining a Conftest policy or AWS SCP is only justified when the finding class is high-severity, appears frequently enough to be a pattern rather than an isolated misconfiguration, and maps to a control that is meaningful for your threat model.

Prioritization criteria for policy-as-code investment:

High reappearance rate. If the same finding class has appeared more than three times across different resources in a 90-day period, a policy rule pays for itself almost immediately.

High severity in your environment. S3 bucket public access, encryption at rest for databases containing regulated data, and overly permissive security groups on publicly accessible resources are examples where the business impact of a missed finding justifies the enforcement investment.

Low implementation risk. Some policy enforcement rules are higher risk than others. An SCP that denies disabling encryption is low risk -- the only thing it prevents is a misconfiguration. An SCP that denies modifications to security groups requires more careful scoping to avoid blocking legitimate operational changes.

Maps to a recurring audit or compliance finding. If the same finding class appears repeatedly in your SOC 2 or ISO 27001 assessments, automated enforcement demonstrates to auditors that you have a preventive control, not just a detection-and-remediation workflow -- which is a materially better audit posture.

Start with two or three high-priority finding classes. Implement the policy rules, validate them in a non-production environment, and deploy them. The feedback loop from seeing those finding classes stop appearing in your CSPM tool provides the organizational confidence to expand enforcement coverage.