Stopping Cloud Waste and Security Leaks at the Pull Request

The Cost of 'Deploy Now, Fix Later'

Infrastructure-as-Code (IaC) has streamlined how we deploy cloud environments, but it has also made it easier to replicate mistakes at scale. A single missing line in a Terraform module can leave an S3 bucket public or create a load balancer that stays idle for months. Traditionally, these issues are found during quarterly security audits or when the monthly cloud bill arrives—long after the code has been merged and deployed.

The goal is to move these checks from the post-deployment phase to the pull request (PR) phase. By integrating static analysis into the CI pipeline, you can treat infrastructure misconfigurations as build errors rather than operational incidents.

Automating the Infrastructure Review

Codeac functions as an automated reviewer for IaC files (such as Terraform, CloudFormation, and Kubernetes manifests). Instead of relying on a human reviewer to remember every security best practice, the platform scans the diff of a PR and leaves inline comments where violations occur.

This shift changes the developer experience. Rather than receiving a ticket from the security team three weeks after a deployment, the developer sees a warning in their PR immediately. This creates a tight feedback loop where the fix happens while the context of the change is still fresh.

Connecting Static Analysis to Real-World Cost

While most scanners look only at the code (static analysis), a critical engineering challenge is identifying orphaned resources—infrastructure that is technically "correct" in the code but unused in the actual cloud environment. This is where the distinction between a simple linter and a cloud-aware platform becomes apparent.

By connecting to a cloud account via read-only credentials, Codeac can cross-reference the deployed state with actual usage. It flags resources like unattached EBS volumes, stale snapshots, or unassociated elastic IPs. This transforms the tool from a security scanner into a cost-optimization engine, surfacing estimated monthly savings directly to the engineering team.

Worked Example: Securing an S3 Bucket

Consider a common scenario where a developer adds a new S3 bucket for application logs but forgets to enforce encryption and public access blocks.

The Vulnerable Configuration

resource "aws_s3_bucket" "app_logs" {
  bucket = "company-app-logs-prod"
  # Missing: aws_s3_bucket_public_access_block
  # Missing: aws_s3_bucket_server_side_encryption_configuration
}

The PR Workflow

1. Push: The developer pushes this code to a feature branch and opens a PR.
2. Scan: Codeac triggers a scan of the Terraform files.
3. Feedback: An inline comment appears on the aws_s3_bucket resource, noting that the bucket lacks a public access block and encryption.
4. Remediation: The developer adds the following blocks to the configuration:

   resource "aws_s3_bucket_public_access_block" "app_logs_block" {
     bucket = aws_s3_bucket.app_logs.id
   
     block_public_acls       = true
     block_public_policy     = true
     ignore_public_acls      = true
     restrict_public_buckets = true
   }

5. Verification: On the next push, the scan clears, and the PR status check turns green.

The Engineering Trade-off: Noise vs. Visibility

Implementing a gating mechanism for infrastructure carries a specific risk: pipeline friction. If you enable every single rule on day one, a legacy repository will likely trigger hundreds of violations, effectively blocking all new work.

The practical engineering decision here is to gate only new findings. By establishing a baseline of existing technical debt, you can ensure that the pipeline only fails if a PR introduces a new security risk or cost inefficiency. This allows the team to maintain velocity while preventing the environment from degrading further.

Additionally, cloud-side resource detection can be noisy. Resources created manually for emergency debugging or shared across teams may be flagged as "unused." To manage this, teams must implement a triage process to ignore specific resource IDs that are intentionally idle.

Verification and Implementation

To verify the effectiveness of this setup, perform a "canary test":

• Create a test branch in a non-production repository.
• Introduce a known misconfiguration (e.g., an open SSH port 22 in a security group).
• Confirm that the PR status check fails and the inline comment points to the exact line of code.
• Verify that the failure is blocked at the VCS level (GitHub/GitLab) to prevent merging.