auditing-container-image-build-hardeninglisted

# Auditing container image build hardening: what survives into the shipped image A secret used in a build stage that a multi-stage build discards is not in the shipped image, and a root Dockerfile deployed under a non-root security context does not run as root. So the bug here is not an instruction in isolation; it is what survives into the final image layer and the runtime request that ships with it. This audit reads the build definition and asks, per concern, whether the image that ships runs unprivileged, carries no secret in any layer, pulls only pinned and verified content, and requests no dangerous runtime privilege. The checklist competitors flag the instruction; the finding that survives is the one a later build stage or a deploy-time override does not neutralize. Stay on the image build plane, and hand deploy-time privilege to the Kubernetes skill and cloud resources to the infrastructure skill. ## When to use - You have a Dockerfile or containerfile, or a compose or run config that sets container runtime flags. - An instruction sets the user, copies files, fetches remote content, pins a base, or requests a privilege. - You want to know what survives into the shipped image, not which instruction looks wrong in isolation. ## Scope check Audit only build definitions for images you own or are authorized to assess, and never push or run a built image to test a finding against shared infrastructure, adjudicate on the layers and the config. If you can't name the autho