Terraform Skill

• Outcome: Review
• Latest audit: Sep 16, 2026 · 3:41 AM UTC
• Version: 1.0.0

Overview

This is mostly Terraform guidance, but it includes copy-ready patterns that can run mutable remote code, change or destroy infrastructure with weak safeguards, mishandle secrets, and add unwanted attribution.

Review and edit the generated guidance before adopting it. Do not copy the pipe-to-shell installers, mutable CI Action refs, -auto-approve Terraform commands, destructive cleanup scripts, or mandatory attribution defaults into real projects without explicit approval, pinned versions, sandbox accounts, least-privilege credentials, state and plan protections, and manual review gates.

A.I.G

Vulnerability Patterns

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

Findings (8)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/ci-cd-workflows.md:45
• Finding: Mutable TFLint Installation Script Is Downloaded and Executed Directly<![CDATA[ ## Vulnerability Details **File Location**: `references/ci-cd-workflows.md:45-50` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```yaml - name: TFLint run: | curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash tflint --init tflint ``` ### Technical Analysis The workflow downloads a shell script from the mutable `master` branch and immediately pipes it into Bash. It does not pin an immutable commit or release, verify a checksum or signature, save the script for review, or fail explicitly on all HTTP errors. Consequently, the effective code executed by the workflow can change after this Skill has been reviewed. Trust is placed not only in the current script, but also in the upstream repository, maintainer accounts, source-hosting infrastructure, DNS and TLS path, and every future modification to the branch. The command is unnecessary for the Skill's declared guidance functionality. A package from a fixed release or a verified binary would provide TFLint without granting a mutable remote response immediate shell execution. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or another part of the script-delivery chain. 2. The attacker modifies `install_linux.sh` on the referenced `master` branch. 3. A user or Agent adopts the supplied CI template. 4. The CI runner downloads the changed script and passes it directly to Bash. 5. The payload executes with the runner's permissions and can inspect the checked-out repository, environment variables, CI tokens, filesystem, network, and any cloud credentials available to the job. 6. The payload can then alter build output, steal credentials, modify infrastructure code, or compromise downstream artifacts. ### Impact Assessment Successful exploitation provides arbitrary command execution as the CI runner or developer executing the command. The pract ...[truncated 256 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the `curl | bash` installation pattern. - Install TFLint through a trusted package manager or download a fixed release artifact. - Pin the release version and immutable source commit. - Verify a vendor-published SHA-256 checksum and, where available, a cryptographic signature before execution. - Download the file separately and terminate on HTTP errors rather than executing a response stream. - Run installation in an isolated, unprivileged environment. - Restrict CI job permissions and do not expose cloud credentials to the validation job. - Cache only verified tool binaries and update them through a reviewed dependency-update process. ]]>

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/security-compliance.md:37
• Finding: Mutable Trivy Installation Script Is Piped Directly into a Shell<![CDATA[ ## Vulnerability Details **File Location**: `references/security-compliance.md:37-46` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash # macOS brew install trivy # Linux curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # In CI - uses: aquasecurity/trivy-action@master with: scan-type: 'config' scan-ref: '.' ``` ### Technical Analysis The Linux installation command retrieves a script from the mutable `main` branch and executes it immediately. No immutable version, commit digest, checksum, or signature is verified. The script is instructed to install into `/usr/local/bin`, a system-wide executable location that commonly requires elevated privileges or a specially permissive environment. This expands the potential effect beyond the project directory and can replace or introduce a command used by other users and processes. Although Trivy is relevant to the Skill's security-scanning function, direct execution of mutable remote code and system-wide installation exceed the minimum privileges necessary to recommend or run a scanner. ### Attack Path 1. An attacker compromises the upstream repository, branch, maintainer account, or script-delivery path. 2. Malicious commands are inserted into the mutable installation script. 3. A user or Agent follows the documented Linux installation command. 4. The shell executes the remote response without local review or integrity verification. 5. The script runs with the invoking user's permissions and attempts to write into `/usr/local/bin`. 6. If elevated permissions are available, the payload can install or replace system-wide executables; otherwise, it can still access the user's files, credentials, and network resources. ### Impact Assessment The immediate impact is arbitrary shell execution. Depending on how the installation is invoked, this may provide developer-ac ...[truncated 216 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not pipe network responses directly into a shell. - Prefer an official package repository or a fixed Trivy release artifact. - Pin the exact version and immutable release URL. - Validate the artifact against the vendor's published checksum and signature. - Install into a user-controlled tool directory unless a system-wide installation is explicitly required. - If system-wide installation is necessary, require deliberate approval and document the exact files being installed. - Keep security scanning jobs separate from credential-bearing deployment jobs. - Pin the corresponding CI Action to a reviewed full commit SHA. ]]>

T01 · Skill Instruction Hijacking

Error

• Location: references/module-patterns.md:779
• Finding: Skill Mandates Promotional Attribution in Generated Public and Private Modules< by Anton Babenko. Additional resources: - [terraform-best-practices.com](https://terraform-best-practices.com) - [Compliance.tf](https://compliance.tf) ``` ```text When to include attribution: - ✅ All new modules created with terraform-skill guidance - ✅ Public modules (GitHub, Terraform Registry) - ✅ Private modules shared within organizations - ⚠️ Optional for one-off environment configurations ``` ### Technical Analysis The Skill directs the Agent to insert author branding and external promotional links into generated repositories, including private organizational modules. This requirement is unrelated to the technical correctness or security of most Terraform tasks and may be applied even when the user did not request attribution. The instruction alters the Agent's output policy when the Skill is loaded. It also presents attribution as broadly required for generated modules, even though license obligations depend on what copyrighted material is actually copied or modified and cannot be inferred merely from following general best practices. ### Attack Path 1. A user asks the Agent to generate a Terraform module. 2. The Skill activates and loads the module-generation guidance. 3. The mandatory attribution instruction is treated as part of the generation requirements. 4. The Agent adds third-party branding and links to the generat ...[truncated 690 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove mandatory attribution and promotional-link requirements. - Do not insert branding into generated public or private repositories unless the user explicitly requests it. - If copied material has a genuine license or NOTICE obligation, explain that obligation neutrally and preserve only the legally required notices. - Distinguish general best-practice guidance from copied or derivative source material. - Ask for user confirmation before adding optional acknowledgments. - Keep module-generation defaults focused on technical files and requirements requested by the user. ]]>

T08 · Insecure Dependencies

Error

• Location: references/ci-cd-workflows.md:379
• Finding: Security Scanning Workflow Executes Actions from Mutable Branch References<![CDATA[ ## Vulnerability Details **File Location**: `references/ci-cd-workflows.md:379-395` **Vulnerability Type**: Mutable third-party CI dependencies **Risk Level**: High ### Vulnerable Code ```yaml security-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run Trivy uses: aquasecurity/trivy-action@master with: scan-type: 'config' scan-ref: '.' - name: Run Checkov uses: bridgecrewio/checkov-action@master with: directory: . framework: terraform ``` ### Technical Analysis The Trivy and Checkov Actions are referenced through the mutable `master` branch. Other workflow examples use mutable major-version tags such as `@v3` and `@v2`. Neither branch references nor version tags provide immutable dependency identity. GitHub Actions execute code inside the workflow job and can access the workspace, job token, environment, network, and any credentials made available to that job. A compromised upstream repository or retargeted reference therefore becomes a direct CI code-execution path. ### Attack Path 1. An upstream Action repository or maintainer account is compromised, or a mutable reference is updated with malicious content. 2. A repository adopts the documented workflow. 3. GitHub resolves `@master` or another mutable tag to the attacker-controlled revision. 4. The Action executes inside the CI job. 5. It reads source files, job tokens, environment variables, artifacts, or credentials permitted to the job. 6. It can exfiltrate data, alter scan results, modify artifacts, or compromise later workflow stages. ### Impact Assessment Exploitation provides arbitrary code execution in the CI job's security context. Scope depends on workflow permissions and available secrets, but can include source-code access, repository-token permissions, artifact manipulation, and cloud-account access if credentials are exposed in the same job or workflow. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin every third-party Action to a reviewed full commit SHA. - Annotate SHA pins with the corresponding release version for maintainability. - Configure explicit, minimal workflow and job-level `permissions`. - Do not expose deployment credentials to validation or scanning jobs. - Use dependency automation to propose reviewed SHA updates. - Separate untrusted pull-request processing from privileged branch workflows. - Prefer maintained current Action releases and retire obsolete major versions after compatibility testing. ]]>

T08 · Insecure Dependencies

Warning

• Location: references/security-compliance.md:197
• Finding: Terraform Compliance Tool Is Installed from an Unpinned Package Version<![CDATA[ ## Vulnerability Details **File Location**: `references/security-compliance.md:197-204` **Vulnerability Type**: Unpinned package dependency **Risk Level**: Medium ### Vulnerable Code ```bash pip install terraform-compliance ``` ### Technical Analysis The installation command does not specify a reviewed package version or verify package hashes. It therefore installs whichever version the package index resolves at execution time. The resulting environment is not reproducible and may unexpectedly consume a compromised, malicious, or incompatible future release. Python packages and their dependencies can execute code during installation and later when invoked, so package integrity directly affects the developer or CI execution environment. ### Attack Path 1. A package release or transitive dependency is compromised, or an unsafe future version is published. 2. A user or CI job runs the documented unpinned installation command. 3. The package resolver selects the compromised version. 4. Package installation or subsequent tool execution runs attacker-controlled code. 5. The code accesses files, tokens, network resources, and credentials available to the Python environment. ### Impact Assessment The potential privilege level is that of the account running `pip`, commonly a developer, container user, or CI runner. If invoked with elevated privileges, impact can become system-wide. Otherwise, repository data, user credentials, virtual-environment contents, and CI secrets may still be exposed. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin `terraform-compliance` to a reviewed exact version. - Maintain dependencies in a lock file or hashed requirements file. - Require package hashes during installation where practical. - Install into an isolated virtual environment rather than the system Python environment. - Review and update pinned versions through a controlled dependency-update process. - Use a trusted internal package mirror for higher-assurance environments. ]]>

T08 · Insecure Dependencies

Warning

• Location: references/module-patterns.md:797
• Finding: Pre-Commit Is Installed from an Unpinned Package Version<![CDATA[ ## Vulnerability Details **File Location**: `references/module-patterns.md:797-806` **Vulnerability Type**: Unpinned package dependency **Risk Level**: Medium ### Vulnerable Code ```bash # Install pre-commit pip install pre-commit # Install hooks pre-commit install # Run manually pre-commit run -a ``` ### Technical Analysis The command installs the latest package version resolved at execution time without version or hash verification. It then installs hooks into the local Git repository and runs configured third-party hook code. Although the referenced Terraform hook repository is version-tagged elsewhere in the file, the `pre-commit` executable itself remains unpinned, and a version tag is not as strong as an immutable commit pin for hook repositories. This creates both package supply-chain and repository-hook execution risks. ### Attack Path 1. The package, a transitive dependency, or a configured hook source is compromised. 2. A user follows the documented installation and hook setup commands. 3. The resolver installs the unsafe package or hook revision. 4. `pre-commit install` adds a Git hook that will execute during later repository operations. 5. `pre-commit run -a` or a subsequent commit runs the dependency-controlled code with the user's permissions. 6. The code can read or alter repository files and access credentials available to the local environment. ### Impact Assessment Successful exploitation provides code execution as the developer or CI account. The installed Git hook also creates repeated execution tied to future Git operations within the repository, increasing exposure until the hook or compromised dependency is removed. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the `pre-commit` package to an exact reviewed version. - Use a locked, hash-verified Python dependency file. - Install the tool in an isolated virtual environment. - Pin hook repositories to immutable commit hashes rather than mutable tags where supported. - Review hook manifests before installation and execution. - Explain that `pre-commit install` modifies repository hooks and obtain user approval before performing that action. - Periodically audit `.git/hooks` and the pre-commit cache for unexpected code. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/security-compliance.md:97
• Finding: Recommended Secrets Manager Pattern Still Stores Database Password in Terraform State<![CDATA[ ## Vulnerability Details **File Location**: `references/security-compliance.md:97-107` **Vulnerability Type**: Plaintext sensitive data persisted in Terraform state **Risk Level**: High ### Vulnerable Code ```hcl # Good: Reference secrets from AWS Secrets Manager data "aws_secretsmanager_secret_version" "db_password" { secret_id = "prod/database/password" } resource "aws_db_instance" "this" { password = data.aws_secretsmanager_secret_version.db_password.secret_string } ``` ### Technical Analysis Retrieving a secret from AWS Secrets Manager does not by itself prevent Terraform from storing the value. Assigning `secret_string` to a normal resource argument such as `password` can serialize the plaintext password into Terraform state and potentially into saved plans. Marking a value as sensitive only suppresses some display paths; it does not remove the value from state. The example is labeled as good security guidance even though it may expose the credential to state readers. Another project reference correctly demonstrates a write-only argument, `password_wo`, making the guidance internally inconsistent. The pre-scan alert associated with `references/code-patterns.md:759` is not itself evidence of network exfiltration: that example uses a write-only argument and is the safer pattern. The confirmed issue is the normal `password` assignment shown here. ### Attack Path 1. A user or Agent adopts the documented Secrets Manager pattern. 2. Terraform reads the plaintext secret through the data source. 3. The provider receives the value through the normal `password` argument. 4. Terraform serializes the sensitive value into state or a saved plan. 5. State versions, backups, local files, CI artifacts, or remote-backend readers retain access to the value. 6. An attacker or unauthorized operator with state access recovers the database credential and uses it against the database or related systems. ### Impact Assessment The vulnerability can disclose ...[truncated 351 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace normal secret-bearing arguments with provider-supported write-only arguments such as `password_wo` where available. - Prefer provider-managed database passwords when supported. - Explicitly state that Secrets Manager data sources and `sensitive = true` do not keep values out of state. - Avoid passing secret material through Terraform when write-only or managed-secret mechanisms are unavailable. - Encrypt remote state, enforce least-privilege state access, enable access logging, and tightly control state backups. - After remediation, rotate the exposed credential and remove or securely retire all historical state and plan copies containing it. - Update all security-guide examples to match the safer write-only pattern already shown in `references/code-patterns.md`. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/ci-cd-workflows.md:80
• Finding: Terraform Plan Containing Potentially Sensitive Values Is Uploaded as a CI Artifact<![CDATA[ ## Vulnerability Details **File Location**: `references/ci-cd-workflows.md:80-90` **Vulnerability Type**: Sensitive CI artifact exposure **Risk Level**: Medium ### Vulnerable Code ```yaml - name: Terraform Plan run: terraform plan -out=tfplan - name: Upload Plan uses: actions/upload-artifact@v3 with: name: tfplan path: tfplan ``` ### Technical Analysis A saved Terraform plan can contain complete planned values, infrastructure identifiers, configuration details, and secrets that flow through ordinary Terraform arguments. The example uploads this binary plan as a CI artifact without warning that it must be treated as sensitive. The template does not specify minimal artifact retention, discuss artifact-access controls, isolate the plan from untrusted jobs, or ensure that secret values cannot enter the plan. The upload Action is also referenced by a mutable major-version tag. ### Attack Path 1. Terraform evaluates a configuration containing sensitive values. 2. `terraform plan -out=tfplan` writes those values and infrastructure details into the saved plan. 3. The workflow uploads the plan to CI artifact storage. 4. A user, compromised Action, token holder, or workflow with artifact-read permission retrieves it. 5. The plan is inspected with compatible Terraform tooling or consumed by another process. 6. Sensitive configuration or credentials are disclosed and can be used against cloud or application resources. ### Impact Assessment Exposure may reveal cloud-resource topology, account identifiers, network configuration, planned changes, and secret values. If credentials are present, impact extends to the privileges associated with those credentials. The production apply stage also trusts the transferred artifact, so inadequate artifact integrity controls can affect deployed infrastructure. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Treat saved plan files as sensitive security artifacts. - Avoid cross-job plan transfer where possible, or use a protected deployment system with authenticated plan provenance. - Set the shortest practical retention period and restrict artifact access to authorized deployment identities. - Pin upload and download Actions to reviewed full commit SHAs. - Ensure secret values use write-only or provider-managed mechanisms so they do not enter plans or state. - Separate pull-request workflows from privileged production deployment workflows. - Bind approval to the exact plan digest and verify that digest immediately before apply. - Never publish plan files from untrusted fork workflows. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults

Findings (23)

Self-Modification

High

• Category: Rogue Agent

Content

- No build artifacts

**Validation approach:**
1. Update SKILL.md
2. Load in Claude Code (reload skills)
3. Test on real Terraform projects
4. Observe if Claude applies patterns correctly

• Confidence: 85% confidence
• Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

• Category: Rogue Agent

Content

- No build artifacts

**Validation approach:**
1. Update SKILL.md
2. Load in Claude Code (reload skills)
3. Test on real Terraform projects
4. Observe if Claude applies patterns correctly

• Confidence: 85% confidence
• Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Chaining Abuse

High

• Category: Tool Misuse

Content

- name: TFLint
        run: |
          curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash
          tflint --init
          tflint

• Confidence: 99% confidence
• Finding: The use of curl ... | bash is a classic command-chaining pattern that executes unreviewed network content immediately. In CI/CD contexts this is especially dangerous because the runner may have repository write access, cloud credentials, and other secrets, so a compromised upstream script can lead to code execution and broader environment compromise.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

checkov -d . --framework terraform

# Skip specific checks
checkov -d . --skip-check CKV_AWS_23

# Generate JSON report
checkov -d . -o json > checkov-report.json

• Confidence: 70% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Credential Access

High

• Category: Privilege Escalation

Content

```
*.tfvars
.env
secrets/
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```
*.tfvars
.env
secrets/
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Session Persistence

Medium

• Category: Rogue Agent

Content

### Progressive Disclosure

```
User: "Create a Terraform module with tests"
       ↓
Claude: Scans skill metadata (~100 tokens)
       ↓

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Quick Start

1. Fork the repository
2. Create a feature branch
3. Make your changes following the guidelines below
4. Test your changes (see Testing Requirements)
5. Submit a pull request

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The cleanup automation terminates resources based on tag/query logic without prominent safeguards, dry-run guidance, scope validation, or warnings about destructive impact. In an infrastructure automation skill, readers may adopt this pattern directly, and mistakes in tag matching, query behavior, or IAM scope could lead to deletion of unintended resources.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The Atlantis example explicitly passes extra_args: ["-lock", "false"], which disables Terraform state locking during plan, while nearby documentation claims locking prevents concurrent changes. In a CI/CD Terraform skill, this is dangerous because users may copy the example into real automation, increasing the risk of concurrent state operations, race conditions, and state corruption or unintended infrastructure changes.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

**4. Integration testing:**
```bash
# Apply and verify
terraform apply -auto-approve

# Verify resources exist (use AWS CLI, etc.)
aws ec2 describe-vpcs --vpc-ids $(terraform output -raw vpc_id)

• Confidence: 94% confidence
• Finding: Using `terraform apply -auto-approve` removes the human confirmation step for creating or modifying infrastructure. In an agent skill context, this increases the risk that an automated system will make unintended changes without review, especially if pointed at non-test environments or privileged credentials.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The document presents destructive Terraform workflows including apply and destroy commands with automatic approval, but does not pair them with clear warnings about running only in isolated test accounts or reviewing plans first. In a skill used to guide agents, this can normalize unsafe execution patterns and increase the chance of unintended infrastructure changes or deletions.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

# Expected: "No changes. Your infrastructure matches the configuration."

# Clean up
terraform destroy -auto-approve
```

### Input Validation Testing

• Confidence: 96% confidence
• Finding: `terraform destroy -auto-approve` enables immediate deletion of managed infrastructure without an interactive checkpoint. In a guidance file for automation, this is particularly dangerous because an agent or user may run it against the wrong state or account, causing irreversible outages or data loss.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

```bash
# Apply configuration
terraform apply -auto-approve

# Immediately run plan - should show no changes
terraform plan -detailed-exitcode

• Confidence: 93% confidence
• Finding: The idempotency test example again uses `terraform apply -auto-approve`, encouraging unattended infrastructure mutation as part of routine testing. In this skill's context, that can be copied into CI/CD or agent workflows and lead to unreviewed provisioning in real environments.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

BEFORE_COUNT=$(terraform state list | wc -l)

# Destroy
terraform destroy -auto-approve

# After destroy - verify state is empty
AFTER_COUNT=$(terraform state list | wc -l)

• Confidence: 97% confidence
• Finding: The destroy testing example uses `terraform destroy -auto-approve`, which can instantly tear down all resources in the current state with no confirmation. In an IaC skill consumed by agents, this meaningfully increases the risk of accidental destructive operations if environment selection or credentials are wrong.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This guidance includes `command = apply` examples that can create real infrastructure and may incur cloud costs or modify environments, but it does not place an explicit safety warning immediately around the examples. In a Terraform testing guide, readers may copy patterns directly into live workflows, so omission of clear side-effect warnings increases the chance of unintended deployment, spend, or destructive changes during testing.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The Terratest sample calls `terraform.InitAndApply` and `terraform.Destroy`, which perform real infrastructure changes, yet the example lacks a prominent upfront warning that execution can affect cloud environments, destroy resources, and generate billing. Because this is executable test code in a skill designed to guide users, it materially increases the risk of accidental use against production or non-isolated accounts.

Session Persistence

Medium

• Category: Rogue Agent

Content

### Test Prompt
```
Create a simple Terraform module for an AWS S3 bucket with:
- Versioning configuration
- Encryption settings
- Bucket policy support

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Vague Triggers

Low

• Confidence: 90% confidence
• Finding: The example invocation "Help me choose between native tests and Terratest for my modules" uses the broad phrase "Help me choose," which is common conversational language and not uniquely scoped to this skill. In a README describing how the skill is invoked, this can contribute to ambiguous activation boundaries compared with more domain-specific trigger wording.

External Script Fetching

Low

• Category: Supply Chain

Content

- name: TFLint
        run: |
          curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash
          tflint --init
          tflint

• Confidence: 99% confidence
• Finding: The workflow fetches an installer script from a remote GitHub URL and executes it during CI. This creates a supply-chain risk: if the remote script, repository, transport assumptions, or dependency path is compromised, arbitrary code will run in the CI runner with the job's permissions and secrets exposure.

External Script Fetching

Low

• Category: Supply Chain

Content

brew install trivy

# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# In CI
- uses: aquasecurity/trivy-action@master

• Confidence: 84% confidence
• Finding: The documentation recommends piping a remotely fetched script directly into 'sh', which creates a supply-chain and integrity risk. If the remote content, transport, or upstream repository is compromised, users may execute attacker-controlled code during installation.

Missing User Warnings

Low

• Confidence: 86% confidence
• Finding: This markdown file includes shell commands that set sensitive environment variables, including AWS credential examples. Although it says 'Never commit these,' it does not warn that exporting secrets in plaintext can leak through shell history, process inspection, or shared session logs, which is a user-facing safety consideration for secret-handling guidance.

Missing User Warnings

Low

• Confidence: 96% confidence
• Finding: The document instructs users to rename the live skill directory to disable and re-enable the skill, which directly modifies local files and operational state. While not inherently malicious, this can cause accidental disruption, race conditions with other tooling, or leave the environment in a misconfigured state if the restore step is missed.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: references/code-patterns.md:517

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: references/security-compliance.md:106