postgres image has HIGH/CRITICAL OS-package CVEs (fails codefly ci audit; blocks module-saas-starter#7)

[AntoineToussaint]

Summary

Trivy's container-image scan (run by codefly ci audit) reports HIGH/CRITICAL OS-package vulnerabilities in the published postgres agent image (0.0.104), which is the latest release. This fails the audit gate for every consumer, blocking codefly-dev/module-saas-starter#7 (and #10) at the audit phase after all earlier phases (verify → sync-drift → lint → compile → test) pass.

Because 0.0.104 is already latest, consumers cannot re-pin around it — the image must be rebuilt on a patched base.

Evidence

• CI: https://github.com/codefly-dev/module-saas-starter/actions/runs/30211661016 → CI phase: audit failed: service saas-starter/store: … audit found HIGH or CRITICAL vulnerabilities.
• Reproduced by codefly ci run --phase audit (trivy image scan of the agent runtime image). Findings are OS-package CVEs (Debian/Alpine/RedHat layers per trivy's vulnsrc), i.e. the image base, not consumer code.
• I couldn't enumerate the exact CVE IDs locally (the vendored trivy-db segfaults on arm64/macOS); the maintainer CI (amd64) can list them with trivy image <the-postgres-runtime-image>.

Ask (Done when)

1. trivy image the current postgres runtime image to enumerate the HIGH/CRITICAL findings.
2. Rebuild on an updated/patched base image (bump base tag, apt/apk upgrade the flagged packages) until trivy image --severity HIGH,CRITICAL is clean.
3. Publish a new postgres release (linux_amd64 asset).
4. Then module-saas-starter re-pins postgres to it (I'll handle the re-pin) → audit clears.

Sibling infra-agent audit blockers for the same PR: service-s3, service-vault, service-postgres.

Note: postgres 0.0.105 exists — if its image is already trivy-clean, a re-pin 0.0.104→0.0.105 alone fixes store; otherwise it also needs a rebuild.