container-image-reviewlisted

# Container Image Review Review an image for the four things that actually matter: does it work, how big is it, how fast does it build, and what does it expose. ## Purpose **Use this when:** - Reviewing a Dockerfile in a pull request. - An image is unexpectedly large, or builds slowly. - Preparing an image for production use. - A vulnerability scan reports findings and you need to know which matter. **Do not use this when:** - A container is failing at runtime — use `docker-debugging`. - The question is Kubernetes configuration around the image — use `kubernetes-production-readiness`. **What this skill assumes:** access to the Dockerfile and, ideally, the built image. Reviewing the Dockerfile alone misses what the base image contributes, which is often most of the size and most of the vulnerabilities. ## Operating Procedure 1. **Build it and measure.** Size, layer count, build time. Numbers before opinions. 2. **Review correctness first.** An image that is small and insecure is better than one that does not run. 3. **Check the base image.** It usually determines size, CVE count and libc compatibility. 4. **Check layer ordering** for cache efficiency — the difference between a 10-second and a 10-minute rebuild. 5. **Check what got in that should not**: secrets, build tools, caches, `.git`. 6. **Check the runtime posture**: user, signals, healthcheck, filesystem. 7. **Produce ranked findings** — correctness, then security, then size, then speed. Size and layer