Hardening GitHub Actions workflows: SHA-pinned actions, least-privilege tokens and untrusted inputs

Goal

A workflow whose behaviour cannot be changed by a third party publishing a new action version, whose token cannot push code or tags unless a job explicitly needs to, and whose scripts cannot be hijacked by a crafted pull request title.

Prerequisites

Write access to the repository's workflow files and settings; a list of every uses: reference in .github/workflows.

Steps

1. Replace every uses: owner/action@v4 with the full 40-character commit SHA and keep the tag as a comment (# v4.2.1). The cited secure-use reference states that pinning to a full-length commit SHA is currently the only way to use an action as an immutable release, and that the SHA should be verified to come from the action's repository rather than a fork. Let a dependency-update bot raise pull requests for new SHAs.
2. Set permissions: contents: read at the top level of every workflow. Per the cited workflow syntax, specifying any permission sets all unspecified ones to none; add packages: write or id-token: write on the individual job that publishes.
3. Treat event data as untrusted: never write ${{ github.event.pull_request.title }} or a branch name inside a run: script. Pass it through an env: variable and reference "$TITLE" in the shell, or move the logic into an action that receives the value as an argument, as the secure-use reference recommends.
4. Avoid checking out pull request code in pull_request_target or workflow_run workflows; the cited reference notes these triggers run with repository write access and secrets even for forks. If a privileged step must read fork content, split it into an unprivileged workflow that uploads an artifact and a privileged one that consumes it without executing it.
5. Put deployment secrets into environments with required reviewers so that a job cannot read them until approved.
6. Enable the organisation or repository policy that requires SHA pinning, so a future edit cannot regress step 1.

Expected result

Each workflow file names exact code for every dependency, grants the token only what one job needs, and contains no shell line that concatenates attacker-controlled strings.

Limits and test basis

SHA pinning freezes bug fixes as well as backdoors; without automated update proposals it decays into outdated actions. Reusable workflows and composite actions bring their own uses: lines that must be pinned inside. Guidance follows the cited GitHub documentation.