Container Debug
Security checks across malware telemetry and agentic risk
Overview
This is a coherent Docker debugging guide, but it includes powerful Docker commands that should be run deliberately against the right containers.
This skill appears suitable for Docker troubleshooting. Before installing or using it, remember that Docker commands can be powerful: confirm container names, avoid unnecessary root shells, treat logs/environment output as potentially sensitive, and use trusted or pinned debug images when possible.
VirusTotal
62/62 vendors flagged this skill as clean.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run against the wrong target, these commands could alter local services, create extra resources, or affect running development environments.
The skill documents Docker commands that can start containers, create networks, and run new containers. This fits the container-debugging purpose, but these operations can change the user's local Docker environment.
docker start -ai my-container ... docker network create my-net ... docker run --network my-net --name api my-api-image
Review mutating Docker commands before running them, use the intended Compose project or container names, and clean up any temporary networks or containers afterward.
A user or agent following this guidance could access or modify files and secrets inside a container with higher privileges than the application normally has.
The skill explicitly includes root-level exec into a container. This is a common debugging technique, but it bypasses the container's normal non-root user boundary.
# As root (even if container runs as non-root user) docker exec -u root -it my-container bash
Use root exec only when necessary, confirm the target container, and avoid exposing or copying sensitive data from container environments.
Running unpinned public images can execute third-party code with access to the target container's network or process namespace.
The skill suggests running public debug images without pinning digests. This is purpose-aligned for troubleshooting, but it relies on external image provenance.
docker run -it --pid=container:my-container --net=container:my-container busybox sh ... docker run --rm --network container:my-container curlimages/curl curl -s http://localhost:8080 ... docker run --rm --net=container:my-container nicolaka/netshoot tcpdump
Prefer trusted internal images or pin image digests when using debug sidecars, especially around sensitive containers.