Lockfile no GitHub Actions ajuda a travar versões de actions nos workflows

Como as actions do GitHub são buscadas direto do Git, a recomendação antiga era fixar em um SHA completo em vez de uma tag. O motivo é que tags são mutáveis: um atacante pode apontar uma tag antes segura para código malicioso, o clássico ataque à cadeia de suprimentos. O custo era ler workflows cheios de hashes.

O passo a passo do hugovk.dev mostra o caminho novo. Você instala a extensão gh-actions-lock no gh CLI e roda o comando no repositório. O workflow passa a usar tags vX.Y.Z legíveis, e o arquivo .github/workflows/actions.lock registra os commits para os quais cada tag resolve. Você versiona workflows e lockfile juntos. Renovate e Dependabot já suportam lockfiles e atualizam o arquivo nas rotinas periódicas (o autor lembra de usar cooldowns).

O GitHub recomenda verificar o lockfile em CI, para garantir que está atualizado e íntegro, e sugere copiar um verify-lockfile.yml. O autor pôs a verificação no workflow de lint existente, em job próprio, rodando em paralelo no runner leve ubuntu-slim, fixado em v0.4.1 (atualizar isso fica como tarefa futura). Se você alterar ou criar um workflow, precisa relockar com gh actions-lock, e o CI avisa quando faltar. Por fim, o zizmor, linter de segurança para GitHub Actions, só suporta lockfiles a partir da v1.32.0. Versões anteriores ainda mandam fixar por hash. O autor usa zizmor via prek, no .pre-commit-config.yaml.

Em 23 de outubro de 2026, o CEVIU noticiou "Workflow lockfiles do GitHub Actions chegam em public preview", com a extensão do GitHub CLI para gerar os lockfiles e a promessa de fixar actions e dependências transitivas em commits revisados, mantendo tags legíveis. O texto de agora sai do anúncio e vai à prática: geração, atualização automática por Renovate e Dependabot, verificação em CI e a exigência do zizmor v1.32.0 ou superior.

Também contrasta com o que o CEVIU registrou em 24 de agosto de 2026, em "Semgrep Fortalece Segurança em GitHub Actions Após Incidente Crítico na Cadeia de Suprimentos": a Semgrep fez SHA pinning completo em 350 repositórios após o caso tj-actions/changed-files. O lockfile tenta entregar a mesma garantia sem hashes espalhados nos workflows.

Para quem mantém muitos repositórios, a leitura é que o lockfile reduz o atrito do pinning. Revisar um diff com vX.Y.Z é mais fácil do que revisar SHAs, e o commit exato continua registrado. O ponto de atenção é operacional: relockar a cada mudança de workflow, manter o verificador em CI e atualizar o zizmor para não receber alertas desatualizados.