T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:52
- Finding
- Automatic Execution of Repository-Controlled Build and Test Commands<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:52-61` **Vulnerability Type**: Automatic execution of untrusted repository scripts **Risk Level**: High ### Vulnerable Code Snippet ```markdown 3. **Detect test + build commands.** Inspect repo manifests in parallel and infer commands: - `package.json` → `npm test`, `npm run build` (or `pnpm` / `yarn` if the lockfile says so) - `pyproject.toml` / `pytest.ini` → `pytest`, plus `python -m build` or project-specific - `*.csproj` / `*.sln` → `dotnet build`, `dotnet test` - `go.mod` → `go build ./...`, `go test ./...` - `Cargo.toml` → `cargo build`, `cargo test` - `Makefile` → check for `test` / `build` targets first - Monorepo (`turbo.json`, `nx.json`, `pnpm-workspace.yaml`) → use the orchestrator 4. **Run tests, then build.** Tests first (faster signal). If tests pass, run the build. Capture output. ``` ### Technical Analysis The Skill instructs the agent to infer and automatically execute build and test commands declared by the repository under review. These commands are not intrinsically safe: package lifecycle scripts, Python build backends, MSBuild targets, Makefile recipes, Cargo build scripts, and similar mechanisms can execute arbitrary repository-controlled code. The workflow does not require explicit user approval of the selected commands, validate that the repository is trusted, sanitize inherited environment variables, restrict filesystem access, disable networking, or require execution inside an isolated sandbox. Consequently, reviewing an attacker-controlled repository may cross the expected read-only boundary and execute arbitrary code with the permissions available to the agent. This behavior exceeds the minimum privileges needed for static code review. Build and test execution may be useful for production-readiness validation, but it should be treated as an optional, separately authorized operation with strong isolation. ### Attack Path 1. An attacker prep ...[truncated 1599 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make build and test execution opt-in. Present the exact commands and request explicit user approval before running them. 2. Treat every reviewed repository as untrusted, including repositories supplied through pull requests or external branches. 3. Execute approved commands inside an ephemeral container or equivalent sandbox with: - No host credential mounts. - A sanitized environment containing no secrets. - Read-only source access where practical. - A dedicated, disposable writable directory. - No access to the host Docker socket or privileged devices. - Strict CPU, memory, process, and execution-time limits. 4. Disable outbound networking by default. If dependencies must be retrieved, use an allowlisted proxy or a controlled dependency cache. 5. Separate static review from dynamic validation so users can receive a useful audit without executing repository code. 6. Log the exact command, working directory, environment policy, network policy, and sandbox configuration used for every approved execution. 7. Warn users that common build tools can execute arbitrary hooks even when the apparent command is a standard operation such as `npm test`, `python -m build`, or `cargo build`. ]]>