T09 · Insecure Skill Coding Practices
- Location
modules/integration-testing.md:60- Finding
Integration testing executes untrusted target-skill tools without isolation
- Content
View full analysis
Vulnerability Details
File Location:
modules/integration-testing.md, lines 60-87
Vulnerability Type: Unsafe execution of an untrusted executable during skill evaluation
Risk Level: HighVulnerable Code
python def test_tool_integration(skill_path: str) -> ToolIntegrationResults: """Test tool compatibility and integration""" results = ToolIntegrationResults() # Parse skill frontmatter frontmatter = parse_frontmatter(skill_path) declared_tools = frontmatter.get('tools', []) # Test each declared tool for tool in declared_tools: tool_path = find_tool(tool, skill_path) if tool_path and tool_path.exists(): results.tools_found.append(tool) # Test tool is executable if os.access(tool_path, os.X_OK): results.tools_executable.append(tool) # Test tool runs with --help try: subprocess.run([tool_path, '--help'], capture_output=True, timeout=5) results.tools_functional.append(tool) except Exception as e: results.tool_errors.append(f"{tool}: {e}") else: results.tools_missing.append(tool) return resultsTechnical Analysis
The documented integration-testing procedure resolves executable paths from the skill being evaluated and launches each executable directly with
subprocess.run. A--helpargument is not a security boundary: an executable controls its own argument handling and may run arbitrary initialization or payload logic before displaying help, or ignore the argument entirely.The procedure does not establish the provenance or integrity of the executable and does not use a sandbox, reduced-privilege account, read-only filesystem, network isolation, environment sanitization, or syscall restrictions. The ...[truncated 1555 chars]
- Remediation
View remediation
Remediation Suggestions
- Make static inspection the default and do not execute tools contained in an untrusted target skill.
- Require explicit user authorization before entering a clearly labeled dynamic-analysis mode.
- Execute dynamic tests only in a disposable container or virtual machine configured with:
- An unprivileged user and no additional Linux capabilities.
- No host credential, SSH-agent, cloud-token, or Docker-socket mounts.
- No network access by default.
- Read-only target artifacts and a disposable writable directory.
- A minimal, sanitized environment and controlled
PATH. - CPU, memory, process-count, output-size, and wall-clock limits.
- Seccomp, AppArmor, SELinux, or equivalent syscall restrictions where available.
- Resolve and validate the final canonical executable path, rejecting symlinks or paths outside the copied sandbox input.
- Verify tool hashes or signatures against trusted metadata when provenance is available.
- Treat exit status explicitly: use
check=True, record nonzero results as failures, and avoid marking a tool functional merely because process creation succeeded. - Destroy the complete execution environment after every target and preserve only bounded, sanitized diagnostic output.