Harden Docker/container images and runtime deployments with secure base images, non-root users, CVE scanning, SBOM/signing, seccomp/AppArmor, and Kubernetes pod security controls.
SkillScore100Maintained
Automatic
◆Security & AppSec pack
Last verified 8/28/2026
What it changes
Passed 23 of 23 test cases with the skill, and 19 of 23 without it.
Without skill83%
With skill100%
Checks it passed that the model alone missed
Lists allowed registries under trustedRegistries.
Includes OCI labels prefixed with org.opencontainers.image.
Specifies a non-root numerical UID for the USER instruction.
and 3 more in the full report
4 fixed19 passed either way0 still failing0 broke
Pass-rate lift
+17 pp
Tokens
+388%
Agent turns
0%
Response time
-10%
Model gemini-3.6-flashMeasured 8/28/2026v123 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
I have an unhardened Node.js application Dockerfile currently running as root that ships build tools to production. Please review it and provide a fully refactored, production-ready multi-stage Dockerfile that implements proper container security practices. Include an explanation of the changes made for base image selection, privilege reduction, build vs runtime separation, and build-time secret handling.
What was checked, without and with the skill
Checked
Without skill
With skill
Pins the base image in the runtime stage using a SHA256 digest.
Missed
Passed
Includes a HEALTHCHECK instruction in the runtime stage.
Passed
Passed
Includes OCI labels prefixed with org.opencontainers.image.
Missed
Passed
case-01 · gemini-3.6-flash · 8/28/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md988 lines4 files
Container Security Hardening Skill
A production-focused guide for building, scanning, and running containers securely — from Dockerfile authoring through runtime enforcement and supply chain integrity.
When to Use This Skill
User mentions Docker security, container hardening, or Dockerfile security review
User asks about distroless images, non-root containers, or read-only filesystems
User wants to scan images for CVEs with Trivy, Grype, or Snyk
User mentions seccomp, AppArmor, Linux capabilities, or runtime security
User asks "is my Dockerfile secure?" or "how do I reduce my image attack surface?"
User wants to sign/verify images with Cosign or generate SBOMs
User asks about Kubernetes pod security, NetworkPolicy, or RBAC hardening
User says "fix container CVEs" or "harden my container for production"
When NOT to Use This Skill
The user is primarily asking about GitHub Actions CI/CD → recommend github-actions-advanced
The user needs general Docker usage help (not security) → recommend docker-expert
The user is working with Kubernetes orchestration beyond security → recommend kubernetes-architect
The user needs application-level security (SQL injection, XSS) → recommend api-security-best-practices
Step 1: Understand Context Before Responding
When invoked, first detect the current state:
# Find Dockerfiles in the project
find . -name "Dockerfile*" -not -path "*/node_modules/*" | head -10
# Check for existing security tooling
ls .trivyignore .hadolint.yaml .snyk docker-compose*.yml 2>/dev/null
# Inspect base images currently in use
grep -r "^FROM" $(find . -name "Dockerfile*") 2>/dev/null