Chapter 2 of 6 · 5 practices · 3 min · 4-question quiz
Image size and security
What makes an image safe to run: who the process runs as, which exact base you build on, and how you find and fix known vulnerabilities.
Start: Run the container as a non-root user5 practices in this chapter
- 1Run the container as a non-root userBy default a container process runs as root. If an attacker breaks into your app, root inside the container makes escaping or damaging mounted files far easier. Both Docker and the OWASP Docker…
- 2Pin base images by digest for reproducible buildsTags are mutable: the publisher can move
node:24-slimto a new image at any time, so two builds of the same commit can differ. Pinning to a digest (@sha256:...) means every build uses the exact… - 3Scan images for known vulnerabilitiesYour image inherits every CVE in its base and its packages. A scanner compares the packages in the image against vulnerability databases and tells you what to upgrade.
- 4Rebuild images regularly to pick up security patchesAn image is frozen at build time. If you build once and deploy that image for a year, it keeps every vulnerability fixed upstream since then, even though nothing in your code changed.
- 5Never mount the Docker socket into a containerMounting
/var/run/docker.sockgives the container the Docker API, and the OWASP cheat sheet's first rule explains that this is effectively root on the host.
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.