← ClaudeAtlas

github-actionslisted

Write, review, and harden GitHub Actions workflows against supply-chain attacks, and bump a whole fleet of repos' action pins to the latest versions. Use when writing or editing a workflow YAML (.github/workflows/*.yml, ci.yml), when asked to review a CI workflow or audit GitHub Actions security, when the ci-action-ref-reminder hook fires, or when the user wants to "bump my actions", "update the fleet", "pin actions to SHAs", run zizmor, or close supply-chain / pull_request_target / script-injection / GITHUB_TOKEN-permissions gaps. Pairs with references/security-checklist.md (the full checklist) and dev-env-setup's CI templates.
mickzijdel/dev-hooks · ★ 0 · Code & Development · score 71
Install: claude install-skill mickzijdel/dev-hooks
# github-actions The canonical home for everything GitHub Actions in your repos: the security checklist to apply when writing or reviewing a workflow, and the fleet-wide procedure for bumping action pins to their latest versions. The full checklist lives in [references/security-checklist.md](references/security-checklist.md); read it whenever you touch a workflow. This skill is the security layer over [[dev-env-setup]], which owns the CI *templates* (already hardened to this standard). ## The five that matter most If you do nothing else when writing or reviewing a workflow, get these right: 1. **Pin every `uses:` to a full commit SHA**, not a tag or branch — `owner/repo@<40-hex-sha> # vX.Y.Z`. Tags are mutable; a compromised maintainer can repoint `@v3` to malicious code and every downstream run picks it up silently (tj-actions, Trivy). 2. **Default `GITHUB_TOKEN` to read-only.** Add `permissions: { contents: read }` at the workflow level; grant more only on the specific job that needs it, at the job level. 3. **Never `pull_request_target` (or `workflow_run`) in public repos.** They run with secret access on fork-PR-controlled input. Use plain `pull_request`, or gate on the upstream event. 4. **Never interpolate `${{ github.* }}` into `run:`.** Branch names, PR titles, issue bodies are attacker-controlled. Assign to an `env:` var first, then reference `$VAR` in the shell (Ultralytics, Nx/s1ngularity). Same rule for LLM output and anything written to `