chore: Harden all GitHub Workflows using Zizmor

[jkowalleck]

Tool

zizmor — https://github.com/zizmorcore/zizmor

GitHub Action

zizmor-action — https://github.com/zizmorcore/zizmor-action

Goal

Harden all GitHub workflows using automated analysis and recommendations.

Implementation idea

• Add zizmor as a dedicated GitHub Actions workflow that analyzes all workflows in .github/workflows/**.
• Run it:
  • on every pull request (only when files under .github/workflows/** changed), and
  • on a weekly schedule (scan the full .github/workflows/** set).
• Triage findings and apply recommended changes to workflows to improve security/compliance.

Triggers (detailed)

• pull_request:
  • paths: [".github/workflows/**"]
  • Runs for PRs targeting the default branch (and/or the repo’s main development branches as applicable).
• schedule:
  • weekly cron (e.g., "0 0 * * 6" # Every Saturday 00:00 UTC)
  • Always scans all workflows under .github/workflows/** (not change-filtered).

Behavior on findings

• If zizmor finds issues in a pull request run, the workflow check must fail (block merge) until findings are addressed.
• Reporting should use GitHub annotations if possible; otherwise fall back to clear text output in logs/job summary.

Output / Reporting

• Preferred: GitHub annotations surfaced directly in the PR checks UI.
• Fallback: simple text output (logs and/or job summary) that clearly lists findings.

Implementation details / constraints

• Workflow file: .github/workflows/zizmor.yml
• Runner: ubuntu-latest
• Permissions: least privilege (default to contents: read, add only what is required)
• Add reasonable timeout-minutes to avoid hanging runs.

Acceptance Criteria

• A zizmor workflow exists in .github/workflows/ and runs on:
  • pull_request events with paths: [".github/workflows/**"], and
  • a weekly schedule.
• PR runs are blocking: the check fails if findings are detected.
• Findings are surfaced via annotations where possible; otherwise via simple text output.

Exit Criteria

• All zizmor findings are addressed by either:
  • fixing them in the same pull request that introduced them, or
  • creating individual follow-up ticket(s)/issue(s) to track and complete the remediation.