container-hardeninglisted

# Container Hardening ## When to use This skill covers the container-image layer: what's inside, how it runs, and how you prove it checks out. It's the foundation `k8s-security` builds on (K8s takes these images and adds cluster-level controls). Activates on: - A request like "review our Dockerfile", "migrate to distroless", "why does our container run as root", "trivy scan triage", "sign images with cosign". - A new or modified `Dockerfile`, `Containerfile`, `docker-compose.yml`, `.dockerignore`, multi-stage build script. - An image-scan output (trivy/grype/snyk container) that needs triaging. - A handoff from `security-review` phase 3 (container in scope) or from `k8s-security` (PodSecurityContext points to an image-level issue). - A supply-chain moment: image needs to be signed, attestation published. Together with `supply-chain`. ### When NOT to use (handoff) - Kubernetes workload spec (PodSecurityContext, NetworkPolicy, RBAC) → `k8s-security`. The image is the ingredient; K8s is the cook. - SBOM format and signing-keys setup → `supply-chain`. This skill calls sigstore; that one explains it. - Vulnerabilities in packages *inside* the image → scanner output goes to `cve-triage` for triage. - Secrets in image layers → `secrets-scanner` on image history. - CI pipeline that runs the build → `cicd-hardening`. - Pure code question that just happens to run in a container → `secure-coding` or the framework skill. ## Approach Six phases. Phases 1–3 are image content, phase