Se você é daqueles que confia no Dependabot para manter as bibliotecas do projeto sempre na versão mais recente, é hora de conhecer um ajuste que pode salvar seu build (e a sua carteira de criptomoedas). A partir de agora, o serviço de automação do GitHub passa a adotar um “cooldown” de, no mínimo, três dias antes de criar pull requests de atualização que não envolvem correções de segurança.
Por que o atraso é, na verdade, um avanço?
Em setembro de 2025, um invasor conseguiu as credenciais de um mantenedor do npm e distribuiu versões contaminadas de pacotes populares como chalk e debug. Foram apenas duas horas no ar, mas suficientes para que ferramentas de atualização instantânea incluíssem o código malicioso em centenas de builds. O golpe reescrevia carteiras de criptomoedas em aplicativos web, redirecionando fundos para o atacante.
Esse é o padrão dos ataques de cadeia de suprimentos: o invasor injeta o malware em um lançamento “0-day”, confia em bots de atualização para espalhá-lo rapidamente e, em poucas horas, o pacote já foi retirado do ar — tarde demais para quem atualizou no primeiro minuto.
Como funciona o novo cooldown do Dependabot?
Agora, para cada atualização que não seja classificada como patch de segurança, o bot:
- Espera três dias completos a partir da publicação no registro (npm, PyPI, Maven, etc.).
- Somente depois abre a PR de bump de versão.
- Permite que o mantenedor ajuste esse intervalo no arquivo
dependabot.ymlusando a chaveupdate_schedule: { interval: "daily", cooldown: "X days" }.
Esse período extra dá tempo para pesquisadores, scanners automáticos e a própria comunidade sinalizarem versões maliciosas antes que o código bata à sua porta.
Três dias: a matemática por trás do número mágico
Levantamentos do GitHub Advisory Database mostram que 18 pacotes npm maliciosos são catalogados, em média, por dia. Na maioria dos casos, as versões problemáticas são derrubadas dentro de algumas horas. Em um estudo com 21 incidentes de alto impacto entre 2018 e 2026 — incluindo axios, Solana web3.js e ua-parser-js —, todas as variantes foram detectadas e removidas em menos de 24 horas. Ou seja, um atraso padrão de 72 horas filtra a enorme maioria desses “tiros rápidos”.
Isso vai atrasar meus releases?
Para dependências críticas de segurança, nada muda: o Dependabot continua alertando imediatamente. Já para atualizações de funcionalidades, a espera de três dias raramente atrapalha o roadmap de um projeto bem organizado — mas oferece um ganho de segurança exponencial. Se, ainda assim, você precisar de mais agilidade, basta reduzir (ou aumentar) o valor de cooldown no YAML.
Imagem: Internet
Camadas de defesa que você ainda precisa
O cooldown é apenas uma barreira contra versões “flash” maliciosas. Ele não protege contra backdoors pensados para ficar meses despercebidos ou contra sabotagem de mantenedores. Para uma postura robusta, combine:
- Lockfiles para pinagem rigorosa de versões.
- Tokens de CI/CD com escopos restritos.
- Desativação de scripts de pós-instalação sempre que possível.
- Revisão manual (ou por scanner) das PRs antes do merge.
O que aconteceria se outras ferramentas adotassem o mesmo modelo?
Projetos que usam soluções como Renovate, Dependable ou Greenkeeper já podem configurar atrasos semelhantes, mas nem todos vêm ativados por padrão. A decisão do GitHub deve pressionar o mercado a adotar atrasos nativos, reforçando todo o ecossistema de open source.
Próximos passos
O cooldown já está ativo por padrão. Se o seu workflow depende de atualizações imediatas, revise o dependabot.yml. Caso contrário, colha os benefícios de segurança “grátis” e concentre-se no que realmente importa: desenvolver funcionalidades, não apagar incêndios causados por pacotes contaminados.
Em um cenário em que ataques à cadeia de suprimentos crescem exponencialmente, esperar 72 horas nunca pareceu tão rápido — e tão inteligente.
Com informações de GitHub Blog
