Add zizmor to CI and stop double-running the security scan

[ChrisJBurns]

Summary

• We have no static analysis for our own workflows. security-scan.yml runs Grype and govulncheck, which cover our dependencies and our Go code — nothing looks at .github/ itself, so workflow anti-patterns accumulate with no signal. This adds zizmor as a job in the existing security scan.
• Every security scan was running twice per PR. security-scan.yml has its own pull_request trigger and was called as a reusable workflow from run-on-pr.yml, so Grype and govulncheck each ran two full times on every pull request. The same overlap existed on main, between the push: trigger and the call from run-on-main.yml. This keeps exactly one path each and reclaims the duplicate runs.

zizmor is deliberately advisory to start with. It reports 111 findings against the current tree, and gating on that today would just block every PR. --no-exit-codes stops findings failing the job and continue-on-error stops a tool or network failure doing so; both come off once the backlog is worked through, which is inventoried in #6253.

Closes #6250

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe): CI configuration

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

No Go code changes, so the repo's own test tasks aren't meaningful here. What was verified locally:

• actionlint passes clean on both changed files.
• Both files parse as YAML.
• zizmor 1.29.0 runs to completion against .github/ and emits valid SARIF, exit code 0 with --no-exit-codes despite 111 findings.
• Confirmed nothing in run-on-pr.yml had needs: security-scan, so removing that job strands nothing.
• Confirmed run-on-main.yml still calls the workflow and image-build-and-push still gates on it via needs, so the main-branch path is unchanged.
• Confirmed via the branch protection and ruleset APIs that the only required status check is CRD Schema Compatibility — moving which workflow reports the security scan won't leave PRs waiting on a check that never runs.
• pipx is present on the ubuntu-24.04 runner image, so no extra setup action is needed.

The zizmor job itself won't run on this PR — security-scan.yml has to be on the base branch before its pull_request trigger applies. Its first execution will be post-merge, or via workflow_dispatch from this branch if you'd like to see it before approving.

Does this introduce a user-facing change?

No.

Special notes for reviewers

• Findings are never printed. Workflow logs and job summaries are world-readable on a public repo, so the run writes SARIF straight to a file and uploads it to the Security tab, which requires write access to read. Worth preserving if this step is ever edited. Note this isn't secrecy for its own sake — .github/ is public and zizmor is open source, so anyone can already run it against us; it just avoids handing over a pre-baked report.
• The SARIF upload is skipped for fork PRs, whose token is read-only and can't write security events. Those workflows are still scanned on push to main.
• pull_request is intentionally unfiltered by branch. security-scan.yml's own trigger was branches: [main], but run-on-pr.yml fired on all PRs — leaving the filter in place would have quietly narrowed coverage.
• The new upload-sarif line copies the existing pin from the Grype job. That pin's # v4 comment doesn't match a real tag, which zizmor itself flags; left consistent with the existing line rather than fixed inline, and tracked in zizmor findings backlog: pins, expressions and checkout credentials #6253. (Since fixed on this branch — see below.)

Generated with Claude Code

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.75%. Comparing base (63f32f3) to head (18a8cea).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6251      +/-   ##
==========================================
+ Coverage   72.72%   72.75%   +0.03%     
==========================================
  Files         742      742              
  Lines       77281    77299      +18     
==========================================
+ Hits        56199    56238      +39     
+ Misses      17122    17080      -42     
- Partials     3960     3981      +21     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.