Terraform Production Engineering

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:40 PM UTC
• Version: 1.0.0

Overview

This Terraform skill is legitimate in purpose, but its copy-ready production CI/CD examples include unsafe defaults that could weaken cloud deployment controls.

Install only if you want Terraform/IaC guidance, and review the CI/CD snippets before use. Pin GitHub Actions to reviewed commit SHAs, scope OIDC and AWS roles per job and environment, make security scans blocking where appropriate, fix drift detection with pipefail or PIPESTATUS, and require explicit human approval and backups before production applies or state migrations.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:438
• Finding: Privileged CI/CD Workflows Use Mutable Third-Party Action References<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 438-499 and 612-617 **Vulnerability Type**: Supply-chain risk caused by mutable GitHub Actions references **Risk Level**: Medium ### Vulnerable Code ```yaml permissions: id-token: write # OIDC contents: read pull-requests: write # PR comments ``` ```yaml steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 ``` ```yaml steps: - uses: actions/checkout@v4 - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::role/terraform-ci aws-region: us-east-1 - uses: hashicorp/setup-terraform@v3 - working-directory: infrastructure/environments/${{ matrix.environment }} run: | terraform init terraform plan -out=tfplan -no-color - uses: actions/upload-artifact@v4 with: name: tfplan-${{ matrix.environment }} path: infrastructure/environments/${{ matrix.environment }}/tfplan ``` ```yaml steps: - uses: actions/checkout@v4 - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::role/terraform-ci aws-region: us-east-1 - uses: hashicorp/setup-terraform@v3 - uses: actions/download-artifact@v4 with: name: tfplan-${{ matrix.environment }} path: infrastructure/environments/${{ matrix.environment }} - working-directory: infrastructure/environments/${{ matrix.environment }} run: terraform apply tfplan ``` The drift-detection example repeats the same pattern: ```yaml steps: - uses: actions/checkout@v4 - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::role/terraform-ci aws-region: us-east-1 - uses: hashicorp/setup-terraform@v3 ``` ### Technical Analysis The workflow references third-party GitHub Actions through major-version tags such as `@v3` and `@v4`. These tags are mutable references rather than immutable commit identifiers. If an action repository or its releas ...[truncated 2352 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every GitHub Action to a reviewed, full commit SHA: ```yaml - uses: actions/checkout@<full-reviewed-commit-sha> # v4.x.x - uses: aws-actions/configure-aws-credentials@<full-reviewed-commit-sha> # v4.x.x - uses: hashicorp/setup-terraform@<full-reviewed-commit-sha> # v3.x.x ``` 2. Use Dependabot or Renovate to propose reviewed SHA updates while retaining an adjacent release-version comment for readability. 3. Move permissions from workflow scope to individual jobs. Only jobs that actually authenticate to AWS should receive `id-token: write`. 4. Remove `pull-requests: write` from jobs that do not post pull-request comments. 5. Use distinct least-privilege IAM roles for planning, drift detection, and applying changes. The plan and drift roles should be read-only wherever possible. 6. Use separate roles and approval environments for development, staging, and production. 7. Ensure production environment protection requires authorized reviewers and prevents untrusted branches from invoking the production role. 8. Consider artifact attestations, strict artifact retention, and verification controls before applying a downloaded Terraform plan. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: SKILL.md:455
• Finding: Terraform Security Findings Are Configured as Non-Blocking<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 455 **Vulnerability Type**: Security control bypass through fail-open scanner configuration **Risk Level**: Low ### Vulnerable Code ```yaml - run: tfsec . --soft-fail ``` ### Technical Analysis The `--soft-fail` option causes `tfsec` to report security findings without returning a failing status that blocks the workflow. As a result, infrastructure code containing findings identified by the scanner can still pass the validation job and proceed to planning or deployment. This configuration contradicts the Skill's production-security guidance because the scanner is presented as a security gate while operating only as an informational control. The problem is more significant when reviewers assume that a successful validation job means no actionable security findings were detected. ### Attack Path 1. A contributor introduces an insecure Terraform configuration, such as public ingress, missing encryption, or an overly permissive IAM policy. 2. `tfsec` detects the violation during the validation job. 3. Because `--soft-fail` is enabled, the command returns a successful workflow status. 4. The plan job remains eligible to run. 5. If review and approval controls do not independently identify the issue, the insecure infrastructure change can reach the apply stage. ### Impact Assessment This issue does not directly grant privileges by itself. It weakens a preventive security control and can permit other infrastructure vulnerabilities to reach deployment. The resulting scope depends on the Terraform change that bypasses the gate. Possible downstream consequences include public exposure of cloud services, excessive IAM permissions, disabled encryption, insufficient logging, or weak network controls. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `--soft-fail` so actionable findings fail the validation job: ```yaml - run: tfsec . ``` 2. Define an explicit severity threshold appropriate for production deployment. 3. Require suppressions to include a documented justification, owner, expiration date, and review approval. 4. Upload scanner output in SARIF format so findings appear in repository code-scanning results. 5. Combine `tfsec` with Terraform validation, policy-as-code enforcement, and plan review rather than treating any single scanner as a complete security boundary. 6. Prevent apply jobs from running unless all required security checks have passed. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:620
• Finding: Drift Detection Pipeline Captures the Wrong Command Exit Status<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 620-625 **Vulnerability Type**: Fail-open drift monitoring caused by incorrect pipeline status handling **Risk Level**: Medium ### Vulnerable Code ```bash terraform init terraform plan -detailed-exitcode -no-color 2>&1 | tee plan.txt EXIT_CODE=$? if [ $EXIT_CODE -eq 2 ]; then echo "::warning::Drift detected in ${{ matrix.environment }}" # Send Slack alert fi ``` ### Technical Analysis In a shell pipeline, `$?` normally contains the exit status of the final pipeline command. Here, the final command is `tee`, not `terraform plan`. Terraform's `-detailed-exitcode` behavior is: - `0`: The plan succeeded and no differences were found. - `1`: Terraform encountered an error. - `2`: The plan succeeded and differences were found. If Terraform returns `2` for detected drift while `tee` successfully writes `plan.txt`, `$?` will normally be `0`. The condition therefore does not execute and no drift warning is emitted. A Terraform failure can similarly be masked when `tee` succeeds. The workflow does not enable `pipefail` and does not read Terraform's pipeline-specific exit status, making the scheduled security control ineffective under normal successful `tee` execution. ### Attack Path 1. A user, compromised cloud credential, or cloud-side automation modifies a managed resource outside Terraform. 2. The scheduled drift workflow runs `terraform plan -detailed-exitcode`. 3. Terraform identifies the difference and exits with status `2`. 4. Output is piped to `tee`, which successfully writes `plan.txt` and exits with status `0`. 5. `EXIT_CODE=$?` records `0` rather than Terraform's `2`. 6. The warning condition is skipped, and the unauthorized or accidental change remains unreported by this workflow. An operational error follows a similar path: Terraform returns `1`, `tee` returns `0`, and the job may appear successful despite the failed plan. ### Impact Assessment The flaw does not itself ...[truncated 570 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Capture Terraform's status explicitly and fail on errors: ```bash set -o pipefail terraform init terraform plan -detailed-exitcode -no-color 2>&1 | tee plan.txt EXIT_CODE=${PIPESTATUS[0]} case "$EXIT_CODE" in 0) echo "No drift detected." ;; 2) echo "::warning::Drift detected in ${{ matrix.environment }}" # Send the configured alert. exit 2 ;; *) echo "::error::Terraform plan failed with exit code $EXIT_CODE" exit "$EXIT_CODE" ;; esac ``` Additional hardening measures: 1. Test the workflow against all three expected Terraform exit statuses. 2. Send drift alerts through a configured, monitored notification channel rather than leaving notification as a comment. 3. Treat Terraform execution errors separately from detected drift. 4. Upload `plan.txt` as a restricted artifact for investigation, ensuring it does not expose sensitive values. 5. Use a read-only cloud role for drift detection. 6. Configure monitoring to alert when the scheduled workflow does not run or does not complete successfully. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill includes sensitive Terraform state operations such as state removal, import, backend migration, and other production-affecting workflows, but it lacks a prominent warning section that these actions can cause outages, orphan resources, or state corruption if performed incorrectly. Because this skill is explicitly aimed at production engineering, omission of explicit risk framing makes unsafe use more likely.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

| Monolithic state file | Slow plans, blast radius | Split by component (networking/compute/data) |
| No `prevent_destroy` on data stores | Accidental database deletion | Lifecycle rule on stateful resources |
| Unpinned module versions | Breaking changes on init | Pin with `?ref=v1.2.3` or `version = "~> 1.2"` |
| `terraform apply -auto-approve` in prod | Unreviewed changes | Plan artifact → human review → apply |
| Using workspaces as environments | Shared state, shared blast radius | Separate directories + backends per env |
| No cost estimation in CI | $10K surprise bills | Infracost or similar on every PR |
| Manual changes "just this once" | Permanent drift | Always go through code, even for emergencies |

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The natural-language triggers are very broad and map to common Terraform requests such as code review, security audit, CI/CD setup, and drift checks. In an agent environment, this can cause the skill to activate unexpectedly across many unrelated infrastructure conversations, increasing the chance of high-impact guidance being applied without sufficient scoping or safety checks.