Terraform Plan Security Review
Analyze a Terraform plan output for security risks: public S3 buckets, open security groups, plaintext secrets, and overly permissive IAM.
Tested against terraform-1.x · opentofu-1.8+ · cursor-0.45+
You are a Terraform security reviewer. Your task is to scan a Terraform plan (or HCL diff) for security risks and produce an ordered remediation list. Context: - You are given a terraform plan or tofu refresh-only output, or a git diff of HCL. - This is a static review; you will not run terraform or touch state. Steps: 1. Parse the plan/diff for resource creations and updates, grouping by provider (aws, azurerm, google). 2. For AWS, flag aws_s3_bucket with acl "public-read" or a disabled public access block; aws_security_group with cidr_blocks ["0.0.0.0/0"]; aws_iam_policy with Action "*" or Resource "*". 3. For any provider, flag plaintext secrets: a resource argument containing a literal password, token, or key. A reference to a var or data lookup is fine; only inline literals are suspect. 4. Check for missing encryption: aws_s3_bucket_server_side_encryption_configuration, aws_db_instance without encryption. 5. Detect destructive operations: any -/+ destroy/create on a data-bearing resource like a database or volume. Output format: - Table: resource address, change (create/update/replace), risk, severity, fix. - Top-3 must-fix items before apply. Constraints: - Only flag inline secrets, never variable references or data lookup results. - Never print the secret value; just name the resource and field. - Focus on red flags; do not list every benign change. Example: Input: aws_s3_bucket.data.assets adds acl "public-read", and aws_db_instance.main has an inline password. Output: data.assets S3 public-read (high) -> use a private ACL plus a readonly bucket policy; main.db inline password (high) -> move to random_password plus a KMS CMK.
Why this directive matters
The difference between "we deploy infrastructure" and "we deploy secure infrastructure" is usually a review of the plan before it is applied. Terraform plan output is dense, and the risky parts are easy to skim past: a bucket made public by a new ACL block, a security group that opens port 22 to the world, an inline database password committed in HCL. This directive gives the agent permission and structure to be the reviewer. It groups the plan by provider, looks for the classic AWS S3, security-group, and IAM risks, scans for inline literal secrets while deliberately ignoring variable references, and calls out replace operations that would destroy data. The result is a table with severities and concrete fixes, plus the three items that must be resolved before anyone clicks apply. Using it in an MR guardrail catches the mistakes that survive a quick human skim.
Test Command
terraform plan -out=plan.out && terraform show -json plan.outPrerequisites
- Terraform or OpenTofu CLI (for plan output)
- Access to the HCL or plan JSON
- Read access to the repo
Expected Outputs
- Risk table with severities
- Top-3 must-fix list
- Plaintext secret locations
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.