Revisão de acessos no GitHub: a automação precisa saber quando ainda não terminou

A GitHub descreveu Evergreen, uma GitHub App que executa revisões trimestrais de acesso e identifica repositórios sem atividade humana para possível arquivamento em uma organização compartilhada.[16] O desenho não apaga repositórios nem seu conteúdo e registra as mudanças, com foco em reversibilidade.[16] A lição para desenvolvedores está menos na periodicidade e mais na forma de representar uma ação incompleta.

O que muda para quem desenvolve

A solução combina um servidor de webhooks em Go, Actions agendadas, issues, propriedades personalizadas e arquivos versionados.[16] Um repositório controlador guarda um JSON por repositório, incluindo snapshot de colaboradores, início da revisão, prazo, responsável e decisão.[16] O histórico Git funciona como trilha de auditoria.[16]

A decisão humana acontece em uma issue, e o webhook verifica se quem a encerrou tem autorização; sem ela, reabre a issue e ignora a decisão.[16] Sem resposta até o prazo, o sistema revoga os acessos do snapshot.[16] Se uma remoção falha, a revisão permanece pendente e uma execução posterior retenta apenas o necessário.[16]

Minha análise é que esse último comportamento deveria ser requisito de qualquer automação administrativa. Concluir o fluxo local não significa concluir todos os efeitos remotos. O estado precisa representar intenção, tentativa e confirmação sem reduzir tudo a sucesso ou erro.

Como aplicar

Comece por inventário e avisos, sem revogar acessos. Defina responsáveis, exceções, prazo mínimo e o significado de silêncio antes de habilitar efeitos reais. Uma política de segurança por padrão precisa ser conhecida por quem será afetado.

Em uma organização de teste, monte um experimento com três colaboradores fictícios e uma revisão limitada. Simule aprovação por pessoa autorizada, encerramento indevido, falta de resposta e falha em uma remoção. Confira se o sistema conserva a decisão correta e distingue quem já teve o acesso removido de quem continua pendente.

Inclua uma execução manual antes do prazo e verifique se ela não antecipa a ação. No caso relatado, há uma carência rígida que nem a execução manual pode encurtar.[16] Essa proteção ajuda a impedir que um atalho operacional anule a regra comunicada aos usuários.

Registre um recibo de cada alteração e teste a recuperação de acesso quando houver engano. O objetivo do piloto é comprovar política e retomada, não apenas produzir uma lista de pessoas.

Cuidados e limites

A implantação descrita começou em simulação e considerou casos como repositórios sem issues e listas vazias de colaboradores.[16] A atividade observada para identificar inatividade é humana, evitando que bots mantenham um repositório artificialmente ativo.[16]

Não copie os critérios sem avaliar o contexto. Um projeto sem commits recentes ainda pode ser essencial. Minha recomendação é separar revisão de acesso, arquivamento e exclusão como decisões distintas, mantendo esta última fora do escopo inicial. Uma automação confiável precisa saber tanto quando agir quanto quando declarar que ainda falta confirmação.

Fonte

[16] Fonte: GitHub Blog. Publicação: 15/10/2026 às 15:00:00.