[rennf93]

The Dockerfiles that DockSec flags are fixed: the root one, the ones under examples/ and, in fastapi-guard, the live-smoke one. None installs apt packages any more, uv comes from the official image at an exact tag, every image runs as a numeric non-root USER and has a HEALTHCHECK. docksec.yml now also watches **/Dockerfile, because DockSec runs trivy config over the whole tree and keeps every file named Dockerfile (findings.py:182-185), so a change to a nested file has to trigger the scan.

Closes all open DockSec alerts (rule ids, alert numbers): DS002 (#3, #4), DS026 (#10, #11, #12), DS029 (#5, #6), DL3008 (#7), DL3013 (#8), DL3042 (#9), DL3009 (#13).

Root Dockerfile:

1. The apt block (libsodium23, wget, build-essential, libffi-dev, curl) is gone. I built the image and ran the suite without it and nothing needed it, so there is nothing to pin.
2. pip install uv became COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /uvx /bin/, and I dropped PIP_NO_CACHE_DIR=false, which only configured that pip call.
3. User app (uid 10001) owns /app, USER 10001 comes before uv sync so the venv and /app/data are writable.
4. HEALTHCHECK probes http://127.0.0.1:8000/ with python and counts any HTTP answer as alive. The one-shot test runner would report a meaningless unhealthy state, so compose.yml sets healthcheck: disable: true on the test service.

Nested Dockerfiles:

• examples/simple_app/Dockerfile: apt block dropped, user app (uid 10001), USER 10001, HEALTHCHECK. Run through its own docker-compose.yml: healthy, GET / 200 from the host and from inside the container, uid=10001.
• examples/advanced_app/Dockerfile: numeric uid 10001 for the existing guard user, USER 10001, HEALTHCHECK on /health. I could not run the real app: on master the app already dies at boot (ValueError: return_pattern rule with pattern '404' requires reading the response body, but behavior_scan_response_body is False), I confirmed that by building master's Dockerfile and starting it. I did not touch that. To prove the image mechanics I ran the stack with a stand-in server answering /health: app healthy through the Dockerfile HEALTHCHECK (compose healthcheck reset), uid=10001, GET /health through nginx 200.

Verification (python 3.10, own compose projects, Redis without a host port, one run at a time):

• Test service, master image vs this branch: 212 passed, 27 failed on both, identical list of failing tests. The failures exist on master (the ones I looked at connect to localhost:6379 inside the test container). I did not touch that.
• Example service on this branch: healthy, GET / 200, uid=10001(app). The service command in compose.yml (gunicorn examples.main:app) fails on master and on this branch alike (No module named 'examples.main'), so I started it with gunicorn examples.simple_app.main:app --bind 0.0.0.0:8000 --reload.
• hadolint 2.15.1 (the version the pinned DockSec action installs) on master, root Dockerfile: DL3008, DL3009, DL3015, DL3013, DL3042. On this branch, every Dockerfile in the repo: no output, exit 0.
• trivy 0.74.0 (the version the pinned action installs) config --file-patterns dockerfile:Dockerfile over the repo: 27 successes, 0 failures for every Dockerfile.
• DockSec check on this PR: pass. Analysis on refs/pull/46/merge: results_count 0 and 0 open alerts on that ref.

Not verified: python versions other than 3.10, and the bind-mounted examples (./:/app) on a Linux host, where a host-owned directory is not writable by uid 10001.

[CLAassistant]

All committers have signed the CLA.