github-actions-hardening

Script injection happens when attacker-controlled `${{ }}` expressions like github.event.issue.title are interpolated into run: steps. Pass the value through an env: variable and reference the quoted shell variable instead, so the data is never re-parsed as shell commands.

pull_request_target runs with a read/write token and full secrets access, yet any fork author can trigger it. If the workflow checks out and executes the fork's code, that is remote code execution with a privileged token. Split into an unprivileged pull_request workflow and a privileged workflow_run consumer instead.

Third-party actions should be pinned to a full 40-character commit SHA because tags and branches are mutable and can be repointed to malicious code. Add a trailing comment with the version number and enable Dependabot for the github-actions ecosystem to keep pins updated.

Set a top-level permissions: {} deny-all or contents: read default, then grant only the scopes each job needs, such as pull-requests: write on a commenting job. Missing permissions blocks inherit potentially broad repository defaults, and write-all should always be flagged.

Yes, GitHub Actions supports OIDC to request short-lived cloud tokens instead of storing long-lived keys like AWS_ACCESS_KEY_ID. Grant id-token: write permission, configure the provider action such as aws-actions/configure-aws-credentials, and scope the cloud trust policy to the specific repo and branch.

No, fork pull_request runs are safe by design because GitHub gives them a read-only token and no secrets. The danger arises when maintainers switch to pull_request_target to restore secrets, which then exposes everything to arbitrary contributors.