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

[github-actions]

📋 Description

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 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.

This is the "master fails CI on Trivy every time" problem. Nothing here weakens the scan.

🔄 Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)

🔧 Implementation Details

Two separate causes. Both are 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 that reports under that name. Trivy writes tool.driver.name = "Trivy" into every SARIF it produces, so all three uploads landed in a single check:

Configuration	Kind	Duration
ci.yml:security-scan	filesystem	~23s
harden-gate.yml:gate-dependency-scan	filesystem	~25s
security.yml trivy-container	container — builds 2 images first	~6 min

The check was finalised long before the slow configuration reported. Observed again on #816: the Trivy check completed at 18:16:31 while Container Security Scan was still running.

Fix: security.yml retags its SARIF before upload, so the container scan gets its own check run:

- name: Retag SARIF tool name so the container scan gets its own check
  run: jq '.runs[].tool.driver.name = "Trivy Container"' trivy-results.sarif > retagged.sarif

A 6-minute job can no longer race 25-second ones. Nothing stops being scanned — those findings simply report under Trivy Container.

2. The one an earlier fix introduced — a baseline entry with nothing producing it

Removing ci.yml's upload in #647 did not fix the warning. It only changed which configuration goes missing — the warning previously named harden-gate's config, and now names ci.yml:security-scan. Master's code-scanning baseline still holds the analysis that step produced, and nothing re-registers it.

That entry can't be aged out from the repo, and deleting it needs code-scanning admin scope:

$ gh api "repos/izzywdev/FuzeFront/code-scanning/analyses?ref=refs/heads/master&tool_name=Trivy"
{"message":"Resource not accessible by integration","status":"403"}

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 left to upload-sarif's own detection rather than hand-rolled, per the warning already standing in harden-gate.yml.

Net result

Tool Trivy now 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.

🧪 Testing

• Both workflows parse (yaml.safe_load)
• jq retag verified on a sample SARIF → tool.driver.name reads Trivy Container
• Retag step guards on the SARIF existing, so a scan that produced nothing can't fail the job
• security-events: write confirmed present on both uploading jobs
• Recovered the pre-feat(ci): add gate-toolchain — enforce the Node 24 / React 19 floor #647 step definition from git history to confirm it carried no category, which is what makes the analysis key ci.yml:security-scan

⚠️ On "is this weakening CI?" — no

Deliberately unchanged: severity filters, .trivyignore, ignore-unfixed, and exit-code. Nothing is excluded from scanning and no finding is suppressed. This changes only which check a finding is reported under, and whether the PR diff has a baseline to compare against. The same set of findings is uploaded before and after.

The failure being fixed is the opposite of a real signal: it reports findings that already exist on master as if the PR introduced them. That is what trains people to ignore the check.

Correcting the record

ci.yml carried a comment asserting the duplicate upload was the problem and that removing it was the fix. That was my change, and it was wrong — it moved the symptom rather than removing it. The comment is replaced with what the evidence actually shows, marked as the third pass over that block so the next person doesn't re-derive the disproven explanation.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.