Reforçando workflows do GitHub Actions: actions fixadas por SHA, tokens com privilégio mínimo e entradas não confiáveis

Objetivo

Um workflow cujo comportamento não pode ser alterado por um terceiro que publique uma nova versão de uma action, cujo token não consegue enviar código ou tags a menos que um job precise disso explicitamente, e cujos scripts não podem ser sequestrados por um título de pull request manipulado.

Pré-requisitos

Acesso de escrita aos arquivos de workflow e às configurações do repositório; uma lista de todas as referências uses: em .github/workflows.

Passos

1. Substitua cada uses: owner/action@v4 pelo SHA de commit completo de 40 caracteres e mantenha a tag como comentário (# v4.2.1). A referência de uso seguro citada afirma que fixar a um SHA de commit completo é, atualmente, a única forma de usar uma action como uma versão imutável, e que se deve verificar se o SHA vem do repositório da própria action e não de um fork. Deixe um bot de atualização de dependências abrir pull requests para novos SHAs.
2. Defina permissions: contents: read no nível superior de cada workflow. Segundo a sintaxe de workflow citada, ao especificar qualquer permissão, todas as não especificadas passam a none; adicione packages: write ou id-token: write no job específico que faz a publicação.
3. Trate os dados de eventos como não confiáveis: nunca escreva ${{ github.event.pull_request.title }} nem o nome de um branch dentro de um script run:. Passe o valor por uma variável em env: e referencie "$TITLE" no shell, ou mova a lógica para uma action que receba o valor como argumento, como recomenda a referência de uso seguro.
4. Evite fazer checkout do código de pull requests em workflows pull_request_target ou workflow_run; a referência citada observa que esses gatilhos são executados com acesso de escrita ao repositório e com segredos, mesmo para forks. Se um passo privilegiado precisar ler conteúdo de um fork, separe-o em um workflow sem privilégios que envia um artefato e um workflow privilegiado que o consome sem executá-lo.
5. Coloque os segredos de deploy em environments com revisores obrigatórios, para que um job não possa lê-los antes de ser aprovado.
6. Ative a política da organização ou do repositório que exige fixação por SHA, para que uma edição futura não desfaça o passo 1.

Resultado esperado

Cada arquivo de workflow indica o código exato de cada dependência, concede ao token apenas o que um job precisa e não contém nenhuma linha de shell que concatene strings controladas por um atacante.

Limites e base de verificação

A fixação por SHA congela tanto correções de bugs quanto backdoors; sem propostas de atualização automatizadas, ela acaba resultando em actions desatualizadas. Workflows reutilizáveis e composite actions trazem suas próprias linhas uses:, que também precisam ser fixadas internamente. As orientações seguem a documentação do GitHub citada.