fix(ci): stop the Trivy check going red on a missing SARIF configuration

.github/workflows/ci.yml

@@ -627,12 +627,42 @@ jobs:
       # medium or low. The alert set never changed; only the baseline diff was
       # broken. Do not re-derive the old explanation from the severity config.
       #
-      # Deduplicated: harden-gate.yml is now the single code-scanning source
-      # for the filesystem scan. The scan still RUNS here and its full,
-      # all-severity SARIF is kept as a build artifact, so nothing stops being
-      # scanned and no finding becomes invisible — it just stops being uploaded
-      # twice under one tool identity. Do not re-add an upload-sarif step here
-      # without first giving it a distinct SARIF tool name.
+      # CORRECTION (this is the third pass over this block — read it before
+      # changing anything here). Removing this upload did NOT fix the warning.
+      # It only changed WHICH configuration goes missing: the warning now reads
+      # "1 configuration present on refs/heads/master was not found ...
+      # .github/workflows/ci.yml:security-scan", because master's code-scanning
+      # baseline still holds the analysis this step used to produce, and
+      # nothing re-registers it. That baseline entry cannot be aged out from
+      # here and deleting it needs code-scanning admin scope, so the only fix
+      # available in-repo is to produce the configuration again — which is what
+      # this step does.
+      #
+      # The actual root cause was never the duplication. It was the ~6-minute
+      # security.yml container scan sharing one SARIF tool identity with these
+      # ~25-second filesystem scans, so the aggregated check finalised before
+      # the slow configuration reported. That is fixed at its source:
+      # security.yml now retags its SARIF to tool "Trivy Container", giving it
+      # a separate check run. The "Trivy" check is left holding only the two
+      # fast filesystem configurations, which finish within seconds of each
+      # other.
+      #
+      # So this upload is deliberately restored, with NO explicit category, to
+      # reproduce the exact analysis key master's baseline expects
+      # (.github/workflows/ci.yml:security-scan). Do not "deduplicate" it away
+      # again without first confirming that key is gone from the baseline.
+      # ref/sha are deliberately NOT set: upload-sarif's own detection is
+      # correct for both pull_request and push, and hand-rolling it here is
+      # what harden-gate.yml already warns against.
+      - name: Upload Trivy scan results to GitHub Security tab
+        uses: github/codeql-action/upload-sarif@c4dd10e44af883a891fe31ced449bcb4a6728b9b # v3.37.6
+        if: always()
+        continue-on-error: true
+        with:
+          sarif_file: 'trivy-results.sarif'
+          # No explicit category — matches master's baseline analysis key so
+          # the PR comparison check finds this as ci.yml:security-scan.
+
       - name: Upload Trivy scan artifact (all severities)
         if: always()
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2

.github/workflows/security.yml

@@ -203,6 +203,34 @@ jobs:
         env:
           TRIVY_TOKEN: ${{ secrets.TRIVY_TOKEN }}
 
+      # GitHub creates ONE check run per SARIF *tool*, aggregating every
+      # configuration that reports under that tool name. Trivy writes
+      # tool.driver.name = "Trivy" into every SARIF it produces, so this
+      # CONTAINER scan and the two filesystem scans (ci.yml:security-scan,
+      # harden-gate.yml:gate-dependency-scan) all landed in one "Trivy" check.
+      #
+      # That is the bug. This job builds two images first and takes ~6 minutes;
+      # the filesystem scans finish in ~25 SECONDS. The check was therefore
+      # finalised long before this configuration reported, and every run
+      # emitted "Warning: 1 configuration present on refs/heads/master was not
+      # found". With no complete baseline to diff against, code scanning
+      # reported PRE-EXISTING findings as "new alerts" — a red check that no
+      # code change could clear, which is exactly the kind of check people
+      # learn to ignore.
+      #
+      # Renaming the tool gives the container scan its own check run, so a
+      # 6-minute job can no longer race 25-second ones. Nothing stops being
+      # scanned and no finding becomes invisible; the findings simply report
+      # under "Trivy Container" instead of "Trivy".
+      - name: Retag SARIF tool name so the container scan gets its own check
+        if: always()
+        run: |
+          set -euo pipefail
+          [ -f trivy-results.sarif ] || { echo "no SARIF produced; nothing to retag"; exit 0; }
+          jq '.runs[].tool.driver.name = "Trivy Container"' trivy-results.sarif > retagged.sarif
+          mv retagged.sarif trivy-results.sarif
+          echo "tool.driver.name is now: $(jq -r '.runs[0].tool.driver.name' trivy-results.sarif)"
+
       - name: Upload Trivy scan results to GitHub Security tab
         uses: github/codeql-action/upload-sarif@c4dd10e44af883a891fe31ced449bcb4a6728b9b # v3.37.6
         if: always()