ci: adopt zizmor and harden GitHub Actions workflows - #76
Conversation
Adopt zizmor static analysis for the GitHub Actions workflows, both in the
template output (generated projects) and this repo's own CI, adapted to our
stack (prek + Renovate, not pre-commit + Dependabot).
Two-layer setup mirroring the reference approach:
- Blocking gate: `zizmor` prek hook (zizmorcore/zizmor-pre-commit) in
prek.toml.jinja and this repo's prek.toml (scoped to real .yml, skipping
un-parseable *.jinja). Runs in the generated project's CI `hooks` job.
- Dashboard: static zizmor.yml (zizmorcore/zizmor-action, SHA-pinned) uploading
SARIF to the Security tab; non-blocking, least-privilege, self-auditing.
Drive every finding to zero across all scenarios:
- artipacked: persist-credentials: false on read-only checkouts; justified
ignores on the two ghp-import push jobs (gh-pages, release-please deploy-docs).
- excessive-permissions: top-level permissions: {} + per-job grants in ci.yml
and manual.yml.
- template-injection: github.ref_name/repository/workflow moved into env: in
release-please finalize/attach run blocks.
- dangerous-triggers: justified ignores on the six intentional
pull_request_target workflows (never check out or run PR code).
template-ci.yml additionally audits each rendered matrix scenario with the
generated project's own zizmor prek hook, covering the .jinja workflow branches
this repo can't scan directly. Kept regular persona (Renovate already SHA-pins
actions). Docs updated in CLAUDE.md, README.md, and template/README.md.jinja.
|
Warning Review limit reached
Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (16)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
# Conflicts: # README.md # template/.github/workflows/ci.yml.jinja
|
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:
For more information about GitHub Code Scanning, check out the documentation. |
- template-ci.yml: guard the rendered-workflow zizmor audit against a silent no-op — prek exits 0 when a hook matches zero files, so assert at least one workflow was staged before running the gate. - release-please.yml.jinja: correct the env-indirection comment — this workflow triggers only on push/workflow_dispatch, so github.ref_name is not fork-controlled here; reframe as uniform template-injection hygiene rather than a fork threat. - CLAUDE.md: zizmor has no `strict` persona; the stricter tier is `pedantic`.
2 participants
Description
Adopts zizmor static analysis for the GitHub Actions workflows, applied to both the template output (generated projects) and this repo's own CI, adapted to our stack (prek + Renovate, not pre-commit + Dependabot).
Modeled on litestar-org/project-template#39, but tuned to how this template already works.
Two-layer setup
zizmorprek hook (zizmorcore/zizmor-pre-commit) inprek.toml.jinja+ this repo'sprek.tomlhooksjob and locallyzizmor.yml(zizmorcore/zizmor-action, SHA-pinned)This repo's
prek.tomlscopes the hook to\.github/workflows/.*\.ya?ml$so it audits the template's static.ymlworkflows but skips the un-parseable*.jinjatemplates.Findings resolved to zero (across every scenario)
artipacked—persist-credentials: falseon read-only checkouts; justified# zizmor: ignore[artipacked]on the twoghp-import -ppush jobs (gh-pages, release-pleasedeploy-docs) whose push needs the persisted credential.excessive-permissions— top-levelpermissions: {}+ per-job least-privilege grants inci.ymlandmanual.yml.template-injection(incl. 2 High) —github.ref_name/repository/workflowmoved intoenv:in the release-pleasefinalize-release/attach-github-releaserun blocks.dangerous-triggers— justified# zizmor: ignoreon the six intentionalpull_request_targetworkflows (check-pr-title,check-branch-name,check-linked-issues,task-completed-check,label,issue-manager); they never check out or execute PR code and read untrusted input only viaenv:.template-ci.yml
Added a step that audits each rendered matrix scenario with the generated project's own zizmor prek hook — the exact gate a generated repo runs — covering the conditional
.jinjaworkflow branches this repo can't scan directly.Adaptations vs. the reference
helpers:pinGitHubActionDigestsalready SHA-pins everyuses:.Verification
zizmorclean across kitchen-sink, minimal, and litestar/nats renders + this repo.prek run zizmor --all-files, the version generated projects actually run) passes inside rendered kitchen-sink (all workflows) and minimal renders, and in this repo.actionlint,yamllint,yamlfmt, GitHub-Actions schema, and TOML validity all pass.template-ci.ymlstep verified end-to-end against a real render.Notes
zizmor-pre-commit@v1.9.0) and a bareuvx zizmor(1.28.0) disagree onlabel.yml's trigger under regular persona; since the hook gates generated projects,label.ymlgot the ignore and CLAUDE.md notes to verify with the prek hook, not bareuvx zizmor.