CSPM in Practice: How to Actually Remediate Findings Instead of Watching the Count Grow

CSPM finding counts grow for three structural reasons that are independent of how hard the security team is working. First, most cloud environments have no prevention controls: findings are detected after the misconfigured resource is deployed, not prevented from being deployed in the first place. Every time a developer creates a new S3 bucket, a new security group, or a new storage account, CSPM checks it and generates findings for every control it violates. With hundreds of developers deploying resources daily, the incoming finding rate far exceeds the remediation rate for any team working in reactive mode.

Second, most cloud resources are not owned. CSPM tools attach findings to resources (a specific S3 bucket, a specific VM, a specific storage account), but the organizational structures that determine who is responsible for those resources are not encoded in the tool. When a finding appears, no one is automatically assigned to fix it. The security team may route it manually, or it may sit in a finding queue with no assigned owner. Without automated ownership assignment based on resource metadata (tags, account structure, folder hierarchy), findings accumulate in an unowned backlog.

Third, manual console fixes are impermanent. An engineer who sees a finding for an open security group port fixes it in the AWS console, the finding closes, and then the CI/CD pipeline runs and redeployes the Terraform configuration that includes the open port. The finding reopens. This cycle of fix-and-reopen is extremely common in environments where CSPM remediation happens outside of the IaC source of truth. Each finding fix that is not reflected in IaC will reappear on the next deployment, generating duplicate work and frustrating engineers who cannot understand why the same issue keeps coming back.

CSPM tools assign risk scores to findings using some combination of severity, asset criticality, and in more advanced tools, attack path analysis. Risk score alone is insufficient for triage because it does not capture exploitability, public exposure, or data sensitivity in a way that maps to actual business impact. A critical-severity finding on a development account with no sensitive data and no public exposure is materially less urgent than a medium-severity finding on a production database with customer data that is reachable from the internet.

A practical triage framework adds four dimensions to the tool-assigned risk score: exploitability (is there a known attack technique that uses this misconfiguration, and has it been observed in the wild), public exposure (is the affected resource reachable from the internet without authentication), data sensitivity (does the resource contain or have access to sensitive data such as PII, financial data, or credentials), and asset criticality (is this resource part of a production system, a customer-facing service, or a security control). Finding score should be adjusted based on these four factors. A finding on a publicly accessible S3 bucket with customer data that requires no authentication to read scores at the top of any triage list regardless of the tool's original severity assignment.

The five finding categories that should be fixed before anything else in any cloud environment are: publicly accessible storage buckets with no authentication requirement (S3 bucket ACL public, Azure Blob container anonymous access), exposed administrative interfaces on port 22, 3389, or cloud provider management ports accessible from 0.0.0.0/0, root account or global administrator credentials without MFA enabled, security groups or network security groups allowing unrestricted inbound access to database or internal service ports, and unencrypted data stores (RDS instances, storage accounts, disk volumes) that are also publicly accessible. These five categories represent the configurations most commonly exploited in cloud breaches and have the clearest, most unambiguous remediation paths.

The operational foundation of CSPM remediation at scale is automated ownership assignment. Every finding must route to the team responsible for the affected resource without manual intervention from the security team. The mechanism is cloud resource tagging: every resource in the environment should have at minimum a team or owner tag and an environment tag (production, staging, development). These tags provide the mapping from resource to responsible team.

Building the tag-to-team mapping requires two investments. First, a tagging policy must be enforced so that all resources have the required tags. AWS Service Control Policies, Azure Policy, and GCP organization policies can all enforce that resources without required tags cannot be created. This enforcement should be applied to new resources immediately; remediating untagged legacy resources is a separate backlog item. Second, the tag values must be mapped to actual team identifiers in your ticketing system or security platform. A tag value of team:payments should map to the Jira project or PagerDuty team for the payments engineering team.

CSPM platforms that support Jira, ServiceNow, or GitHub Issues integration can create tickets automatically when findings are opened and close them when findings are resolved, using the resource tag to determine the ticket destination. This integration is the mechanism that removes security as a routing bottleneck: findings go directly to the responsible team without a security engineer manually assigning each one. The security team's role shifts from routing to monitoring (are teams remediating within SLA, are suppression rates in acceptable ranges, are critical findings getting escalated) rather than individual ticket handling.

SLA tiers tied to finding severity provide the structure that makes the workflow accountable. A reasonable starting point is: critical findings (publicly exposed data, no-auth access to sensitive resources) require acknowledgment within 24 hours and remediation within 7 days; high findings require acknowledgment within 72 hours and remediation within 30 days; medium findings require remediation within 90 days; low findings are tracked but have no fixed SLA. These tiers should be agreed with engineering leadership before implementation, because they create accountability for teams that are not accustomed to being measured on security finding remediation time.

Infrastructure as code is the source of truth for cloud configuration in modern environments. When CSPM finds a misconfiguration, the fix must be made in the IaC definition of the resource, not in the cloud console. A console fix closes the CSPM finding until the next deployment, at which point the IaC definition redeploys the misconfigured state and the finding reopens. This cycle is the most common source of frustration in CSPM programs and the leading reason finding counts do not decrease despite ongoing remediation effort.

