T09 · Insecure Skill Coding Practices
- Location
SKILL.md:81- Finding
Untrusted Specification Commands May Be Marked for Autonomous Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 81-145
Vulnerability Type: Command injection through generated verification instructions
Risk Level: HighVulnerable Code
The following is an English translation of the relevant source directives:
markdown - Automatable → mark as `[A]`, including an executable command and expected result. When to use `[A]`: 1. HTTP requests — curl, wget, or any API call 2. Shell commands — grep, find, diff, cat, and file-existence checks 3. Build/compile — npm run build, tsc, cargo test 4. JSON/output comparison — inspect response structure and status codes 5. Process/port checks — ss, lsof, psmarkdown Preparation items are used by sdd-start-human-verify for autonomous execution. - `[AUTO]` — a one-time command that is executed directly and checked by exit code. Format: `- [ ] [AUTO] description: command` - `[AUTO/SERVICE]` — a long-running service started in the background. The default classification is `[AUTO]`. The following categories are always `[AUTO]`: - File and configuration checks - Version and dependency checks - Compilation and build commands - Dependency installation — `npm install`, `pip install`, `apt-get install` - Database migration and seed commandsTechnical Analysis
The skill extracts commands and verification procedures from workspace-controlled
spec-plan.mdandspec-design.mdfiles. It then places executable content into[A],[AUTO], or[AUTO/SERVICE]entries intended for autonomous execution by the downstreamsdd-start-human-verifyprocess.The source specification documents therefore cross a trust boundary: content that should be treated as untrusted documentation can become executable shell instructions. The skill does not require an allowlist, shell-token validation, command argument validation, URL validation, package-source validation, privilege restrictions, or sandboxing. It ...[truncated 2236 chars]
- Remediation
View remediation
Remediation Suggestions
- Treat every command extracted from specification documents as untrusted input.
- Do not automatically copy source-document commands into executable
[AUTO]entries. - Restrict autonomous checks to a narrowly defined allowlist of read-only commands and fixed argument patterns.
- Parse commands into argument arrays rather than passing strings to a shell.
- Reject shell metacharacters and execution features, including command substitution, pipes, redirection, background execution, chained commands, and environment-variable expansion.
- Prohibit autonomous use of download utilities, package installers, migration tools, privilege-changing commands, and arbitrary build hooks.
- Require separate, explicit approval for every command that writes files, modifies databases, installs software, starts a service, or accesses the network.
- Display the exact command, working directory, environment changes, destination host, and expected side effects before approval.
- Validate outbound URLs against an approved host and protocol list. Block redirects and private-network destinations unless explicitly required.
- Pin package names, versions, registries, and integrity hashes when dependency installation is unavoidable.
- Execute approved checks in an isolated sandbox with minimal filesystem access, no inherited secrets, restricted network access, resource limits, and a nonprivileged user.
- Add provenance metadata to each generated command and flag commands copied from specification files for manual security review.
- Make the safe default non-executable. Only commands generated from trusted, predefined verification templates should qualify for autonomous execution.
