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

Content

View full analysis

Remediation

View remediation

# v4.x.x - uses: aws-actions/configure-aws-credentials@ # v4.x.x - uses: hashicorp/setup-terraform@ # 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

Content

View full analysis

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:620

Finding

Drift Detection Pipeline Captures the Wrong Command Exit Status

Content

View full analysis

&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

View remediation

&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

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• 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.

Content

Scanner excerpt · SKILL.md (reported line 851)May include surrounding context.

md

| 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 |

Vague Triggers

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.