ci(security): remediate platform-scan image findings — EOL Debian 11 base, runtime headers, unfixed-OS noise

[mikemcdougall]

Problem / Summary

The compliance scan triage (honua-io/honua-compliance#15, register in honua-compliance PR #29) attributes ~99% of the org's open high-priority scan volume — 3 critical + 583 high Trivy findings — to a single cause in this repo: the platform-scan container image is built on an EOL Debian 11 (bullseye) base, ships linux-libc-dev kernel headers in the runtime stage (~570 findings of pure noise), carries bullseye won't-fix zlib/sqlite criticals, and includes a stale .NET runtime layer.

Why it matters now

These findings dominate the Phase 1 security program's scan register (CCM v4-anchored, honua-compliance#16) and mask any genuinely new critical in dashboards. One three-part fix clears 586 crit/high findings.

Proposed fix (from the triage)

1. Bump the platform-scan image base off EOL Debian 11 to a supported base (current .NET runtime-deps image).
2. Drop linux-libc-dev/build headers from the runtime stage (multi-stage build hygiene).
3. Enable ignore-unfixed for OS packages in the Trivy config so distro won't-fix findings don't page.

Acceptance criteria

• Platform-scan image builds on a supported (non-EOL) base
• Runtime stage contains no kernel/build headers
• Trivy scan of the image reports 0 critical/high actionable findings (unfixed-OS suppressed with rationale in config)
• honua-compliance scan-findings register row updated/closed with the evidence link

Affected repos

honua-server (image + scan config); honua-compliance (register close-out only).

Gate-tier impact

CI/scan workflows only; no runtime code paths, no gate-tier changes.

Release/deploy impact

None to served artifacts unless the platform-scan image is also a shipped runtime image — verify during implementation; if shared, the base bump rides the normal release train.

Non-goals

Weakening or disabling scanning; suppressing findings without an ignore-unfixed-class rationale.