Originally published on kuryzhev.cloud

---

Copilot just autocompleted your security group with port 0–65535 open to the world — and terraform validate said it was fine. That's the GitHub Copilot Terraform security problem in one sentence: the suggestions are syntactically valid, pass every local check, and still destroy your security posture on first apply. We've seen it happen across three separate teams in the last six months, and the pattern is always the same: nobody noticed until a compliance scan flagged it post-deploy.

Symptoms

The signs aren't loud. That's what makes this dangerous. Here's what we actually observed before we locked things down.

Security group rules open to the world. Copilot autocompletes resource "aws_security_group" blocks with ingress { from_port = 0, to_port = 0, cidr_blocks = ["0.0.0.0/0"] }. It's valid HCL. It passes terraform validate. The first terraform plan shows a clean diff. Then on the second apply — after your existing state has been modified — you get a conflict you can't easily roll back.

RDS instances with public access enabled. In roughly 60% of completions observed in public issue trackers, Copilot sets publicly_accessible = true on aws_db_instance resources. It also defaults deletion_protection = false on RDS clusters, Cloud SQL instances, and Azure PostgreSQL servers. Both values look like reasonable defaults to someone new to the codebase.

Kubernetes manifests with security context stripped. The Helm/Kubernetes variant is equally quiet. Copilot suggests hostNetwork: true as a quick fix for DNS resolution issues inside pods — which bypasses network policy entirely. It drops readOnlyRootFilesystem from securityContext blocks without any warning. The manifest applies cleanly. The container runs. The risk is invisible until someone audits it.

Hallucinated module references. Copilot has zero visibility into your .tfstate. It generates references like module.vpc.private_subnet_ids that don't exist in your actual module structure. The error only surfaces at plan time: Error: Reference to undeclared module — A managed resource "module.vpc" has not been declared in the root module. By then the suggestion has already been committed.

Watch out for: lifecycle { ignore_changes = all } appearing in Copilot suggestions as a way to "silence drift warnings." This is a correctness trap. It masks real infrastructure divergence and should be treated as a blocking finding, not a style preference.

Root Cause: Why Copilot Gets IaC Wrong

Stop blaming yourself or your team. There are three structural reasons Copilot underperforms specifically on infrastructure code compared to application code.

Root cause #1: Training data skew. Public Terraform repos over-represent quick demos, blog posts, and tutorials that intentionally skip security hardening to keep examples short. Copilot's probability distribution has learned from that corpus. It favors insecure defaults — deletion_protection = false, publicly_accessible = true, acl = "public-read" — because those values appear constantly in "getting started" content. Checkov check CKV_AWS_57 exists specifically because S3 buckets with public ACLs are that common in training data.

Root cause #2: No state awareness. Copilot has no access to your .tfstate, your module outputs, your workspace variables, or your backend configuration. It generates module references and resource outputs based on pattern matching against what it has seen in public repos. When your module structure doesn't match that pattern, the suggestion compiles but fails at plan or apply time. There's no feedback loop.

Root cause #3: Context window truncation. In files over roughly 300 lines, Copilot loses the top-of-file provider block and required_providers version constraints. It starts generating syntax valid for Terraform 0.12 or 0.13 — ${var.name} interpolation where it's unnecessary, list() and map() type constructors that were deprecated in 0.14 — inside a codebase running Terraform 1.7.x. The code applies, but it's semantically wrong and will cause issues when you upgrade.

One more gotcha worth calling out separately: Copilot Chat in VS Code reads all open editor tabs as context. If you have prod.tfvars open while asking Copilot to "generate a similar staging config," it will echo production account IDs, bucket names, and state key paths back into the generated output. Every repo contributor with Copilot access can see those values in the suggestion. This is a lateral information exposure risk in multi-team organizations, and most engineers don't know it's happening.

Fix #1 — Add a .github/copilot-instructions.md Guardrail File

The fastest single-file intervention. No CI changes required. Supported in GitHub Copilot for Business and Enterprise (not available in individual Free/Pro plans as of Q1 2025). This file instructs Copilot to follow repo-specific rules during both inline completions and Copilot Chat sessions.

Create the file at exactly this path — .github/copilot-instructions.md — and include directives like these:

# Copilot Instructions — IaC Repository

## Security Rules (apply to all Terraform and Kubernetes suggestions)

- Never suggest `0.0.0.0/0` in security group ingress or egress rules
- Always include `lifecycle { prevent_destroy = true }` on stateful resources
  (aws_db_instance, aws_s3_bucket, aws_elasticache_cluster, aws_rds_cluster)
- Default encryption to `true` for all storage resources
- Set `publicly_accessible = false` on all database resources
- Set `deletion_protection = true` on all database and cache resources
- Never suggest `lifecycle { ignore_changes = all }` — this masks drift
- Pin all provider versions using the `~>` pessimistic constraint operator
- Never suggest `hostNetwork: true` in Kubernetes or Helm manifests
- Always include `readOnlyRootFilesystem: true` in container securityContext

## Terraform Version
- Target Terraform >= 1.5.0. Do not generate 0.12-era interpolation syntax.
- Use `for_each` with conditional sets instead of `count` for feature toggles.

