GitHub Actions ganha lockfiles para fixar dependências de workflow

O GitHub anunciou em 14 de outubro de 2026, via changelog oficial, a entrada em preview público de lockfiles para dependências de workflow no GitHub Actions. A feature está disponível para GitHub Enterprise Cloud e para GitHub Enterprise Cloud com data residency, e resolve um problema que qualquer time que já sofreu ou temeu um ataque de supply chain em CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → reconhece na hora.

O problema que o lockfile ataca

Um workflow do GitHub Actions normalmente referencia uma ação por tag ou branch, algo como actions/checkout@v4. O detalhe incômodo é que tags e branches podem se mover depois que alguém revisou e aprovou aquele workflow. Se a ação referenciada for comprometida e o mantenedor (ou um invasor) reatribuir a tag v4 para um commit malicioso, o workflow passa a rodar código diferente do que foi auditado, sem que uma única linha do repositório do time tenha mudado.

Esse vetor não é hipotético: episódios de ações populares comprometidas no marketplace do GitHub já mostraram como um workflow aparentemente inalterado pode começar a vazar segredos ou executar payload malicioso de um dia para o outro. O lockfile não substitui a revisão da dependência, o próprio changelog do GitHub é explícito nisso: travar um commit não garante que aquele commit seja seguro, só garante que ele não vai mudar sob os pés do time sem aviso.

Como funciona na prática

A mecânica é a mesma que qualquer dev já conhece de outros ecossistemas: package-lock.json no npm, poetry.lock no Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) →, go.sum no Go. A diferença é que agora o alvo do lock não é uma dependência de aplicação, é a própria orquestração do CI/CD.

O fluxo proposto pelo GitHub funciona assim:

1. Instalar a extensão gh actions-lock para o GitHub CLI, mantida no repositório público gh-actions-lock.
2. Gerar o arquivo .github/workflows/actions.lock, que registra os commits exatos de cada ação usada, incluindo dependências transitivas (uma ação que chama outra ação) e workflows reutilizáveis.
3. Revisar o lockfile gerado e dar commit junto com as mudanças no workflow.
4. A partir daí, o workflow fica "onboardado": o GitHub Actions passa a exigir entrada no lockfile para cada dependência e executa sempre o commit registrado, não importa para onde a tag aponte depois.

A adoção é gradual, workflow por workflow, não é um botão que trava o repositório inteiro de uma vez. Isso importa porque dá para começar pelos pipelines que tocam produção ou publicam artefatos, e deixar os workflows de baixo risco para depois.

Verificação de lockfile desatualizado e política obrigatória

A extensão também oferece um modo de checagem que verifica se o lockfile está sincronizado com o workflow, sem modificar nada, pensado para rodar como um check de CI. Isso evita o cenário clássico de lockfile que ninguém atualiza e que silenciosamente para de refletir a realidade do pipeline.

Além disso, o GitHub liberou em preview a política Require lockfile, que administradores de enterprise, organização ou repositório podem ativar para exigir lockfile em todos os workflows sob aquele escopo. Isso transforma o lockfile de prática opcional de time disciplinado em requisito de compliance, algo que faz diferença em organizações grandes onde nem todo squad vai adotar boas práticas de segurança por conta própria.

Dependabot entra na jogada

Um lockfile que trava commits tem um custo óbvio: ele também trava updates. O GitHub resolveu isso integrando a feature ao Dependabot. Quando o Dependabot abre uma pull request de atualização de versão para uma ação já onboardada, ele regenera a entrada correspondente no lockfile na mesma PR, mantendo a referência do workflow e o commit travado sincronizados sem configuração extra.

Na prática, isso remove o principal atrito de qualquer sistema de lock: o time não precisa escolher entre segurança (ficar travado num commit antigo) e atualização (abrir mão do lock toda vez que uma ação sobe de versão). O Dependabot já era usado para manter ações atualizadas, agora ele também cuida do lockfile.

Quando isso ainda não serve para você

O detalhe que mais importa para o dev brasileiro é a disponibilidade: o preview está restrito a GitHub Enterprise Cloud e GitHub Enterprise Cloud com data residency. Quem está no GitHub.com free, Pro ou Team não tem acesso ainda, só organizações com licença Enterprise Cloud.

Isso significa que boa parte dos times em startups e squads menores vai continuar exposta ao mesmo risco de tag móvel por um tempo, até (se) a feature sair do preview e descer para outros planos. Vale também lembrar que lockfile não é bala de prata: ele imobiliza o commit, não audita o código daquele commit. Times que pulam a revisão da ação antes de travar só estão fixando uma dependência potencialmente ruim com mais confiança do que deveriam ter.

Para quem já mantém pipelines críticos em Enterprise Cloud, o caminho natural é começar pelo onboarding dos workflows que publicam releases ou tocam segredos de produção, ativar a checagem de lockfile desatualizado como gate de CI e, só depois, considerar a política Require lockfile em escopo de organização. Forçar a política antes de qualquer time ter rodado o fluxo manualmente tende a gerar fricção e lockfiles gerados às pressas, sem revisão de verdade, o que anula boa parte do ganho de segurança que a feature promete.

Fonte: GitHub Changelog