O GitHub anunciou em 10 de novembro de 2026 que, a partir de 8 de dezembro, vai desligar os alertas do Dependabot na maioria dos repositórios que passaram o último ano sem atividade. Os alertas que já existem são arquivados, sem exclusão, e podem ser restaurados. A justificativa do GitHub é o volume crescente de vulnerabilidades descobertas e de alertas, que a empresa quer manter rápido para os repositórios em desenvolvimento ativo.
Um repositório sem commits pode continuar sustentando um sistema em produção. Um site institucional, uma API interna ou um plugin entregue a um cliente podem passar um ano sem commit e continuar no ar, com as mesmas dependências. Uma vulnerabilidade publicada depois disso nessas dependências deixa de aparecer como alerta.
O que conta como atividade
Pela regra do changelog, só três eventos reiniciam o prazo de um ano:
- push em qualquer branch ou tag;
- criação do repositório;
- ativação dos alertas do Dependabot.
Abrir issue, comentar ou rodar um workflow não aparece na lista. Qualquer push religa os alertas automaticamente, e também é possível religá-los nas configurações do repositório. Nos dois casos, o GitHub restaura os alertas arquivados e o prazo recomeça.
A mudança vale para todos os planos do github.com e para o GitHub Enterprise Cloud com residência de dados. O GitHub Enterprise Server fica de fora.
Quem perde alertas sem perceber
Os casos mais expostos são os de código que terminou de ser desenvolvido e continua rodando: projetos de agência entregues e em manutenção sob demanda, bibliotecas internas estáveis, sites em WordPress ou Laravel que só mudam quando alguém pede. É o momento em que a responsabilidade pelo sistema já costuma ser difusa, tema de quem cuida do sistema depois que o projeto acaba, e agora ele perde também um aviso automático.
Organizações que já aplicam uma configuração de segurança obrigatória com alertas do Dependabot ligados não são afetadas. Também ficam de fora as enterprises cuja política impede os administradores de repositório de ligar ou desligar os alertas.
O que fazer até 8 de dezembro
Primeiro, listar os repositórios sem push há doze meses e separar os que correspondem a algo em produção. Esse cruzamento depende de inventário próprio, porque o GitHub não sabe o que está no ar.
Para os que precisam continuar monitorados, o caminho que o próprio GitHub indica é a exceção formal: uma configuração de segurança da organização, aplicada como obrigatória, com os alertas do Dependabot ligados, ou a política equivalente na enterprise. Fazer um push vazio ou religar os alertas à mão também funciona, mas só por mais um ano, e depende de alguém lembrar. Na minha avaliação, isso só serve como paliativo enquanto a configuração da organização não sai.
Para o que realmente foi abandonado, a mudança pode ser aceitável. Nesse caso, vale arquivar o repositório e registrar que ninguém mais acompanha as dependências daquele código.
O que o anúncio não diz
O texto fala apenas em alertas. Não diz se as atualizações de segurança do Dependabot, que abrem pull requests de correção a partir dos alertas, também param, nem se haverá aviso por e-mail ou na interface antes de cada repositório ser pausado. Também não menciona um filtro na API ou no painel para listar os repositórios atingidos. O "na maioria dos repositórios" do anúncio sugere que pode haver outras exceções além das duas descritas. Até o GitHub detalhar, a premissa segura é que o repositório inativo e sem exceção configurada deixa de receber alertas no dia 8.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
