From 179bdd725661ac758c25d73d626cca1705253a23 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 26 Aug 2026 18:23:14 +0000 Subject: [PATCH] fix(ci): stop the Trivy check going red on a missing SARIF configuration MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The "Trivy" check has been failing or going neutral on every PR with: Warning: 1 configuration present on refs/heads/master was not found: .github/workflows/ci.yml:security-scan With no complete baseline to diff against, code scanning then reports PRE-EXISTING findings as "new alerts" — a red check that no code change can clear. It is currently red on #813, #814 and #816, none of which touch anything it scans. Two separate causes, both fixed here. 1. The real one: a 6-minute job sharing a tool identity with 25-second ones. GitHub creates ONE check run per SARIF *tool*, aggregating every configuration reporting under that name. Trivy writes tool.driver.name = "Trivy" into every SARIF, so security.yml's CONTAINER scan — which builds two images first and takes ~6 minutes — landed in the same check as the filesystem scans that finish in ~25 seconds. The check was finalised long before the slow configuration reported. security.yml now retags its SARIF to "Trivy Container" before upload, giving it its own check run. Nothing stops being scanned; the findings report under a different tool name. 2. The one an earlier fix introduced: a baseline entry with nothing producing it. Removing ci.yml's upload (#647) did not fix the warning — it only changed WHICH configuration goes missing. Master's baseline still holds the analysis that step produced, and nothing re-registers it. The entry cannot be aged out from the repo, and deleting it needs code-scanning admin scope (the API returns 403 here), so the only in-repo fix is to produce the configuration again. The upload is restored with NO explicit category, reproducing the exact analysis key the baseline expects. ref/sha are deliberately left to upload-sarif's own detection rather than hand-rolled, per the warning already in harden-gate.yml. Net result: tool "Trivy" holds exactly the two fast filesystem configurations, which finish within seconds of each other, and both are registered on master and on PRs. The slow container scan reports separately as "Trivy Container". No severity filter, ignore rule, or exit code is changed. Nothing is excluded from scanning and no finding is suppressed — this only fixes which check a finding is reported under and whether the diff has a baseline. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_013tMciHkPE8To7V67CsgKKc --- .github/workflows/ci.yml | 42 +++++++++++++++++++++++++++++----- .github/workflows/security.yml | 28 +++++++++++++++++++++++ 2 files changed, 64 insertions(+), 6 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index dfb50fc00..ab1e74df2 100644 --- a/.github/workflows/ci.yml +++ b/.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 diff --git a/.github/workflows/security.yml b/.github/workflows/security.yml index d5fd0ce2d..30f497266 100644 --- a/.github/workflows/security.yml +++ b/.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()