fix(demo): serve the static demo from a slim base, not the builder

[thedancingdeveloper]

The failure

dev's build workflow has failed on four consecutive pushes — 2d0e3d5, d2c73de, c1fc614, ba6baf1 — always the same job (build, smoke, and publish the static public demo), always at the Trivy step, and never because anything in the tree changed:

libexpat1      CVE-2026-56408  HIGH  fixed  2.5.0-1+deb12u2 → 2.5.0-1+deb12u3
libexpat1-dev

The gate runs --ignore-unfixed, so a CVE with a fix is precisely what it refuses. Every substantive job in that workflow passes; only the demo image is red.

Why those packages are there at all

demo-runtime reused NODE_IMAGE — the builder base. Building the PWA needs a toolchain; serving the built bytes does not. node:22-bookworm derives from buildpack-deps and carries 413 packages, including compilers and -dev headers, behind a server whose complete dependency set is four builtins:

node:fs   node:fs/promises   node:http   node:path

Why not just patch libexpat

Upgrading the package would leave the next advisory against the other ~400 to break dev again — which is exactly what already happened once: the rm -rf /usr/local/lib/node_modules/npm in that stage is the scar from npm's transitive deps tripping the same gate (#454). Treating the surface, not the symptom, is the fix.

The runtime gets its own base: node:22-bookworm-slim, 88 packages, no libexpat, no compilers.

Measured, not assumed

Two images identical but for the base, scanned with the workflow's exact Trivy invocation:

Probe	Base	Trivy exit	Findings
fat	node:22-bookworm	1	2 HIGH — libexpat1, libexpat1-dev
slim	node:22-bookworm-slim	0	none

That reproduces the CI failure locally and demonstrates the fix removes it.

The slim image also serves correctly under the same hardened flags CI uses (--read-only --cap-drop ALL --security-opt no-new-privileges --tmpfs /tmp):

healthz          200
root has #root   true
manifest schema  true   (full-estate-v1)
api status       404  | no server-side API: true

No new plumbing

The mirror workflow discovers bases by reading ARG *IMAGE= lines, and Renovate's registryAliases maps the whole vogt-base prefix — so the new base is mirrored and tracked upstream with no change to either config. Verified by running the workflow's own "no build stage pulls from Docker Hub" check locally.

Test

test_demo_image_branches_from_the_normal_web_build pinned FROM ${NODE_IMAGE} AS demo-runtime, which was incidental to what it was protecting. It now pins the property that matters — a runtime base separate from the builder, and a slim one — and I confirmed both new assertions fail against the old shape before keeping them.

Verification

uv run pytest 1315 passed / 25 skipped / 91% · mypy clean · ruff clean · check_docs.py clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RzFCTnWGff1k4FyX1HQCYM