T08 · Insecure Dependencies
Error
- Location
- SKILL.md:106
- Finding
- Unsafe execution of untrusted AWS CDK projects through npx## Vulnerability Details **File Location**: `SKILL.md`, lines 106–109 **Vulnerability Type**: Unpinned dependency resolution and execution of project-controlled code **Risk Level**: High **Complete Code Snippet**: ```bash # Synth and check output npx cdk synth --quiet 2>&1 # Check for drift npx cdk diff 2>&1 ``` ### Technical Analysis The skill instructs the agent to run `npx cdk synth` and `npx cdk diff` inside the application under audit. This creates two related execution risks: 1. If no suitable local CDK executable exists, `npx` may resolve and download an unpinned package from the configured package registry. This creates a dependency supply-chain risk because the executed version and artifact are not explicitly constrained or verified. 2. CDK synthesis and diff operations load and execute the target project's configured CDK application. Consequently, these commands are not passive inspection operations: attacker-controlled application code and dependency initialization logic can execute with the auditing process's permissions. The instructions do not require a sandbox, prohibit network access, remove ambient credentials, enforce a verified lockfile, use `npx --no-install`, or request user authorization before execution. ### Attack Path 1. An attacker supplies or contributes a malicious AWS CDK project for analysis. 2. The project defines an attacker-controlled CDK entry point or malicious dependency initialization code. 3. The agent follows the skill instructions and invokes `npx cdk synth --quiet` or `npx cdk diff`. 4. `npx` may obtain an executable through dependency resolution, after which CDK loads and executes the project's application. 5. The malicious code executes with the agent process's filesystem access, environment variables, network access, and any ambient cloud credentials. 6. If AWS credentials are available, the code may read or misuse them; `cdk diff` may also interact with AWS according ...[truncated 563 chars]
- Remediation
- ## Remediation Suggestions - Make static source and template inspection the default; do not execute applications from untrusted repositories automatically. - Require explicit user approval before synthesis or diff operations. - Use a pinned, lockfile-verified local CDK dependency and invoke it with `npx --no-install cdk ...` so the audit cannot silently download a package. - Verify dependency integrity using a committed lockfile and a reproducible installation process. - Execute CDK commands in a disposable container or virtual machine with no host filesystem access beyond a read-only project mount. - Remove AWS credentials, cloud configuration, tokens, and unrelated secrets from the execution environment. - Disable outbound network access unless it is strictly required and explicitly authorized. - Avoid `cdk diff` against live AWS environments during an untrusted-code audit. If it is necessary, use a dedicated read-only audit role with narrowly scoped permissions. - Apply process limits, timeouts, and resource quotas, and discard the sandbox after each analysis.