# Fix GitHub Copilot Terraform Security Risks Before They Hit Prod > Source: > Published: 2026-06-27 07:02:52+00:00 *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. 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. 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. `.github/copilot-instructions.md` Guardrail FileThe 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. 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. `.copilotignore` and Content ExclusionsThis 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. 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](https://pre-commit.com/) 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](https://developer.hashicorp.com/terraform/language/meta-arguments/count) 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](https://kuryzhev.cloud/) for related patterns across AWS and Kubernetes environments.