## Provider Versions
- aws: ~> 5.40
- kubernetes: ~> 2.30
- helm: ~> 2.13

Watch out for: this file is advisory, not enforced. Copilot may still violate these rules under high-ambiguity completions or when the file isn't fully loaded in context. Treat it as signal reduction — it meaningfully reduces bad suggestions, but it is not a hard block. You still need the CI layer in Fix #2.

Fix #2 — Block Dangerous Patterns in CI with tfsec and Checkov

This is the enforcement layer. What the instructions file misses, the pipeline catches. We run both tfsec and Checkov as a single required status check on every PR that touches *.tf or *.tfvars files. Both tools must pass before merge is allowed — not advisory, not continue-on-error: true.

The most common mistake I see: teams install tfsec and Checkov, set continue-on-error: true to avoid blocking the team during rollout, and then never flip the flag. Findings accumulate. Nobody resolves them. The tools become theater. Make the check required in branch protection rules from day one, even if you start with a narrow check list.

Note on tooling: tfsec version 1.28.x is the last stable OSS release before Aqua Security shifted focus to trivy for IaC scanning. The forward-compatible replacement is trivy config . — worth planning the migration now. We're still on tfsec in older pipelines but all new repos use trivy.

Here's the full workflow. It scopes Checkov to only changed Terraform directories using git diff output, which cuts scan runtime from 4–6 minutes on large monorepos down to under 45 seconds. It also uploads tfsec findings to the GitHub Security tab via SARIF — but note that SARIF upload via github/codeql-action/upload-sarif@v3 requires GitHub Advanced Security enabled on the repo:

# .github/workflows/iac-copilot-guardrails.yml
# Blocks dangerous Copilot-generated IaC patterns on every PR
# Requires: GitHub Actions, tfsec 1.28.x, checkov >= 2.3.0

name: IaC Security Scan

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.tfvars'
      - '**/Chart.yaml'
      - '**/values.yaml'

permissions:
  contents: read
  security-events: write   # required for SARIF upload to GitHub Security tab
  pull-requests: write     # required for inline PR annotations

jobs:
  security-scan:
    name: Scan Copilot-Generated IaC
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # Identify only changed Terraform directories to keep scan fast
      - name: Get changed TF directories
        id: changed
        run: |
          git fetch origin ${{ github.base_ref }} --depth=1
          CHANGED_DIRS=$(git diff --name-only origin/${{ github.base_ref }}...HEAD \
            | grep '\.tf$' \
            | xargs -I{} dirname {} \
            | sort -u \
            | tr '\n' ',')
          echo "dirs=${CHANGED_DIRS}" >> $GITHUB_OUTPUT

      # tfsec: catches HIGH/CRITICAL misconfigs, outputs SARIF for Security tab
      - name: Run tfsec
        uses: aquasecurity/tfsec-sarif-action@v0.1.4
        with:
          sarif_file: tfsec.sarif
          minimum_severity: HIGH
          # Exclude downloaded provider modules — only scan authored code
          additional_args: --exclude-downloaded-modules

      - name: Upload tfsec SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: tfsec.sarif
          category: tfsec

      # Checkov: policy-as-code checks, blocks PR if any HIGH finding
      - name: Run Checkov on changed directories
        id: checkov
        run: |
          pip install checkov==3.2.0 --quiet

          # Build --directory flags from changed dirs output
          DIRS="${{ steps.changed.outputs.dirs }}"
          DIR_FLAGS=$(echo "$DIRS" | tr ',' '\n' | sed 's/^/--directory /' | tr '\n' ' ')

          checkov \
            $DIR_FLAGS \
            --framework terraform \
            --check CKV_AWS_8,CKV_AWS_24,CKV_AWS_57,CKV_AWS_135,CKV_K8S_30 \
            --compact \
            --output cli \
            --output-file-path console \
            --hard-fail-on HIGH  # PR fails on HIGH severity — not advisory
        continue-on-error: false   # INTENTIONAL: must be false to block merge

      # Annotate PR with Checkov findings as inline comments
      - name: Post Checkov summary to PR
        if: failure()
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '❌ **IaC Security Scan failed.** Checkov found HIGH severity issues in Copilot-generated Terraform. Review the Security tab for details before merging.'
            })

One cost note: running Checkov and tfsec as separate parallel jobs doubles your CI minute consumption. Keep them in a single security-scan job running sequentially. On GitHub Actions free tier (2,000 min/month), this matters for active teams.

Fix #3 — Scope Copilot Access with .copilotignore and Content Exclusions

This is the hardest fix to get teams to adopt, and also the most important one for production environments. The goal is to surgically remove your highest-risk files from Copilot's context window so it cannot read sensitive infrastructure definitions or echo them back in suggestions.

Create a .copilotignore file at the repo root. Syntax mirrors .gitignore. This prevents Copilot from indexing matched files as context for suggestions. At minimum, include these patterns:

# .copilotignore
# Prevents Copilot from using these files as suggestion context

