Dependabot agora espera 3 dias antes de abrir PRs de atualização

Resumo rápido

• Desde julho de 2026, o Dependabot aplica por padrão um cooldown de 3 dias antes de abrir PRs de atualização de versão (não afeta atualizações de segurança, que continuam imediatas).
• O GitHub baseou essa decisão na análise de 21 incidentes de supply chain entre 2018 e 2026, em que pacotes maliciosos (como axios, Solana web3.js e ua-parser-js) foram identificados e removidos poucas horas após a publicação.
• O período é configurável por projeto através da chave cooldown no arquivo dependabot.yml, permitindo ajustar ou desativar o comportamento padrão.

O GitHub tornou padrão, em julho de 2026, um período de espera de 3 dias antes de o Dependabot abrir pull requests de atualização de versão de pacotes. Se você usa a ferramenta para manter dependências em dia, é bem provável que já tenha notado PRs chegando alguns dias depois do lançamento de uma nova versão, em vez de no mesmo dia.

Para quem usa o Dependabot diariamente, essa mudança pode parecer contraintuitiva à primeira vista. Afinal, não seria melhor atualizar dependências o mais rápido possível para obter correções de segurança e novos recursos? Segundo o próprio GitHub, a resposta é “depende”, e o motivo tem a ver com como ataques à cadeia de suprimentos de software costumam acontecer.

O que mudou, exatamente

Segundo o changelog oficial do GitHub, publicado em 14 de julho de 2026, o Dependabot passou a aguardar no mínimo 3 dias após o lançamento de uma nova versão de pacote antes de abrir um PR de atualização. O comportamento vale para todos os ecossistemas suportados no github.com e chega também ao GitHub Enterprise Server 3.23.

Um ponto importante: esse cooldown se aplica exclusivamente a atualizações de versão (version updates). Atualizações de segurança, que corrigem vulnerabilidades já conhecidas e catalogadas, continuam sendo abertas imediatamente, sem qualquer atraso.

Por que 3 dias

O número não foi escolhido por convenção. No post oficial que explica o raciocínio por trás da mudança, o GitHub descreve ter revisado 21 incidentes de supply chain amplamente reportados entre 2018 e 2026. Em casos como os pacotes comprometidos do axios, do Solana web3.js, do ua-parser-js e do Ledger Connect Kit, as versões maliciosas foram identificadas e removidas poucas horas depois da publicação.

Ou seja, na maioria dos ataques reais, a janela de exposição perigosa é curta, geralmente medida em horas. O cooldown de 3 dias foi definido para ultrapassar com folga essa janela, sem impor um atraso longo o suficiente para travar a adoção de melhorias legítimas.

Como funciona na prática

O fluxo passou a ser este:

1. Uma nova versão de uma dependência é publicada no registro de pacotes (npm, RubyGems, PyPI, Maven, NuGet, Helm, entre outros).
2. O Dependabot detecta a nova versão disponível.
3. Em vez de abrir um PR imediatamente, a ferramenta aguarda o período de cooldown (3 dias por padrão).
4. Passado esse período, se nada de anormal foi sinalizado pela comunidade, o PR de atualização é criado normalmente.

Para a maioria dos times, isso é transparente no dia a dia: você continua recebendo os PRs de atualização, só que com alguns dias de defasagem em relação ao lançamento da versão. Atualizações de segurança não entram nesse fluxo e seguem chegando sem atraso.

Como configurar o cooldown no seu projeto

O comportamento é controlado pela chave cooldown no arquivo .github/dependabot.yml, documentada na referência de opções do Dependabot. Os principais parâmetros são:

• default-days: período base de cooldown para dependências sem regra específica (3 dias se você não especificar nada).
• semver-major-days, semver-minor-days, semver-patch-days: permitem definir cooldowns diferentes conforme o tipo de atualização semver (só para gerenciadores de pacote que seguem SemVer).
• include e exclude: listas de dependências (com suporte a wildcards) para aplicar ou isentar do cooldown. Em caso de conflito, exclude tem prioridade.

Se seu time trabalha com dependências internas, sob seu próprio controle, faz sentido usar exclude para isentá-las do cooldown, já que o risco de supply chain attack nesse caso é bem menor. Já projetos que lidam com dados sensíveis ou infraestrutura crítica podem preferir aumentar o default-days para além dos 3 dias padrão.

O contexto maior de supply chain security

Essa mudança não existe isolada. Ela reflete uma preocupação crescente com ataques à cadeia de suprimentos de software, nos quais alguém compromete um pacote popular e distribui uma versão maliciosa para milhares de projetos que atualizam automaticamente suas dependências.

O cooldown do Dependabot é uma camada de defesa em profundidade: não impede um ataque por si só, mas dá tempo para que mantenedores, pesquisadores de segurança e a comunidade em geral identifiquem e sinalizem um pacote comprometido antes que ele se espalhe para o seu projeto.

Se você quer se aprofundar em como pensar segurança de forma mais ampla, vale conferir nosso guia completo de cibersegurança para iniciantes, que cobre os princípios básicos por trás de decisões como essa.

Perguntas frequentes

O cooldown afeta atualizações de segurança? Não. O período de espera de 3 dias vale apenas para atualizações de versão comuns. Atualizações de segurança, que corrigem vulnerabilidades conhecidas, continuam sendo abertas imediatamente.

Posso desativar o cooldown? Sim. Basta configurar a chave cooldown no arquivo dependabot.yml do repositório, usando default-days: 0 ou ajustando os parâmetros include/exclude conforme sua necessidade.

Isso vale para todos os gerenciadores de pacote? O cooldown padrão se aplica a todos os ecossistemas suportados pelo Dependabot no github.com, incluindo npm, PyPI, RubyGems, Maven, NuGet e Helm.

Preciso mudar algo no meu workflow para usar essa proteção? Não. O cooldown de 3 dias já é o comportamento padrão desde julho de 2026. Você só precisa mexer na configuração se quiser um período diferente ou isentar dependências específicas.

Conclusão

O cooldown de 3 dias no Dependabot é uma resposta direta a um padrão observado em ataques reais de supply chain: pacotes maliciosos costumam ser detectados poucas horas depois de publicados. Dar esse tempo antes de puxar automaticamente a atualização para o seu projeto reduz a chance de você ser um dos primeiros a instalar uma versão comprometida, sem travar o ritmo normal de manutenção de dependências.

Se seu time gerencia repositórios no GitHub, vale revisar o dependabot.yml de cada projeto para confirmar se o cooldown padrão faz sentido ou se algum ajuste é necessário, principalmente em dependências internas ou críticas. Para quem ainda está organizando o fluxo de versionamento e PRs no dia a dia, nosso guia de Git e GitHub em 5 passos e o texto sobre DevOps como pilar do profissionalismo moderno são bons complementos para entender onde essas práticas de automação se encaixam.