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:
## 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:
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
- 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
- name: Run tfsec
uses: aquasecurity/tfsec-sarif-action@v0.1.4
with:
sarif_file: tfsec.sarif
minimum_severity: HIGH
additional_args: --exclude-downloaded-modules
- name: Upload tfsec SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: tfsec.sarif
category: tfsec
- name: Run Checkov on changed directories
id: checkov
run: |
pip install checkov==3.2.0 --quiet
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
- 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:
terraform.tfvars
*.auto.tfvars
*.tfvars.json
backend.tf
backend.hcl
secrets.tf
credentials.tf
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 {
required_version = ">= 1.5.0, < 2.0.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.40"
}
kubernetes = {
source = "hashicorp/kubernetes"
version = "~> 2.30"
}
}
}
locals {
allow_destroy = terraform.workspace == "staging" ? true : false
}
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
publicly_accessible = false
deletion_protection = !local.allow_destroy
storage_encrypted = true
kms_key_id = var.kms_key_arn
lifecycle {
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.