# Variable files with real values — account IDs, bucket names, ARNs
terraform.tfvars
*.auto.tfvars
*.tfvars.json

# Backend config — contains real S3 bucket names and state key paths
backend.tf
backend.hcl

# Files that may contain sensitive resource definitions
secrets.tf
credentials.tf

# Production environment configs — exclude entirely
envs/prod/**
environments/production/**

For GitHub Copilot Enterprise, go further. Configure Content Exclusions at the organization level under Settings → Copilot → Content exclusion. Use glob patterns like **/prod/**/*.tf to exclude all production Terraform from Copilot context across every repo in the org. Organization-level exclusions override repo-level .copilotignore — org settings win. This is the hard block. The .copilotignore is a soft hint; Content Exclusions are enforced by the platform.

The concrete risk without this: Copilot Chat reads all open editor tabs. Open backend.tf in VS Code, ask Copilot to "generate a staging backend config," and it will echo your production S3 bucket name and state key path directly into the suggestion. Any repo contributor with Copilot access sees that output. In a multi-team org with shared repos, that's a real lateral information exposure path.

Also worth enabling: Copilot audit logs in GitHub Enterprise org settings. Suggestions are not logged by default at the repo level. Turning on audit logs lets you track which suggestions were accepted in IaC files — useful for compliance and incident investigation.

Prevention — Build a Copilot-Aware IaC Module Template

Fixes #1–3 are reactive. This one is proactive. The goal is to make the secure path the default path — so engineers never start from a blank, unconstrained Terraform file where Copilot's bad defaults have nothing to override them.

Create a terraform-module-template repository using GitHub's template repository feature. Every new module repo gets created from this template and inherits the full guardrail stack on day one. The template should include a pre-populated versions.tf with pinned providers, a variables.tf with typed and validated inputs, and a .github/copilot-instructions.md already in place.

The versions.tf file does double duty: it constrains Copilot's context (when the file is open, Copilot inherits the version and provider patterns) and it prevents the context-window-truncation problem by keeping version constraints at the top of every module. Here's what that baseline file looks like, with the RDS resource showing all Copilot-common insecure defaults explicitly overridden:

# terraform-module-template/versions.tf
# Drop this file into every new module repo via GitHub template repository

terraform {
  # Prevents Copilot from generating 0.12-era syntax
  required_version = ">= 1.5.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      # Pessimistic constraint — Copilot defaults to unpinned or too-broad ranges
      # Pin minor version to prevent breaking changes from auto-accepted suggestions
      version = "~> 5.40"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.30"
    }
  }
}

# Local that makes destruction intent explicit and auditable
locals {
  # Only staging workspaces allow destroy — production is always protected
  # Copilot will inherit this pattern from context if file is open in editor
  allow_destroy = terraform.workspace == "staging" ? true : false
}

# Example: RDS instance with all Copilot-common insecure defaults overridden
resource "aws_db_instance" "main" {
  identifier        = "${var.env}-${var.app_name}-db"
  engine            = "postgres"
  engine_version    = "16.2"
  instance_class    = var.db_instance_class
  allocated_storage = var.db_storage_gb

  # Copilot default = true — always override explicitly
  publicly_accessible = false

  # Copilot default = false — always override explicitly
  deletion_protection = !local.allow_destroy

  # Copilot frequently omits this block entirely
  storage_encrypted = true
  kms_key_id        = var.kms_key_arn

  lifecycle {
    # Do NOT use ignore_changes = all — that masks drift
    # Only ignore tags to prevent plan noise from tagging automation
    ignore_changes = [tags]
  }
}

Add a pre-commit configuration to the template as well. Using pre-commit framework v3.x with hooks terraform_tfsec, terraform_checkov, terraform_validate, and terraform_fmt catches issues before they ever reach CI. The most common failure mode: terraform_checkov requires checkov >= 2.3.0 and Python >= 3.8 in the local environment. Version mismatch is the number one cause of "hook failed to install" errors on new developer machines. Pin both in your onboarding docs.

One final thing I want to flag: the count = var.enable_feature ? 1 : 0 pattern. Copilot loves suggesting this for optional resources. In Terraform versions below 1.3, toggling this value causes resource replacement — a destroy followed by a create — not an update. We had a Redis cluster get destroyed in staging because of this. Use for_each with a conditional set instead. It's a one-line change and it avoids the replacement behavior entirely. See the Terraform count meta-argument docs for the full explanation of why this happens.

GitHub Copilot Terraform security isn't about disabling the tool — it's about building a system where the tool's suggestions land inside guardrails rather than outside them. The copilot-instructions.md file reduces noise. The CI pipeline enforces policy. The content exclusions protect sensitive context. The module template makes the secure path the default. Stack all four layers and Copilot becomes genuinely useful for IaC work instead of a liability. For more on enforcing infrastructure policy in CI pipelines, see the DevOps_DayS runbook archive for related patterns across AWS and Kubernetes environments.

Related

• More Terraform security patterns, module design, and state management fixes
• CI/CD pipeline hardening: gates, scans, and policy enforcement in GitHub Actions
• Infrastructure security automation: secret scanning, CVE gates, and compliance checks