GitHub Actions trava dependências de workflow por commit com lockfiles em disponibilidade geral

O GitHub tornou geralmente disponível, em 28 de outubro de 2026, o recurso de lockfiles para dependências de workflow no GitHub Actions, duas semanas depois de ele entrar em preview pública, segundo reportagem da InfoQ. O recurso está liberado em GitHub Enterprise Cloud, Enterprise Cloud com data residency, Team e Free, e a versão final mantém as mesmas capacidades que já estavam na preview.

A ideia ataca um problema conhecido de quem mantém pipelines no GitHub: uma referência como actions/checkout@v4, ou o nome de uma branch, pode apontar para outro código depois que o workflow foi escrito. Isso significa que uma action comprometida consegue injetar código malicioso numa pipeline sem que ninguém precise tocar no repositório que a usa. Pinar no SHA completo do commit já resolvia parte do problema, mas prejudicava a leitura do YAML e não cobria dependências transitivas, como as puxadas por composite actions.

Como o lockfile muda a execução

O arquivo .github/workflows/actions.lock registra o commit exato de cada dependência, direta ou transitiva, referenciada no workflow. Depois que o lockfile existe, o runner do Actions passa a executar o commit gravado ali, não importa para onde a tag ou a branch citada no YAML tenha se movido desde então. O workflow continua legível, com @v4 ou nome de branch no arquivo, mas quem decide o que roda é o lockfile.

A geração e a manutenção do arquivo ficam por conta da extensão gh actions-lock, hospedada no repositório gh-actions-lock e instalada via GitHub CLI. Depois que um workflow é integrado ao processo, toda dependência dele precisa ter uma entrada correspondente no lockfile. A extensão também tem um modo de verificação que confere se o lockfile está atualizado sem alterar nenhum arquivo, o que permite usá-lo como gate de CI para detectar divergência entre o workflow e o que está travado.

Um ponto prático para quem administra múltiplos repositórios: a adoção é incremental. Dá para integrar workflow por workflow, começando pelos de maior privilégio, sem precisar converter a organização inteira de uma vez.

Dependabot entra no ciclo de atualização

O custo histórico de pinar dependências é o pin ficar velho: a tag avança, recebe correções de segurança, e o commit travado no YAML não acompanha. O GitHub resolveu isso integrando o lockfile ao Dependabot. Quando o Dependabot abre um pull request de atualização de versão para uma action de um workflow já integrado, ele atualiza também a entrada correspondente no lockfile, e as duas mudanças aparecem no mesmo PR, sem configuração adicional.

Para governança, administradores de enterprise, organização ou repositório podem ativar uma política de "Require lockfile", que ajuda a forçar a adoção no escopo escolhido. Isso dá a quem cuida de segurança uma forma de garantir que pipelines sensíveis, como as de release, não fiquem sem o controle mesmo que times individuais não priorizem a migração.

O que o lockfile não resolve

O próprio anúncio do GitHub é direto sobre o limite do mecanismo: um lockfile garante que a execução use o commit que foi travado, mas não garante que esse commit seja seguro. A recomendação é revisar a dependência antes de travá-la. Na prática, isso desloca o ponto de controle: o pull request do Dependabot vira o momento em que alguém precisa olhar o que está sendo aceito.

Em resumo: times que configuram merge automático para PRs do Dependabot em workflows com lockfile levam qualquer mudança maliciosa direto para dentro do arquivo travado, porque a automação remove exatamente a revisão que o recurso pressupõe. O lockfile reduz a superfície de ataque por tag flutuante, mas não substitui revisão humana ou automatizada do conteúdo da dependência.

Parte de um endurecimento maior do Actions

A GA dos lockfiles não é um recurso isolado. Um changelog publicado em 2 de novembro de 2026 anunciou que pull_request_target será bloqueado por padrão a partir de 2 de dezembro de 2026, outra mudança voltada a limitar como código não confiável chega a contextos privilegiados de workflow. Para quem já lida com segurança de pipeline, as duas mudanças compõem o mesmo movimento: fechar brechas de execução de código de origem não verificada dentro do Actions.

Como as outras plataformas de CI resolvem o mesmo problema

Nenhum concorrente direto anunciou um recurso nativo equivalente ao lockfile do GitHub até agora. Cada plataforma trata o problema de um jeito diferente:

No GitLab, depois dos incidentes de supply chain de março de 2026, a orientação oficial passou a recomendar pin manual em SHA para includes e components, e pin de imagens por digest; as políticas de execução de pipeline introduzidas depois focam em bloquear padrões de ataque conhecidos, não em criar um manifesto de dependências. No Azure Pipelines, a orientação Zero Trust da Microsoft segue a mesma linha de pin manual em SHA, somada à recomendação de restringir extensões do Marketplace. O CircleCI foge do modelo de commit: orbs usam um registro central com versionamento semântico mantido imutável.

Times nessas plataformas costumam recorrer a ferramentas cross-platform, como o pinner para travar tags em SHA com verificação em CI, ou scanners como o ActionSieve para sinalizar referências não pinadas. Essas ferramentas travam a referência escrita no arquivo de pipeline, mas não resolvem a dependência transitiva, que é exatamente a lacuna que o design de lockfile do GitHub ataca. Como no recurso do GitHub, nenhuma delas julga se a dependência pinada é confiável: a revisão continua sendo o controle que importa.

O que muda para quem mantém CI/CD no Brasil

Para equipes que já usam GitHub Actions em produção, o recurso chega sem custo de licença extra nos planos citados, inclusive Free, o que remove a desculpa de orçamento para não adotar pin de dependência em pipelines de deploy. O ponto de entrada sugerido pela reportagem da InfoQ é começar pelos workflows de maior privilégio, como os de release ou deployment, adicionar a checagem de desatualização do lockfile como gate de CI, e confirmar que os PRs combinados do Dependabot encaixam no processo de revisão já existente antes de ativar a política em nível de enterprise.

Vale reler a reportagem da InfoQ antes de rodar a extensão em produção, porque a configuração de verificação como gate obrigatório muda o comportamento de PRs que hoje passam sem fricção. Para quem revisa segurança de pipeline em squads pequenos, o ganho prático imediato é reduzir a dependência de disciplina manual de pin em SHA, um hábito que raramente sobrevive à pressão de prazo.

Fonte

GitHub Actions Lockfiles Reach GA to Secure Workflow Dependencies - InfoQ

Fonte: InfoQ