T09 · Insecure Skill Coding Practices
- Location
SKILL.md:151- Finding
Database Secret Persisted in Docker Image Metadata
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Docker guidance skill is only a Markdown template, but some production and security examples could lead users to leak credentials or run broad destructive cleanup commands.
Review this skill carefully before installing or using it as production guidance. Do not copy its secret-handling or Compose credential examples into real systems; use Docker or platform secrets, runtime injection, and unique credentials instead. Treat docker system prune -af as destructive and verify the Docker context and disposable resources before running it.
SKILL.md:151Database Secret Persisted in Docker Image Metadata
SKILL.md:178Hard-Coded Plaintext Database Credentials in Production Compose Template
SKILL.md:30Destructive Docker Cleanup Command Presented Without Safety Controls
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
docker system prune -af is a destructive cleanup command that removes unused containers, networks, images, and build cache; documenting it without caution can lead to accidental data or environment loss. In an agent skill meant to be reused as operational guidance, terse unsafe commands increase the chance of harmful copy-paste execution.
The skill says not to store secrets in images, then demonstrates ARG DB_PASSWORD followed by ENV DB_PASSWORD=$DB_PASSWORD, which bakes secret material into image metadata/layers and can expose it via image inspection, build history, or registry access. In a Docker guidance skill, this is especially dangerous because users may copy the pattern verbatim into production builds.
The example secret-handling pattern and credentials guidance normalizes embedding a database password in image configuration, contradicting secure practice and potentially leading users to leak credentials into images, CI logs, and registries. Because this skill presents itself as security-hardening guidance, the misleading example is more dangerous than a neutral code snippet.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
FROM debian:bookworm-slim RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/* COPY --from=builder /app/target/release/myapp /usr/local/bin/ CMD ["myapp"]
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
FROM debian:bookworm-slim RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/* COPY --from=builder /app/target/release/myapp /usr/local/bin/ CMD ["myapp"]
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
FROM debian:bookworm-slim RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/* COPY --from=builder /app/target/release/myapp /usr/local/bin/ CMD ["myapp"]
The heading/comment claims 'Read-only filesystem', but RUN chmod -R 555 /app only changes file permissions inside the image and does not enable Docker's read-only root filesystem behavior at runtime. The documentation overstates what the code achieves, creating an intent-code divergence.
No suspicious patterns detected.