T09 · Insecure Skill Coding Practices
- Location
scripts/main.py:257- Finding
Destructive Docker Cleanup Silently Bypasses Confirmation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Docker cleanup skill is purpose-aligned, but its implementation can delete Docker resources without the confirmations its documentation promises.
Review carefully before installing or running. Treat cleanup commands as destructive even without --force, avoid using this against production or remote Docker contexts, do not rely on dry-run volume/network counts as an exact deletion plan, and make backups before any volume cleanup.
scripts/main.py:257Destructive Docker Cleanup Silently Bypasses Confirmation
scripts/main.py:187Dry-Run Incorrectly Reports Every Volume and Network as Unused
README.md:12Documentation Recommends Installing an Unpinned and Unused Dependency
Stopped-container cleanup always appends --force, even when the caller did not request force. That removes any meaningful confirmation barrier in a destructive tool and makes accidental or automated invocation far more dangerous, especially in environments where stopped containers may be retained for forensics or recovery.
Image cleanup performs forced deletion without any effective confirmation, and --all may expand the scope significantly beyond dangling images. In a container-management context, that can break builds, deployments, or recovery workflows by deleting cached or needed images unexpectedly.
Volume cleanup permanently deletes data-bearing Docker volumes while always forcing the prune operation. Because volumes often contain persistent application databases or state, this behavior creates a serious risk of irreversible data loss from accidental execution or misleading dry-run output.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
# Remove dangling images only
python3 scripts/main.py clean --images --dangling
# Force cleanup of everything (no confirmation)
python3 scripts/main.py clean --all --force
# Dry run (show what would be removed)
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- `--volumes`: Remove unused volumes
- `--networks`: Remove unused networks
- `--all`: Clean all resource types (equivalent to --containers --images --volumes --networks)
- `--force`: Skip confirmation prompts
- `--dry-run`: Show what would be removed without actually removing
- `--yes`: Auto-answer "yes" to all prompts
- `--no-interactive`: Disable interactive mode (use with --yes for scripts)
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- `--volumes`: Remove unused volumes
- `--networks`: Remove unused networks
- `--all`: Clean all resource types (equivalent to --containers --images --volumes --networks)
- `--force`: Skip confirmation prompts
- `--dry-run`: Show what would be removed without actually removing
- `--yes`: Auto-answer "yes" to all prompts
- `--no-interactive`: Disable interactive mode (use with --yes for scripts)
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
If permission denied:
❌ Permission denied. You may need to run with sudo or add your user to the docker group.
If timeout occurs:
The skill advertises shell-capable behavior via Docker and Python CLI usage but does not declare any explicit tool scope or permissions boundaries. In an agent environment, missing tool restrictions can let the skill invoke powerful local commands against the host Docker daemon, increasing the blast radius of misuse or prompt-injection-driven execution.
The documented '--force' mode enables destructive cleanup with no confirmation, which is an autonomous destructive action against local Docker resources. In this skill's context, that is especially dangerous because Docker cleanup can remove containers, images, volumes, and networks, causing data loss or service disruption if triggered unintentionally or by a compromised agent workflow.
python3 scripts/main.py clean --networks
Force cleanup (no confirmation):
```bash
python3 scripts/main.py clean --all --force
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def check_docker_available() -> bool:
"""Check if Docker is installed and running."""
try:
result = subprocess.run(["docker", "version"],
capture_output=True, text=True, timeout=5)
return result.returncode == 0
except (subprocess.TimeoutExpired, FileNotFoundError):
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
"""Run a docker command and return standardized result."""
start_time = time.time()
try:
result = subprocess.run(
["docker"] + cmd,
capture_output=True,
text=True,
The status/dry-run logic reports all volumes as unused even though it does not verify actual attachment or use. In a cleanup tool, this is dangerous because it can mislead users into authorizing deletion of important persistent data volumes, increasing the risk of irreversible data loss.
The code marks all networks as unused without checking whether containers are attached. This can misrepresent cleanup impact and cause users to remove networks that are operationally important, leading to application connectivity failures or service disruption.
Network cleanup also forces prune without meaningful confirmation. Although typically less severe than volume deletion, unexpected removal of Docker networks can disrupt service communication, break local development environments, and complicate incident recovery.
The --unused option is documented in a way that suggests careful identification of images not used by any container, but the implementation relies on docker image prune --all. While Docker's prune behavior is valid, the mismatch between advertised semantics and actual action can cause broader-than-expected deletion and operational disruption.
No suspicious patterns detected.