[Gerrrt]

The hardened configuration (read-only root, CapDrop=ALL, no-new-privileges) was proved by one boot of one digest on 2026-09-09. Dependabot moves the digest monthly, and nothing re-ran the boot, so a bump could first fail on trinity after the deploy.

scripts/check_hardened_boot.sh boots the one service from the real compose.yaml with --no-deps, on its networks made internal (no route out, as the original proof was), waits for its own healthcheck, then reads the hardening back from the running container with docker inspect, so a softened compose.yaml fails rather than passing. down -v always runs, from a trap.

The proof is cached on the service's resolved config, its config directory and the script, the way #602 caches --probe's, so a diff that doesn't touch them pulls nothing. A new CI job, "Boot hardened services", runs it beside validate. make check-hardened-boot runs it by hand.

Tried locally on the pinned 2026.9.3 digest: healthy in 12 s warm; a second run hit the proof in about a second; with read_only removed it failed on ReadonlyRootfs=false. The README's "nothing here re-runs the boot" is replaced.

What changed

Why

Blast radius

• No change to network segmentation or firewall rules
• No new port published to a VLAN that could not already reach the service
• No credential added outside secrets/*.sops.yaml

Verification

• make validate passes
• Deployed to the lab and confirmed working
• Docs updated (docs/, service README, or docs/roadmap.md)