container-security-hardening
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. Use for Dockerfile security reviews, container CVEs, image scanning, distroless images, or production hardening.
Profile →npx skills add sickn33/agentic-awesome-skills --skill container-security-hardening --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Guides security-focused hardening of Docker/container images and runtimes, covering secure base images, non-root users, CVE/secret scanning, SBOM/signing, seccomp/AppArmor, and Kubernetes pod security controls. It is intended for Dockerfile security reviews, container CVEs, image scanning, distroless images, or production hardening.
How it works
The skill provides concrete, step-by-step guidance across layers:
- Layer 1: Dockerfile hardening, including using minimal base images, multi-stage builds, running as non-root, pinning base images by digest, avoiding secrets in layers, read-only filesystems, and minimal .dockerignore. It presents example Dockerfile snippets and a full hardened Dockerfile example.
- Layer 2: Image scanning, detailing Trivy, Grype, and Hadolint usage; secrets scanning; SBOM generation; and CI integration with GitHub Actions. It includes commands for installing tools, scanning images and files, ignoring specific CVEs, and integrating results (SARIF) into CI.
- Layer 3: Runtime security, covering docker run hardening flags for a locked-down container, Linux capabilities posture (drop all and selectively re-add), Docker Compose hardening, and Seccomp/AppArmor guidance, plus an example Compose file.
Additionally, it outlines the five-layer model of container security and provides practical commands and YAML/config snippets for enforcement at build, scan, and run time.
When to use it
Use when Docker security hardening, non-root configuration, CVE/secret scanning, SBOM/signing, seccomp/AppArmor, or Kubernetes pod security controls are relevant. Triggers include questions about distroless images, non-root containers, read-only filesystems, image signing, and Kubernetes pod security practices.
What it can touch
The skill references and instructs use of tools and configurations:
- Commands and files: "Dockerfile" snippets, "FROM" lines, and various snippet blocks shown in the text.
- Tools: Trivy, Grype, Hadolint, TruffleHog, git secrets, Cosign (SBOM/signing related mentions), Renovate/Dependabot (digest pinning), Seccomp profiles, AppArmor, and Kubernetes security concepts. It provides concrete commands and file names exactly as described in the material.
Caveats
The skill presents specific commands, examples, and configuration blocks. It does not guarantee security outcomes and should be implemented with awareness of the user’s environment (base OS, registry, CI, Kubernetes distribution). No licensing or legal risk details beyond general tool mentions are listed; licensing is noted as MIT for the skill as a whole.
# 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 (S
- When to Use This Skill
- When NOT to Use This Skill
- Step 1: Understand Context Before Responding
- The Five Layers of Container Security
- Layer 1: Dockerfile Hardening
- 1.1 Use a Minimal Base Image
- 1.2 Multi-Stage Build — Separate Build from Runtime
- 1.3 Run as Non-Root User
- 1.4 Pin Base Images to Digest
- 1.5 Never Bake Secrets into Images
- 1.6 Read-Only Filesystem & No New Privileges
- 1.7 Minimal .dockerignore
- 1.8 Full Hardened Dockerfile Example
- Layer 2: Image Scanning
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
Check if Kubernetes manifests exist
find . -name "*.yaml" -path "*/k8s/*" -o -name "*.yaml" -path "*/manifests/*" | head -10
docker pull node:20-slim
docker inspect node:20-slim --format='{{index .RepoDigests 0}}'What does the container-security-hardening skill do?
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. Use for Dockerfile security reviews, container CVEs, image scanning, distroless images, or production hardening.
How do I install it?
Run `npx skills add sickn33/agentic-awesome-skills --skill container-security-hardening --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From sickn33/agentic-awesome-skills, a repository with 44,414 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.