ci: fail the container scan only on findings with a fix

The Debian base carries HIGH advisories the distribution has not fixed
(util-linux, ncurses, systemd, acl, sqlite, perl-base), which no change
here can remove. The blocking image scan now runs with --ignore-unfixed,
so a finding with a published fix still fails the job, and a separate
step before it lists every HIGH and CRITICAL finding without failing.
The scheduled scan's critical gate follows the same rule; its SARIF
report keeps everything.

.github/workflows/security.yml

@@ -245,12 +245,23 @@ jobs:
           rm trivy-install.sh
           trivy --version
 
-      # Blocking since v1.15.20 — a HIGH/CRITICAL finding in the built
-      # image fails the job. For a finding without an upstream fix
-      # (e.g. a base-image CVE Wolfi has not patched yet), add the CVE
-      # id to a `.trivyignore` file at the repository root — Trivy reads
-      # it automatically — one CVE per line, each with a comment naming
-      # the tracking issue and the re-check condition. Never suppress a
-      # finding that has a fixed version available; bump instead.
+      # Every HIGH/CRITICAL finding in the built image, fixed or not, as a
+      # table in the job log. Reporting only: a Debian base carries
+      # advisories the distribution has not fixed yet (or marked as not
+      # worth a fix), and nothing this repository changes can remove those.
+      # The list is here so they stay visible and move to the gate below
+      # the day a fix is published.
+      - name: Trivy container scan (all findings)
+        run: trivy image --format table --severity CRITICAL,HIGH --exit-code 0 healthlog:scan
+
+      # Blocking since v1.15.20 — a HIGH/CRITICAL finding with a published
+      # fix fails the job. `--ignore-unfixed` leaves out only the findings
+      # listed above that have no fixed version yet; a fix that reaches the
+      # Debian archive, the Node image or a dependency turns this red until
+      # it is taken (rebuild, bump the base digest, or bump the package).
+      # `.trivyignore` at the repository root (Trivy reads it automatically)
+      # is for a finding with a fix that cannot reach this image, one CVE
+      # per line with a comment naming what it covers and when to remove
+      # it. Never suppress a finding whose fix applies here; take it.
       - name: Trivy container scan
-        run: trivy image --format table --severity CRITICAL,HIGH --exit-code 1 healthlog:scan
+        run: trivy image --format table --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 healthlog:scan

.github/workflows/trivy.yml

@@ -6,7 +6,7 @@ name: Trivy Scheduled Scan
 #   - `security.yml` → `dependency-audit` runs `pnpm audit --prod` on every
 #     push to `main` and once a day, blocking on HIGH/CRITICAL.
 #   - `security.yml` → `docker-security` builds the image on a push to `main`
-#     and runs `trivy image` against it, blocking on HIGH/CRITICAL.
+#     and runs `trivy image` against it, blocking on HIGH/CRITICAL with a fix.
 #
 # Both are change-triggered, and both answer "is this change safe". Neither
 # answers "is what we shipped last week still safe", because an advisory
@@ -162,3 +162,6 @@ jobs:
           format: table
           severity: "CRITICAL"
           exit-code: "1"
+          # Same rule as the blocking gate in security.yml: a finding with a
+          # published fix fails, one without is in the SARIF report above.
+          ignore-unfixed: true