For Terraform environments, CSPM findings map to specific Terraform resource attributes. A finding for an S3 bucket with public access maps to aws_s3_bucket_public_access_block resource or the acl = "public" attribute on aws_s3_bucket. A finding for an unencrypted EBS volume maps to the encrypted = false attribute on aws_ebs_volume. The remediation workflow is: identify the Terraform resource managing the affected cloud resource (using the resource ID in the finding to locate the Terraform state entry), update the attribute in the Terraform source file, create a pull request, pass code review, and apply. The CSPM finding closes after the next apply syncs the corrected configuration to the cloud.

The challenge in practice is that many cloud resources were not created by IaC or were created by IaC that has drifted from the actual resource state. Terraform drift occurs when someone modifies a resource in the console after it was created by Terraform; terraform plan then shows the console state and the Terraform state are different. Before remediating a finding in IaC, running terraform plan on the relevant module identifies any existing drift that must be resolved before the security fix can be applied cleanly. Unresolved drift can cause Terraform applies to fail or to reset legitimate configuration changes made outside of IaC.

Prevention controls that stop misconfigurations from deploying in the first place are complementary to CSPM. Policy-as-code tools like Checkov, tfsec, and KICS scan Terraform and CloudFormation files in CI/CD pipelines before deployment and fail the pipeline if security policy violations are present. Configuring these tools to run on every pull request means misconfigurations are caught at code review time rather than after deployment, when a CSPM alert generates a finding and routes it through the remediation workflow. The combination of pre-deployment scanning (prevention) and CSPM (detection for resources that bypass the IaC pipeline or have drifted) addresses both the prevention and remediation sides of the problem.

Suppression is the mechanism for telling a CSPM tool that a specific finding is accepted as-is and should not continue appearing in the active finding count. Suppression is legitimate and necessary for some findings: compensating controls that address the risk without matching the specific configuration the CSPM check expects, findings that are false positives for a specific resource's use case, and findings in development environments where the risk profile differs from production. Suppression becomes a problem when it is used to make the finding count look better without actually addressing the underlying risk.

Acceptable suppression criteria include: the resource is in a non-production environment with no sensitive data and no production traffic; the finding is a known false positive for this resource type (the CSPM check logic does not account for a specific configuration pattern that is actually secure); or a documented compensating control addresses the risk (a finding for no WAF on an application server is acceptable if the application sits behind a WAF that CSPM cannot detect). Unacceptable suppression criteria include: the finding is too hard to fix, no one knows who owns it, the remediation requires a developer to make a change and they have not responded, or there is a plan to fix it eventually. These are process failures that suppression hides rather than resolves.

Every suppression should have an expiry date (90 days maximum) and a business justification attached as a comment. Quarterly suppression review should evaluate every active suppression: has the compensating control changed, has the resource moved to production, has the false positive been confirmed by the vendor. Suppressions that exceed 90 days without re-justification should be removed and the underlying finding re-evaluated.

For CSPM tool selection, four products dominate enterprise deployments. Wiz uses an agentless, graph-based model that connects cloud resources, identities, network paths, and vulnerabilities into a unified risk graph, enabling attack path analysis that shows which misconfiguration combinations create the most significant real-world risk. Its strength is contextual prioritization. Prisma Cloud (Palo Alto Networks) provides broad coverage across CSPM, CWPP, CIEM, and IaC scanning in a single platform; it is the natural choice for organizations with Palo Alto network security products. AWS Security Hub aggregates findings from AWS native services (GuardDuty, Inspector, Macie) and partner tools, provides free CIS AWS Foundations Benchmark compliance checking, and is the right starting point for AWS-only environments without a budget for a third-party tool. Orca Security provides agentless scanning with a cloud-native approach similar to Wiz; it is strong on vulnerability context and data classification.

The CSPM metrics that show real security improvement are not finding count (which reflects tool coverage and environment size as much as security posture) but finding age distribution, mean time to remediate by severity, and the ratio of new findings opened to findings closed. Finding age distribution shows whether the backlog is aging out (most findings are over 90 days old, indicating the program is not making progress on existing debt) or being addressed (most findings are under 30 days old, indicating active remediation). A healthy program has an aging distribution that skews toward recent findings and an MTTR that decreases over time.

The new-finding rate versus remediation-rate ratio is the metric that determines whether the program is winning or losing. If 100 new findings are opened per week and 80 are closed, the backlog grows by 20 per week regardless of effort level. Reducing the new finding rate (through policy-as-code prevention in CI/CD pipelines) is as important as increasing the remediation rate, and often easier to achieve with less team time. Instrumentation that shows both the incoming rate and the remediation rate in the same dashboard makes the dynamics visible to engineering leadership in a way that drives investment in prevention.

Connecting CSPM findings to the developer workflow reduces time-to-fix and removes the friction that leads to suppression-as-avoidance. Creating a GitHub Issue or Jira ticket directly from a CSPM finding, tagged with the affected resource, the finding severity, the remediation guidance, and a link to the relevant IaC file, puts the fix in the engineer's existing workflow rather than requiring them to log into the CSPM tool. Wiz, Prisma Cloud, and Security Hub all support native integrations to GitHub, Jira, and ServiceNow. Some teams go further and configure automatic pull requests for common finding types where the fix is deterministic (S3 public access block, EBS encryption, RDS backup retention), using tools like Drata or custom Lambda functions triggered by Security Hub findings.