TL;DR
- Cloud security posture is set when you write the cloud configuration (in Terraform), not when you deploy it. By the time a CSPM scan flags a gap, the exposure window is already open.
- Cloud infrastructure is defined in configuration files before it is ever deployed. Most posture gaps (missing audit logs, unencrypted buckets, and absent flow logs) already exist in those files as missing or wrong settings, and standard code review isn’t built to catch compliance control gaps.
- Opsera’s compliance audit agent assessed a real cloud configuration (in Terraform) before deployment, found 15 SOC 2 control gaps in the code, and produced fix-ready diffs with no running environment needed.
- Four AWS configuration changes (in Terraform) closed the highest-severity gaps in under three hours, moving the compliance score from 12% to 30% before the infrastructure ever deployed.
Orgs associate cloud security posture management with scanning cloud environments after infrastructure has already been deployed. Security teams use CSPM platforms to identify misconfigurations, compliance violations, exposed assets, and security risks across existing cloud environments.
While this approach provides visibility into existing risks, it raises an important question:
If cloud security posture is largely determined by infrastructure decisions, why are we waiting until the infrastructure is in production to evaluate it?
This article explores how cloud security posture is created, why traditional compliance audits find open ports, missing audit logs, and unencrypted storage only after they are already operational in a live environment, and how evaluating Infrastructure as Code before deployment allows organizations to close those gaps before any exposure begins. Using a real-world assessment performed with Opsera on a Terraform-managed AWS environment, we will walk through a Terraform assessment that surfaced 15 SOC 2 gaps before a single AWS resource was deployed, and why it caught a class of risk that post-deployment scanning cannot reach.
What is Cloud Security Posture Management?
Before examining where CSPM falls short, it helps to be precise about what cloud security posture is and what the tooling around it is designed to do.
Posture covers more than open ports
Cloud security posture is not a product or a dashboard score. It is the overall security condition of a cloud environment at a given point in time, expressed across several domains simultaneously:
- Identities and access controls: which principals can access which resources, and under what conditions
- Network exposure: which ports accept inbound connections, from which IP ranges, and whether traffic flows between tiers that should be isolated
- Resource configurations: whether storage is encrypted, whether audit logs are enabled, and whether key rotation is configured
- Data protection controls: whether backup schedules run, whether encryption covers every data store, and whether access to sensitive data is logged
- Logging and monitoring: whether API calls are recorded, whether network traffic is captured, and whether alerts fire when anomalous behavior occurs
- Resilience and recovery capabilities: whether backups exist and run on a schedule, whether recovery has been tested, whether RTO and RPO targets are defined and achievable
The combined state of these conditions at any given moment is what cloud security posture management is designed to assess.
Every merged PR shifts your posture
Cloud environments are not static. A production AWS account receives Terraform changes continuously, new security groups, updated IAM policies, new S3 buckets, modified instance configurations, and additional subnets. Each of those changes alters the environment’s posture.
Adding a security group rule that opens port 22 to 0.0.0.0/0 degrades posture in the access control and network exposure domains. Removing CloudWatch alarms to reduce cost degrades posture in the monitoring domain. Provisioning a new S3 bucket without encryption degrades posture in the data protection domain. Because posture is the sum of every infrastructure decision, and because infrastructure changes continuously, cloud security posture changes with every merged pull request.
What CSPM is actually solving
At its core, cloud security posture management exists to continuously answer four questions that would otherwise require manually auditing hundreds of resources:
- What assets exist, and which are publicly accessible?
- Who can access them, and with what permissions?
- Which configurations introduce risk, such as open ports, missing encryption, and disabled logging?
- Which data is at risk, and what controls protect it?
CSPM platforms answer these questions by scanning deployed infrastructure, comparing configurations against policy baselines, and surfacing deviations. Scanning deployed infrastructure catches configuration drift, a security group rule added manually through the console, an S3 bucket created outside of Terraform, and an IAM permission granted through a one-off change, which would never appear in a code review. But most CSPM discussions begin after infrastructure is already deployed, which raises an important question about when posture actually originates.
Why Post-Deployment Audits Find Problems Too Late
Cloud infrastructure in 2026 is defined as IaC(Infrastructure as Code). Terraform, CloudFormation, Pulumi, and similar frameworks describe the exact configuration of every resource before any of it reaches a cloud provider. A security group ingress rule, a KMS key rotation period, a CloudTrail configuration, and an S3 bucket encryption policy are all written as code before terraform apply runs. The posture conditions those configurations produce are fixed the moment the code is written:
- A security group with cidr_blocks = [“0.0.0.0/0”] on port 22 will expose SSH to the internet the instant it is applied
- A Terraform module with no aws_cloudtrail resource will deploy an environment with no audit logging from day one
- An S3 bucket module with no aws_s3_bucket_server_side_encryption_configuration block will store every object unencrypted
These are not future risks. They are present conditions written into infrastructure definitions, waiting for terraform apply to make them operational.
Deployment activates what the code has already decided
There is a common assumption embedded in how most teams talk about security findings: that the problem is created at the moment a CSPM scan identifies it. This assumption mislocates the origin of the risk.
Consider how this actually plays out. An engineer submits a PR that adds a new VPC module, subnets, routing tables, security groups, an EC2 instance, and an IAM role. The reviewer checks that every resource is correctly defined, dependencies are wired properly, and the architecture matches the design. Everything looks right. What nobody notices is that aws_cloudtrail is simply absent from the entire module. Not misconfigured, just never added. The PR merges. terraform apply runs. The environment deploys with no API audit trail from day one.
Days or weeks later, a CSPM scan flags it.
The finding did not originate from the scan. It originated when the code was written. The reviewer wasn’t at fault; they checked what was there. Nobody was checking for what wasn’t.
By the time a CSPM platform reports the finding, the environment has been running without an audit trail for however long elapsed between deployment and the next scheduled scan. That window is where actual risk exists. That exposure window, the time between when a misconfiguration first deploys and when an audit finds it, is exactly what the traditional compliance audit lifecycle is not designed to close.
The Compliance Audit Lifecycle Is Structurally Reactive
Platform teams discover gaps in cloud security posture through compliance audit cycles. A SOC 2 assessment, an internal security review, and a pre-certification audit, these are the moments when posture findings get formally documented and assigned for remediation. CSPM platforms feed directly into this workflow, providing the evidence and scan results that auditors and security teams work from.
That’s why understanding how the compliance audit cycle works matters here. It shapes when security teams see posture issues, how they prioritize them, and how long remediation takes. And that cycle has a structural problem.
The standard workflow for compliance-driven cloud security looks like this:
At every stage in this workflow, the audit operates on infrastructure that is already running. Security findings occur after deployment. Risks exist in a live environment. And the remediation that follows requires modifying production infrastructure rather than correcting a line of code.
This structure is not a design failure; it reflects the historical reality that cloud environments were managed manually, and auditing was the only available mechanism for visibility. But in environments where all infrastructure is defined as code before deployment, relying solely on post-deployment audits means accepting an unnecessary exposure gap.
The Same Security Group Change Costs 15 Minutes in Terraform and Five Business Days in Production
The cost difference between fixing a misconfiguration before deployment and fixing it after is not incremental. It is structural.
Before deployment, restricting an SSH rule from 0.0.0.0/0 to an internal network range is a one-line change in a .tf file, a code review comment, and a commit.
After deployment, the same change requires:
- A CSPM platform identifies the open SSH rule in production
- The security team files a finding and assigns severity
- The infrastructure team assesses which services depend on the current rule
- A change request is opened and reviewed for operational impact
- The change is scheduled for a maintenance window
- The updated Terraform is applied to production
- Connectivity is validated to confirm that no legitimate access was disrupted
- The remediation is documented as compliance evidence
Two weeks after the finding was reported, the one-line Terraform change is live in production. The same change would have taken 15 minutes before terraform apply ran.
This difference compounds across every finding in a compliance assessment. An organization that runs quarterly CSPM audits and identifies 15 high-severity findings is not managing 15 one-line Terraform changes. They are managing 15 production change requests, each with its own review cycle, maintenance window, and validation process.
Compliance Audits Answer “What Security Risks Exist,” They Cannot Answer “What Risks Are We About to Introduce.”
Compliance audits are designed to measure the security posture that currently exists in a deployed environment. That is a legitimate and necessary capability.
What they are not designed to do is evaluate the security posture that the next terraform apply is about to introduce. An engineer can write Terraform that adds three unencrypted S3 buckets, removes a security group rule that restricts internal traffic, and disables a CloudWatch alarm, and none of that will appear in any CSPM finding until the deployment runs and the next scan executes.
Compliance remains valuable. But relying on post-deployment audits as the primary mechanism for cloud security posture management means posture degradation is discovered after it is operational, not before it is introduced.
Shifting CSPM Left: From Post-Deploy to Pre-Deploy
The shift-left model does not replace post-deployment CSPM scanning. It adds an assessment step earlier in the delivery cycle, at the point where infrastructure decisions are still expressed as code and are still easy to change.
In the shift-left model, the same posture assessment that would have run against deployed infrastructure runs against the Terraform definitions before terraform apply executes. The findings are the same. The difference is that the engineer receives them while the fix is still a code change rather than a production deployment.
What shifts when you move posture assessment into the pull request
Moving cloud security posture management earlier, from post-deployment audit into the pull request review, produces several concrete improvements:
- Faster feedback loops: Engineers learn about posture weaknesses in the pull request, not in a quarterly audit report
- Lower remediation costs: Fixing a misconfiguration in Terraform takes minutes; fixing the equivalent in production takes days
- Reduced production risk: Misconfigurations that never reach production create zero exposure, regardless of their severity
- Improved developer ownership: an engineer whose security group PR was flagged for open SSH checks, ingress rules, before opening the next PR, rather than waiting for a post-deployment finding to surface the same pattern again
- Fewer compliance findings downstream: Post-deployment CSPM scans surface fewer findings because the misconfigurations that would have generated them were corrected before deployment
- Better governance: Security review becomes part of the change management process, not a separate activity that happens after changes are live
The goal is not simply achieving compliance faster. The goal is to prevent posture degradation from reaching production in the first place. To make that concrete: the following section walks through a Terraform-based AWS environment that Opsera assessed before deployment, and the 15 control gaps it found in the code.
Auditing App-Config Before Deployment With Opsera
banzo-app-config is a Terraform repository that defines an AWS environment built around a single EC2 t3.micro instance running a K3s Kubernetes cluster with Velero backups targeting an S3 bucket. The infrastructure spans 46 Terraform files within a modular structure that covers VPC, subnets, routing, security groups, IAM roles, EC2, EBS volumes, KMS keys, and S3.
The assessment objective was not SOC 2 certification. The objective was to understand what cloud security posture this infrastructure would produce if it were deployed to a production AWS account, and to identify which posture weaknesses could be corrected before that deployment ran.
Why SOC 2, and why it’s not about certification
SOC 2 was selected as the assessment framework because its Trust Service Criteria map directly to the posture domains that matter most in a cloud environment:
- Security (CC6): access controls, network exposure, incident detection
- Availability (A1): resilience, backup, disaster recovery
- Processing Integrity (PI1): backup scheduling, data recovery
- Confidentiality (C1): encryption at rest and in transit
- Privacy (P1): data classification and access controls
Using SOC 2 as the assessment framework gives each Terraform resource a concrete checklist: Does this VPC have flow logs? Does this S3 bucket have an aws_s3_bucket_server_side_encryption_configuration block? Does this IAM role have an explicit deny policy? It answers the question “what should exist in this infrastructure?” systematically, rather than relying on an ad hoc security review.
How Opsera read 46 files without a running environment
The Opsera compliance audit agent analyzed the Terraform definitions across the repository, reading security group ingress rules, checking for the presence of CloudTrail and VPC Flow Log resources, examining S3 bucket configurations, reviewing IAM trust policies, and cross-referencing the EC2 user_data script against what the provisioned S3 bucket was supposed to contain. No AWS environment was running. No resources were deployed. The entire assessment ran against code. Now, based on the snapshot below:
The output was a structured gap analysis, each failing control mapped to the specific Terraform file and line where the gap originated, with code-level remediation guidance for each finding.
What the Audit Found
The assessment returned a 12% compliance score against 64 evaluated SOC 2 controls. 54 controls were missing entirely. 8 findings were rated critical. 7 were rated high.
Every finding existed in the Terraform code.
1. SSH on Port 22 Accepted Connections From Every IP Address on the Internet
modules/aws_security_group/main.tf, lines 26–34, defined an ingress rule for port 22 with cidr_blocks = [“0.0.0.0/0”]. The EC2 instance running K3s had a public IP address, and this security group was attached.
Any machine on the internet could attempt an SSH connection to this instance. Automated scanners that continuously probe public IP ranges for open port 22 would have discovered it within hours of deployment. No vulnerability needed to be exploited — the port was open by design, and the finding mapped directly to CC6.1 (Logical Access Controls).
2. The Entire Infrastructure Stack Had No CloudTrail Resource Across 87 Lines of Root Terraform
The root main.tf file, 87 lines that orchestrated the deployment of the VPC, subnets, EC2 instance, IAM roles, KMS key, and S3 bucket, contained no aws_cloudtrail resource and no reference to one. None of the 46 Terraform files across the repository contained one.
SOC 2 Type II requires 12 months of API call logs to demonstrate who accessed which resources, when, and from which IP addresses. An auditor requesting this evidence would receive nothing. Every IAM assume-role event, every S3 write, every EC2 API call would have happened with no record.
3. VPC Flow Logs Were Absent, Leaving Network-Level Incidents With No Investigation Path
modules/aws_vpc/main.tf defined the VPC with no aws_flow_log resource. Inbound and outbound traffic to the EC2 instance and every Kubernetes workload running on it would produce no logs. If an attacker exfiltrated data after gaining access, there would be no network record of the connections, destination IPs, or the volume of data transferred.
4. Velero Was Installed But Never Scheduled. Backups Were Not Running Despite the Infrastructure Existing
This is the finding that post-deployment CSPM scanning is least equipped to catch. The EC2 user_data script installed the Velero CLI. The IAM instance profile gave Velero the permissions it needed. The S3 bucket db-lg-001 existed as the backup target. From a surface-level CSPM scan perspective, the backup infrastructure looks correct, Velero is present, the bucket exists, and the IAM role has the right permissions.
What was missing was a Velero Schedule resource, the Kubernetes CRD that actually tells Velero to run a backup on a defined interval. Without it, Velero sits idle. No backup ever runs. If the EC2 instance failed after deployment, the recovery time would be measured in days, and the data loss window would be however long the instance had been running.
This gap only becomes visible when you read the Terraform and the user_data together and ask: Does the configuration actually produce the intended behavior? Opsera caught it at code review. A post-deployment CSPM scan would have passed it.
5. The S3 Backup Bucket Stored Its Contents Without Encryption, while the EBS Volumes Used KMS
modules/aws_s3_bucket/main.tf defined the db-lg-001 bucket with no aws_s3_bucket_server_side_encryption_configuration block. The EBS root volume was KMS-encrypted. The attached EBS data volume was KMS-encrypted. The KMS key had automatic rotation configured. And the S3 bucket that received all Kubernetes state and application data backups was unencrypted.
The inconsistency was present in the code and invisible to anyone who reviewed each module in isolation.
5 Findings: Each degrades a Different Cloud Security Posture Domain
Each finding maps to a specific posture domain rather than being a standalone misconfiguration:
| Finding | Posture Domain Affected |
| SSH open to 0.0.0.0/0 | Attack surface, network exposure |
| No CloudTrail | Visibility and accountability, API audit trail |
| No VPC Flow Logs | Monitoring and detection, network visibility |
| Velero installed, no schedule | Resilience, backup execution |
| S3 backup bucket unencrypted | Data protection, confidentiality of backups |
Taken together, these findings describe an infrastructure with a large external attack surface, no logging to detect an attack in progress or investigate one after the fact, and no tested recovery path if the primary instance fails.
Four Changes That Fixed the Gaps Before Deployment
Once the assessment surfaced these findings, four targeted Terraform changes as suggested in the remediation roadmap were committed to a new branch before any deployment ran.
- Restricting SSH to internal network ranges (15 minutes): In modules/aws_security_group/main.tf, the SSH ingress rule changed from cidr_blocks = [“0.0.0.0/0”] to cidr_blocks = [“10.0.0.0/8”]. The EC2 instance is no longer reachable on port 22 from the public internet. Legitimate SSH access now requires an internal network connection.
- Enabling CloudTrail with encrypted log storage (60 minutes): A new file, cloudtrail.tf, defined an S3 log bucket (with encryption, versioning, and a policy that only allows CloudTrail to write) and an aws_cloudtrail resource set to multi-region with log file validation enabled. Every AWS API call in the account will produce a log entry. The 12-month evidence window required for SOC 2 Type II starts from the first deployment, not from the date someone noticed it was missing.
- Enabling VPC Flow Logs with 90-day CloudWatch retention (45 minutes): A new file, vpc-flow-logs.tf, created a CloudWatch log group, an IAM role for the VPC Flow Logs service, and an aws_flow_log resource capturing all traffic on the VPC. Network-level incidents can now be investigated. Anomalous outbound connections to unfamiliar IPs appear in CloudWatch within minutes of occurring.
- Encrypting the backup S3 bucket with KMS, adding versioning, and enabling access logging (15 minutes): A new file, s3-encryption.tf, added aws_s3_bucket_server_side_encryption_configuration using the existing KMS key, enabled versioning so accidental deletion is recoverable without data loss, and created a separate logging bucket to record every s3:GetObject and s3:PutObject on the backup bucket.
The Compliance Score Moved From 12% to 30%, and Four Attack Vectors Were Closed Before the Deployment Ran
The total commit contained 956 insertions across 5 changed files, opened as pull request #2 on the repository. The security posture before and after those changes looks like this:
| Posture Dimension | Before | After |
| Attack surface | SSH is open to the internet | SSH is restricted to the internal network |
| Visibility and accountability | Zero API audit logs | 12-month CloudTrail from day one |
| Monitoring and detection | No network logging | VPC Flow Logs with 90-day retention |
| Data protection | Plaintext backup storage | KMS-encrypted with versioning and access logging |
| Overall SOC 2 score | 12% | ~30% |
Security posture improved before a single AWS resource was deployed. The CloudTrail logs that a SOC 2 Type II auditor would request exist from the first API call, not from the date a post-deployment CSPM scan identified the gap. The S3 bucket was never unencrypted from an operational standpoint; by the time it stored its first object, encryption was already in place. This assessment, 15 gaps found in Terraform, four resolved before deployment, zero production exposure created, illustrates the operational difference between detecting misconfigurations in a running environment and preventing them from reaching one.
The Future of CSPM Is Preventive, Not Reactive
Cloud Security Posture Management Is Moving From Detect-After-Deployment to Prevent-Before-Deployment. The traditional CSPM model operates on a detect-and-remediate loop:
Traditional: Deploy-> Detect-> Remediate
The emerging model introduces an assessment phase before deployment that prevents misconfigurations from reaching production:
Emerging: Assess->Fix->Deploy->Detect (for drift)
In the emerging model, post-deployment CSPM scanning still runs, but it catches configuration drift and manual changes made outside of Terraform, not the foundational misconfigurations that were written into IaC from the start. The volume of post-deployment findings decreases because the deployed infrastructure has already been assessed.
Where Opsera fits in this workflow
Opsera’s position in this model is not as an alternative to CSPM scanning. It is an earlier evaluation layer that reads the infrastructure before it runs.
By analyzing Terraform definitions against compliance control frameworks, such as SOC 2, HIPAA, PCI DSS, and ISO 27001, Opsera answers the question “What security posture will this infrastructure produce?” before the infrastructure exists. Engineers receive findings during pull request review; at the same time, they receive linting errors and test failures. The security feedback is part of the development workflow rather than a downstream audit that arrives weeks after the code ships.
This also means that posture improvements reach production through a controlled change process, a PR, a code review, and a commit, rather than through a production remediation cycle triggered by a compliance finding.
Conclusion
Cloud security posture does not begin when infrastructure is deployed to the cloud. It begins when infrastructure decisions are made. The open SSH rule in modules/aws_security_group/main.tf was a posture weakness at the moment it was written. The absence of CloudTrail in main.tf was a compliance gap before the file was ever reviewed. The missing Velero schedule was a recovery failure waiting to happen from the day the user_data script was committed.
By the time a CSPM platform identifies a misconfiguration in a running production environment, posture degradation has already occurred. The exposure window is open. The audit trail gap has already accumulated. The backup that was supposed to run has not run.
The next evolution of cloud security posture management is not faster detection after deployment. It is preventing posture degradation before deployment ever occurs, by moving assessment to the point where infrastructure decisions are still expressed as code, still easy to change, and still free of the operational complexity that makes production remediation expensive.