github-actions

Start every workflow with `permissions: {}` at the top level and widen scopes only per-job. Pin all third-party actions by full commit SHA, bind untrusted `${{ github.event.* }}` data through `env:` variables instead of interpolating into `run:` strings, and use OIDC federation for cloud credentials.

Never interpolate `${{ github.event.* }}` values like PR titles or issue bodies directly into a `run:` string, since GitHub substitutes them before the shell executes. Instead, assign the value to an `env:` variable and reference it as a shell variable like `$TITLE`, which is a safe runtime read.

Pin every third-party action by its full 40-character commit SHA, with a comment noting the resolved tag. Tags are mutable and can be force-pushed by attackers, as demonstrated by the tj-actions/changed-files supply-chain attack. Tools like pinact, Ratchet, and Dependabot automate SHA pinning and updates.

Grant `id-token: write` on the job, then use `aws-actions/configure-aws-credentials` with a `role-to-assume` ARN. On the AWS side, create a federated identity provider trusting token.actions.githubusercontent.com and scope the IAM role trust policy's `sub` claim to a specific repo and environment.

Composite actions reuse a sequence of steps within a single job and cannot define jobs, matrices, or environments. Reusable workflows (`on: workflow_call`) package entire jobs including matrices, concurrency, and environment gates, making them suited for org-wide CI/CD templates. Secrets must be passed explicitly to reusable workflows.

pull_request_target runs in the base repository's context with access to its secrets while the fork's code can be checked out. Checking out the PR head and referencing untrusted context together lets attackers execute code with the base repo's token. Separate privileged steps from untrusted code execution.