GitHub Actions: o commit fixado também precisa de revisão
O que foi aprovado se um workflow revisado depois executa outro código? O GitHub anunciou lockfiles em prévia pública em 14 de outubro. Defina quem revisa o commit e quem aprova a próxima atualização.
Confira o alcance
O anúncio corrigido inclui GitHub Enterprise Cloud, Enterprise Cloud com residência de dados, Team e Free. É uma prévia. O repositório oficial exclui GHES e alerta para mudanças antes de 1.0. Registre data e versão da extensão.
Separe tag de aprovação
A extensão gera .github/workflows/actions.lock para commits de actions, dependências transitivas e workflows reutilizáveis dos workflows incorporados. Reduz alterações silenciosas após uma referência mudar, mas não certifica a segurança do código fixado.
Comece com uma mudança revisável
Proposta operacional: escolha um workflow de teste sem segredos de produção ou autoridade de implantação. Liste referências uses, responsáveis e finalidade. Revise workflow e lockfile juntos e relacione a revisão com a execução antes de exigir adoção ampla.
Dê um dono às atualizações
O README documenta gh actions-lock --verify sem escrita. --verify-local verifica estrutura offline e não substitui verificação de confiança. Separe CI e revisão de código; defina responsável, parada e recuperação. Não instalamos extensões para este artigo.
Segundo o anúncio, o Dependabot regenera a entrada correspondente do lockfile no mesmo PR ao atualizar actions incorporadas. O diff gerado também exige revisão. Sugerimos comparar referência, commit, permissões e comunicação externa do novo código.
Reprodutibilidade não é um veredito de segurança. A participação comunitária citada não prova redução de incidentes nem compatibilidade universal. Leia o README atual e atribua revisão, fixação e atualização.
Fontes oficiais
Verificado em 15 de outubro de 2026; propostas operacionais separadas das funções do produto.