mediumContainers and deployment files

Container Runs as Root

The image starts its process as root.

Why it matters

Root inside a container is still root for everything the container can reach: mounted volumes, the Docker socket if it is mounted, and any kernel weakness. Official base images ship a ready-made unprivileged user, so the fix is one line before the CMD.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

No USER instruction
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci --omit=dev
CMD ["node", "server.js"]

The smallest fix

minimal patch
# node images ship a "node" user; python and others: create one
RUN addgroup --system app && adduser --system --ingroup app app
COPY --chown=app:app . .
USER app
CMD ["node", "server.js"]

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

safe alternative
# Keep root only for the build stage in a multi-stage Dockerfile and
# switch to the unprivileged user in the final stage. Files the app must
# write to (uploads, cache) get chown'd to that user explicitly.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

In [the file] at line [the line number] the final image stage never switches away from root: [the flagged code]. Add an unprivileged user (or use the base image's built-in one such as "node"), chown the files the app needs, and add a USER instruction before CMD/ENTRYPOINT. Make sure the app still starts and can write to the directories it needs.

How to check the fix worked

1. Build the image and run `docker run --rm <image> id`; confirm the uid
   is not 0.
2. Start the app and confirm it serves requests and can write where it
   needs to.

Further reading