Resposta rápida
A partir de 8 de dezembro de 2026, o GitHub desativará alertas do Dependabot na maioria dos repositórios que não registrarem atividade por um ano. Os alertas existentes serão arquivados, não apagados, e voltam quando o recurso é reativado. A mudança vale para todos os planos no github.com e para o GitHub Enterprise Cloud com data residency; não vale para o GitHub Enterprise Server.
Se um repositório ainda precisa de acompanhamento contínuo, a solução durável é aplicar e impor uma configuração de segurança que mantenha Dependabot alerts habilitado. Um push em qualquer branch ou tag também reativa os alertas e reinicia o prazo de um ano, mas não crie commits vazios apenas para produzir atividade: classifique o repositório como mantido, legado monitorado ou arquivado e aplique a política adequada.
O que o GitHub considera atividade
Para esta regra específica, o GitHub conta três eventos: criação do repositório, push em qualquer branch ou tag e ativação de Dependabot alerts. Cada um inicia ou reinicia o relógio de um ano. Abrir uma issue, comentar, receber uma estrela ou apenas consultar o repositório não aparece na lista oficial e não deve ser tratado como forma de preservar a cobertura.
O anúncio usa a expressão maioria dos repositórios porque há exceções de política. Repositórios com uma configuração de segurança imposta que habilita os alertas não serão pausados. O GitHub também exclui repositórios de enterprises cuja política de Dependabot alerts não permite que administradores do repositório ativem ou desativem o recurso.
Como saber quais repositórios precisam de ação
Comece pelo inventário, não por pushes em massa. Identifique repositórios sem alteração no último ano e separe os que continuam implantados, distribuídos como biblioteca, usados como template, mantidos por obrigação contratual ou regulatória, ou apenas preservados como histórico. Código sem commits recentes ainda pode permanecer em produção e continuar exposto a vulnerabilidades novas nas dependências.
Em organizações, use a visão de segurança e as configurações aplicadas para confirmar onde Dependabot alerts está ativo e quem pode alterar o recurso. Registre a decisão por repositório: manter cobertura com política, reativar porque o desenvolvimento voltou, ou arquivar porque o projeto foi aposentado. O simples fato de não haver commits não prova que o software deixou de ser usado.
- Liste repositórios sem push há quase um ano e confirme proprietário, finalidade e ambiente em que o código ainda roda.
- Verifique se Dependabot alerts está habilitado e se uma configuração de segurança aplicada é imposta.
- Priorize aplicações em produção, pacotes publicados, imagens de contêiner, templates e integrações ainda consumidas.
- Defina para cada repositório uma decisão explícita: manter monitorado, retomar manutenção ou arquivar.
- Atribua responsável e prazo antes de 8 de dezembro de 2026 para os repositórios que precisam permanecer cobertos.
Como manter os alertas ativos sem depender de commits
Crie ou edite uma configuração de segurança da organização ou do enterprise, defina Dependabot alerts como Enabled, aplique-a aos repositórios selecionados e imponha a configuração. A opção de enforcement bloqueia proprietários de repositórios de alterar os recursos definidos pela configuração; campos deixados sem definição não são impostos.
Usar a configuração como padrão para novos repositórios não cobre automaticamente todo o acervo existente. A documentação informa que o padrão é aplicado aos repositórios criados depois da definição e que repositórios transferidos ainda precisam receber uma configuração apropriada. Confirme a aplicação nos repositórios existentes e não apenas a existência da política.
- Abra as configurações de Code Security da organização ou do enterprise.
- Crie ou edite uma configuração personalizada de segurança.
- Em Dependency scanning, defina Dependabot alerts como Enabled.
- Em Policy, escolha a opção de impor a configuração no nível administrativo necessário.
- Salve, aplique aos repositórios que exigem monitoramento contínuo e confirme a associação na interface.
Como reativar depois da pausa
Qualquer push para o repositório reativa automaticamente os alertas. Também é possível ativá-los nas configurações do próprio repositório, quando a política permite. Em ambos os casos, o GitHub restaura os alertas arquivados e reinicia o relógio de um ano; você não precisa recriar cada alerta manualmente.
Depois da reativação, revise a fila restaurada por severidade, alcance e uso em produção. Um alerta antigo pode continuar relevante, ter correção disponível ou afetar uma dependência que o projeto já não utiliza. Reativar o recurso devolve visibilidade, mas não resolve vulnerabilidades nem cria automaticamente um plano de remediação.
- Ative Dependabot alerts nas configurações ou faça um push legítimo quando a manutenção realmente for retomada.
- Confirme que os alertas arquivados reapareceram e que o prazo de inatividade foi reiniciado.
- Revise primeiro alertas críticos e altos presentes em artefatos ou serviços ainda usados.
- Atualize manifestos e lockfiles em uma branch, execute testes e valide o deploy antes do merge.
- Aplique uma configuração imposta se o repositório precisa de cobertura contínua mesmo durante longos períodos sem commits.
Não confunda alertas pausados com updates pausados
A nova regra trata de Dependabot alerts e usa um ano sem criação, push ou ativação. Existe outra automação, anterior, que pode pausar pull requests de Dependabot updates após 90 dias sem interação com pull requests do bot. Nessa regra, ações como mesclar ou fechar um pull request do Dependabot, alterar dependabot.yml, disparar uma atualização manual ou usar comandos @dependabot demonstram atividade.
Os sintomas também diferem. A pausa de updates impede novos pull requests e rebases até haver interação; a mudança de dezembro arquiva alertas em repositórios inativos. Verifique qual banner ou configuração aparece antes de alterar dependabot.yml, porque reativar alertas não corrige necessariamente uma fila de updates pausada, e interagir com um pull request não substitui a política para alertas.
Limitações e próxima ação útil
Este guia foi verificado em 11 de novembro de 2026. O GitHub anunciou a entrada em vigor para 8 de dezembro de 2026, mas não publicou no comunicado uma API específica para listar o relógio individual de cada repositório. A cobertura também não substitui análise de dependências fora do grafo, inventário de software em produção, atualização de pacotes ou revisão de risco.
A próxima ação é exportar hoje a lista de repositórios sem push recente, marcar os que continuam em uso e aplicar uma configuração de segurança imposta aos que precisam de alertas contínuos. Se vários repositórios não exibirem alertas ou configurações ao mesmo tempo, consulte o GitHub Status antes de ampliar permissões ou refazer políticas; se a falha for isolada, revise elegibilidade, configuração aplicada e dependency graph.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Dependabot alerts will pause on inactive repositoriesGitHub Changelog
- Configuring Dependabot alertsGitHub Docs
- Creating a custom security configurationGitHub Docs
- Dependabot update pull requests no longer generatedGitHub Docs
- GitHub StatusGitHub