Lockfiles de workflow do GitHub Actions entram em prévia pública

O GitHub colocou os lockfiles de dependências de workflow do GitHub Actions em prévia pública em 14 de outubro de 2026. Um novo arquivo, .github/workflows/actions.lock, registra o commit exato por trás de cada action que um workflow usa. Uma execução posterior não pode mais puxar código diferente sem ninguém perceber, uma brecha na cadeia de suprimentos que as equipes tinham de fechar à mão.

O GitHub Actions é o sistema do GitHub para rodar tarefas automatizadas, como testes e deploys, quando o código muda. Essas tarefas são montadas a partir de etapas reutilizáveis chamadas actions. A maioria das actions fica em repositórios de outras pessoas.

O problema que o lockfile resolve

Um workflow normalmente se refere a uma action por uma tag ou um branch, como actions/checkout@v6. Esse nome pode apontar para outro código amanhã. "Tags e branches podem mudar depois que você revisa um workflow, então uma execução posterior pode rodar código diferente", diz o changelog do GitHub. A documentação do GitHub cita uma forma de isso acontecer: a conta de um mantenedor upstream é tomada e uma tag é movida.

Até agora, a principal defesa era fixar cada action no hash completo do commit, chamado de SHA, dentro do arquivo de workflow. A documentação do GitHub diz que isso "não é mais necessário" para repositórios que adotam um lockfile. A fixação manual também deixava de fora as actions que outras actions puxam. O lockfile cobre também essas dependências indiretas, ou transitivas.

Como o actions.lock funciona

Uma ferramenta de linha de comando chamada gh actions-lock grava o arquivo. Ela é uma extensão do gh, o cliente de linha de comando do GitHub. Instale-a com gh extension install github/gh-actions-lock e depois rode gh actions-lock a partir da raiz do repositório. O arquivo começa com um aviso para não editá-lo à mão.

Cada entrada de dependência guarda quatro valores: a referência, o commit resolvido e os IDs numéricos do dono e do repositório. Na hora da execução, o Actions verifica esses IDs. Isso confirma que o repositório por trás do nome ainda é o mesmo que foi travado.

Item	Detalhe
Arquivo	.github/workflows/actions.lock
Ferramenta	gh actions-lock, uma extensão do GitHub CLI
Cobre	Actions diretas, actions transitivas, dependências de workflows reutilizáveis
Planos na prévia	Free, Team, Enterprise Cloud, Enterprise Cloud com residência de dados
Imposição	Uma política "Require lockfile" para administradores de empresa, organização ou repositório
Status	Prévia pública desde 14 de outubro de 2026

As equipes podem incluir workflows um de cada vez ou todos de uma vez, por exemplo com gh actions-lock .github/workflows/ci.yml. Depois disso, toda action que o workflow usa precisa ter uma entrada, e o Actions roda o commit registrado. A ferramenta também reescreve uma referência solta, como @v3, para a versão exata que encontrou, como @v3.1.0.

Quando uma tag upstream muda por um bom motivo, gh actions-lock --relock atualiza a entrada. Se um commit travado desapareceu, por exemplo depois de um force-push, a documentação indica --relock --accept-moved.

Quem tem acesso, e o que o Dependabot faz

O changelog lista quatro planos: Free, Team, Enterprise Cloud e Enterprise Cloud com residência de dados. Uma nota do editor diz que o GitHub mudou essa lista em 14 de outubro. A cobertura inicial, incluindo a do OpenTools, descreveu a prévia como exclusiva do Enterprise Cloud. Nenhuma das fontes menciona o GitHub Enterprise Server, a edição auto-hospedada.

Uma política "Require lockfile", também em prévia, permite que administradores tornem os lockfiles obrigatórios. Ela funciona no nível da empresa, da organização ou do repositório.

O Dependabot é o bot do GitHub para atualizações de dependências. Quando ele atualiza uma action em um workflow já incluído, agora também gera de novo a entrada correspondente do lockfile no mesmo pull request. Ele não inclui workflows novos por conta própria, diz a documentação do GitHub.

O que o lockfile não faz

Um lockfile congela o código, mas não o verifica. O changelog do GitHub orienta as equipes a revisar as dependências antes de travá-las. O desenvolvedor Dave Kurian fez a mesma observação em seu guia na DEV Community. "O lock registra para qual commit uma dependência de workflow é resolvida; ele não avalia se a action é segura."

Os workflows reutilizáveis têm um porém. Um workflow reutilizável é um workflow inteiro que outros workflows chamam. Ele é coberto pelo lockfile do repositório onde é definido, não pelos de quem o chama. Equipes que compartilham workflows a partir de um repositório central devem travar esse repositório primeiro, recomenda a documentação.

O que isso significa para desenvolvedores

• Comece com um workflow. Trave primeiro um workflow de deploy ou de release, já que eles costumam ter as credenciais mais fortes. Acompanhe algumas execuções antes de ampliar.
• Ajuste suas allowlists. Algumas organizações permitem actions por tag, como actions/checkout@v6. A documentação do GitHub diz que essas entradas deixam de corresponder a workflows travados, então troque-as por um curinga ou por um SHA completo.
• Ative primeiro o Dependabot para actions. Ele mantém as entradas do lockfile atualizadas no mesmo pull request, para que os workflows travados não fiquem desatualizados.
• Procure lockfiles desatualizados no CI. A ferramenta pode verificar as entradas sem mudar nenhum arquivo. O OpenTools sugere uma verificação obrigatória que falhe com um lockfile desatualizado, além de revisão do arquivo pelos code owners.
• Segure a política até a cobertura estar pronta. "Ativar a política antes que a cobertura e a automação de atualizações estejam prontas pode bloquear execuções de workflow", alerta o OpenTools. Meça primeiro, depois imponha.
• Trate uma mudança no ID do dono ou do repositório como alarme. A documentação do GitHub diz que esse tipo de mudança deve ser raro. Investigue antes de fazer o merge.