GitHub Actions ganha lockfiles de workflow em preview público para fixar dependências em commits revisados

Fala aí, beleza? O GitHub acabou de atacar um dos buracos mais chatos da cadeia de suprimentos de CI: a tag que muda de lugar sem ninguém ver 👀

Em 14/10/2026, os lockfiles de dependências de workflows do GitHub Actions entraram em preview público, segundo o changelog oficial do GitHub

Na prática, o workflow passa a executar os commits que você travou, mesmo que uma tag ou branch seja movida depois

O recurso está disponível só no GitHub Enterprise Cloud e no GitHub Enterprise Cloud com residência de dados

E junto veio a política Require lockfile, também em preview público, para administradores exigirem o uso no seu escopo

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Qual problema os lockfiles de workflow resolvem?

Resolve o seguinte: o código que roda no seu CI pode não ser o mesmo código que você revisou

Isso acontece porque tags e branches podem ser movidas depois da revisão do workflow

Então aquele @v4 que estava apontando pra um commit hoje pode apontar pra outro amanhã, e a execução seguinte roda código diferente 😛

Agora pensa no pior cenário: uma action é comprometida

Uma tag ou branch movida pode levar código malicioso pro seu workflow SEM nenhuma alteração no seu repositório

Nenhum diff, nenhum PR, nada pra revisar… é por isso que esse tipo de ataque é tão traiçoeiro

O lockfile muda essa lógica de um jeito simples:

• As referências (tags e branches) continuam no YAML do workflow
• A execução usa o commit exato registrado no lockfile

Se você conhece o package-lock.json do NPM ou o composer.lock, a ideia é bem semelhante: o arquivo de configuração diz a versão que você quer, o lockfile diz exatamente QUAL código vai rodar

Como funciona o lockfile do GitHub Actions?

O lockfile é criado e mantido pela extensão gh actions-lock do GitHub CLI, publicada no repositório público github/gh-actions-lock

A instalação, segundo a documentação de lock de dependências de workflow, é esta:

gh extension install github/gh-actions-lock

Depois, na raiz do repositório, tu roda o comando sem argumentos:

gh actions-lock

Ele varre todos os workflows em .github/workflows/, fixa cada action resolvível em um SHA de commit e grava o lockfile

E se você quiser integrar só um workflow, dá pra passar o caminho de um único arquivo (o nome abaixo é só exemplo):

gh actions-lock .github/workflows/seu-workflow.yml

O arquivo gerado fica em .github/workflows/actions.lock

E o que vai lá dentro? Commits revisáveis de três coisas:

• As actions que o workflow usa
• As dependências transitivas dessas actions
• As dependências de workflows reutilizáveis

A parte das transitivas é importante, porque uma action pode chamar outras por baixo dos panos, e travar só a primeira camada deixaria a porta aberta

Se liga num detalhe: depois que um workflow é integrado, ele PRECISA ter entradas no lockfile para todas as suas dependências, e o GitHub Actions executa os commits registrados

Pra quem quer ir mais fundo, o repositório github/actions-lockfile traz a definição oficial do formato do lockfile e um parser em Go para auditar e verificar os pins 🙂

O que muda para times que usam GitHub Actions no Enterprise Cloud?

Muda bastante coisa, e o impacto depende do seu papel no time

Para quem escreve e mantém workflows:

A adoção é gradual, workflow por workflow, então não precisa travar o repositório inteiro de uma vez

A extensão também consegue verificar se o lockfile está atualizado sem modificar arquivos, inclusive como checagem de CI

Pra rodar localmente, a documentação sugere este comando num hook de pre-commit:

gh actions-lock --verify-local --no-fix

Ele funciona offline, dispensa autenticação, é rápido o bastante pra rodar a cada commit e confirma que toda dependência tem uma entrada no lockfile

Se o seu time roda workflows do GitHub Actions há tempos, esse tipo de checagem no commit evita aquele PR que muda o YAML e esquece de atualizar o lock

E o Dependabot?

Esse é o ponto mais massa da integração 😀

Quando o Dependabot abre uma atualização de versão de uma action num workflow já integrado, ele regenera a entrada correspondente do lockfile no MESMO pull request

Sem configuração adicional, a referência no workflow e o commit travado ficam sincronizados

Para administradores:

A política Require lockfile deixa administradores de enterprise, organização e repositório exigirem que os workflows usem lockfiles no seu escopo

Os detalhes de aplicação estão na página enforce workflow lockfiles do GitHub Docs

Qual o primeiro passo oficial?

O GitHub resume assim: instalar a extensão a partir do repositório público gh-actions-lock, depois revisar e commitar o lockfile gerado e as alterações nos workflows

Repara no "revisar" aí, ele não está ali de enfeite… já já tu entende o porquê

Limitações do preview: o que o lockfile não faz

O lockfile garante consistência, não segurança

Travar uma dependência não diz se ela é segura, e o próprio GitHub orienta revisar as dependências ANTES de travá-las

Ou seja: se tu travar uma action que já está comprometida, o lockfile vai garantir com muito carinho que o código ruim rode sempre igualzinho haha

Outros pontos pra ter no radar:

• Disponibilidade restrita: o preview vale só para GitHub Enterprise Cloud e Enterprise Cloud com residência de dados
• Extensão imatura: a gh-actions-lock está antes da versão 1.0 e em desenvolvimento ativo
• Mudanças sem aviso: o formato do lockfile, as flags dos comandos e o comportamento podem mudar entre releases

Por isso, convém não amarrar scripts de CI em flags específicas sem acompanhar as releases da extensão

Tome cuidado com isso, porque um pipeline que quebra do nada por causa de uma flag renomeada é o tipo de dor de cabeça que ninguém quer numa sexta à tarde 🙂

Próximo passo: como testar os lockfiles e enviar feedback

Se você está no Enterprise Cloud, o caminho mais seguro é começar pequeno:

1. Escolha um workflow isolado e gere o lockfile só pra ele, passando o caminho do arquivo pro gh actions-lock
2. Abra um pull request e revise o actions.lock com calma, conferindo os commits travados antes do merge
3. Adicione a verificação de lockfile desatualizado, no pre-commit com gh actions-lock --verify-local --no-fix e também como checagem de CI

Se você não está no Enterprise Cloud, o recurso ainda não está disponível pra você nesse preview

Achou bug ou tem sugestão? O GitHub recebe feedback na discussão já existente da GitHub Community ou em issues no repositório gh-actions-lock

E vale o registro: o anúncio no changelog do GitHub agradece Andrew Nesbitt, François Proulx, Jesse Houwing e William Woodruff pela colaboração ao longo do último ano

É isso, até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.