A sabedoria convencional (embora agora desatualizada) diz que a forma de se manter afastado de vulnerabilidades é manter as dependências de código aberto atualizadas automaticamente. O Dependabot e o Renovate são duas ferramentas populares para fazer precisamente isso. O Dependabot é nativo do GitHub, com o seu dependabot-core em código aberto; o Renovate é totalmente de código aberto e mantido pela Mend.
Qualquer uma das opções constitui uma base razoável, mas fica-se por aí. Ambas as ferramentas conseguem indicar se um pacote tem uma vulnerabilidade conhecida, mas nenhuma diz se a vulnerabilidade é acedida no seu código. E a única resposta de ambas a qualquer problema é atualizar a versão. Unir esses PRs cegamente acarreta o risco de breaking changes, ou até de novas vulnerabilidades introduzidas com a atualização. E, assim que passa a gerir o risco real de dependências, normalmente prefere ter o SCA juntamente com o SAST e a detecção de segredos num único local.
Vamos analisar como se comparam, onde o modelo de atualização automática falha e o que fazer em relação a isso.
TL;DR
Para manter as dependências atualizadas e corrigir CVEs conhecidas, o Dependabot supera o Renovate se o seu código estiver no GitHub e pretender simplicidade sem necessidade de configuração. Se estiver disposto a investir na configuração, o Renovate oferece maior profundidade de configuração, melhor gestão de monorepos e alcance multiplataforma. No entanto, ambos são limitados, pois a atualização reflexiva de pacotes pode causar breaking changes e introduzir vulnerabilidades na sua aplicação. O Aikido Security corrige a versão que já executa, permitindo corrigir uma CVE sem as breaking changes que uma atualização implica, e a sua análise Reachability analysis indica quais as descobertas que são efetivamente exploráveis. O seu feed de malware e ameaças deteta vulnerabilidades às quais ainda não foi atribuída uma CVE. O SCA funciona lado a lado com o SAST, o DAST e a detecção de segredos numa única plataforma de segurança de software.
Eis como o Dependabot, o Renovate e o Aikido Security se comparam em termos de configuração, suporte de plataforma, monorepos, controlo de ruído e gestão de segurança.
O que é o Dependabot?
O Dependabot é a ferramenta de dependências integrada do GitHub. Ativa-a nas definições de um repositório para monitorizar os manifestos e ficheiros de bloqueio, abrindo pull requests para atualizar as dependências para versões mais recentes. Executa atualizações de versão e de segurança com base em vulnerabilidades conhecidas.
Prós:
- Nativo do GitHub, sem necessidade de configurar uma conta ou infraestrutura separada. Uma equipa pode ter PRs funcionais na própria tarde.
- Resolve as atualizações com base nas restrições e no lockfile existentes, executando o próprio gestor de pacotes para que a versão proposta seja instalada sem conflitos com as outras dependências.
- Trata do trabalho mecânico, regenerando manifestos e lockfiles para a nova versão e escrevendo descrições de PR que incluem o changelog da dependência e o histórico de commits.
- As atualizações de segurança correm numa via separada que não precisa de dependabot.yml. Quando a base de dados de avisos do GitHub sinaliza uma dependência vulnerável e os alertas estão ativos, o Dependabot abre automaticamente um PR de correção para a versão corrigida mínima.
- Os novos controlos reduzem o ruído, incluindo atualizações agrupadas que juntam alterações relacionadas num único PR e um período de arrefecimento que retém lançamentos recentes durante um determinado período antes de os propor.
Contras:
O Dependabot é gratuito e está integrado no GitHub, razão pela qual a maioria das equipas começa por aí. No entanto, é apenas uma base de referência e não uma visão completa da segurança das dependências.
- Apenas GitHub. Se parte do seu código estiver no GitLab, Bitbucket ou Azure DevOps, o Dependabot não o consegue cobrir.
- O esquema de configuração é deliberadamente pequeno, o que constitui a vantagem para configurações simples, mas deixa o agrupamento e o agendamento muito genéricos.
- Monorepos implicam listar caminhos manualmente. Declara uma entrada por ecossistema e diretório e, embora um campo de diretórios com suporte a glob reduza alguma repetição, continua a enumerar em vez de obter a descoberta automática de workspaces.
- Sem visão entre repositórios. Os PRs de cada repositório existem isoladamente, sem nada que agregue o que está pendente numa organização.
- Abre um PR para tudo o que seja passível de correção. Com as atualizações de segurança ativas, o Dependabot cria um pull request para cada alerta aberto que tenha uma correção e, para ser seletivo, é necessário desativar a funcionalidade e criar regras de Auto-triage em alternativa. Numa demonstração pública contra o repositório vulnerável AI Goat da Orca, o Dependabot devolveu 48 descobertas para analisar, muitas delas dependências de baixa prioridade que nunca estiveram em produção.
- Faz apenas uma coisa. O Dependabot atualiza dependências e fica-se por aí. Não oferece Reachability analysis nem priorização com base na severidade. Também não existe uma vista do seu código juntamente com o risco da dependência.
- As dependências transitivas são tratadas de forma irregular. Para npm, o Dependabot atualiza uma dependência principal ou remove uma subdependência para puxar uma versão corrigida. Noutros ecossistemas, não atualiza uma dependência indireta se isso também exigir a atualização da principal, pelo que essas vulnerabilidades transitivas não podem ser corrigidas por um PR do Dependabot.
- O único sinal de "isto vai partir o meu código" é uma pontuação de compatibilidade, e esse número resulta de a mesma atualização ter passado na CI noutros repositórios públicos, e não na sua base de código.
- Se a sua equipa parar de fazer merge dos seus PRs, o Dependabot pausa as atualizações até alguém retomar a atividade. Os alertas continuam a ser disparados, mas as correções automáticas não, pelo que uma equipa que confie em "aparecerá um PR quando houver um problema" pode ver isso deixar de acontecer silenciosamente.
Ideal para: Programadores a solo e pequenas equipas focadas exclusivamente no GitHub que pretendem automatização de dependências com uma configuração quase nula.
O que é o Renovate?
O Renovate é uma ferramenta de dependências de código aberto mantida pela Mend. Tal como o Dependabot, monitoriza os seus manifestos e abre pull requests para atualizar dependências, mas funciona no GitHub, GitLab, Bitbucket, Azure DevOps e Gitea, trocando uma configuração mais complexa por um maior controlo sobre o que é atualizado e como as atualizações são agrupadas em PRs.
Prós:
- Totalmente open-source e gratuito para autoalojamento, com um nível de aplicação gratuito alojado pela Mend.
- Uma vasta superfície de configuração. As regras podem abranger dependências por padrão de nome, caminho de ficheiro, tipo de dependência ou tipo de atualização, permitindo definir exatamente como cada classe de atualização se comporta.
- Predefinições partilhadas através do campo extends. Defina uma política de agrupamento e agendamento uma vez e aplique-a a todos os repositórios da organização com uma única linha.
- Deteção nativa de workspaces para monorepos, cobrindo Yarn, npm, pnpm, Lerna e Nx.
- Mais de 25 ecossistemas, além de customManagers que apontam uma regex para qualquer ficheiro com uma string de versão, para que Dockerfiles, configurações de CI e infraestrutura como código sejam atualizados juntamente com as dependências da aplicação.
- Um painel de dependências que oferece uma visão contínua do que está pendente e fixo.
Contras:
- Curva de aprendizagem. A documentação é densa e as equipas passam habitualmente dias a afinar os packageRules antes de o volume de PRs corresponder ao que realmente pretendem.
- Não obtém os seus próprios dados de vulnerabilidade. O Renovate pode criar PRs de correção de segurança assim que ativar o osvVulnerabilityAlerts, mas essa opção é opcional, ainda está marcada como experimental e lê a base de dados externa OSV em vez de curar o seu próprio feed. Por defeito, o Renovate apenas indica que existe uma versão mais recente, nada mais.
- Barulhento por predefinição. De raiz, o Renovate é mais agressivo do que o Dependabot, e a enxurrada de PRs antes de ajustar os packageRules é a primeira impressão mais comum.
- Fraco em dependências transitivas, que é onde o risco realmente reside. Cerca de 95% das vulnerabilidades de open source são encontradas em dependências transitivas e não nos pacotes que escolheu diretamente. Tal como o Dependabot, o Renovate foi criado a pensar nas dependências que declara e o seu próprio maintainer afirmou que não é a ferramenta certa para vulnerabilidades transitivas.
- Esforço de auto-alojamento (self-hosting). A via gratuita de auto-alojamento implica executar e manter o executor do Renovate e gerir a respetiva agendamento.
- Faz apenas uma coisa. O Renovate atualiza dependências e fica-se por aí. Sem reachability, sem classificação de explotabilidade e sem visibilidade do seu código, containers ou cloud em paralelo com o risco das dependências.
Ideal para: Monorepos, organizações multi-plataforma e equipas com repositórios suficientes para que o ruído de PRs justifique o esforço de afinação.
Limitações da atualização automática
Tanto o Dependabot como o Renovate tratam uma versão mais recente como uma versão mais segura. No entanto, "recente" e "segura" divergem com bastante frequência e, quando isso acontece, estas ferramentas empurram-no diretamente para o problema.
A versão mais recente pode ser a comprometida
Um exemplo claro é o xz-utils. Em 2024, um atacante que passou anos a conquistar a confiança dos maintainers introduziu uma backdoor que existia apenas nas versões 5.6.0 e 5.6.1; quem ainda utilizava a linha 5.4.x mais antiga nunca esteve exposto, e a recomendação subsequente da CISA foi fazer downgrade e não upgrade. O mesmo padrão afetou os pacotes chalk e debug comprometidos, distribuídos pelo canal oficial de modo a que todos os pipelines de atualização automática os descarregassem em minutos e ficassem infetados com malware
Por vezes, não existe nenhuma versão corrigida para a qual mudar.
Atualizar automaticamente para uma versão mais recente é inútil quando todas as versões são afetadas por uma vulnerabilidade. Por exemplo, o lodash passou um período de 2026 com vulnerabilidades divulgadas em todas as versões publicadas, incluindo a mais recente. Até que um maintainer lance um patch, nem o Dependabot nem o Renovate o conseguem ajudar.
Quando a correção é finalmente lançada, pode quebrar o seu sistema
Quando o lodash finalmente lançou a sua correção na versão 4.18.0, os builds falharam logo no próprio dia. O patch introduziu uma função interna que nunca tinha sido importada, e uma versão funcional só chegou na 4.18.1. As alterações disruptivas da atualização eram totalmente alheias ao patch de vulnerabilidade. O CVE-2026-48937 do Node representa a mesma armadilha sob outro prisma. A sua correção veio acompanhada de um salto de versão principal que removeu a sinalização de prioridade de HTTP/2, tornando impossível aplicar o patch sem introduzir alterações disruptivas.
Até uma atualização limpa pode quebrar o seu sistema
Uma atualização de rotina pode alterar o comportamento de um pacote ou obrigar a atualizar metade da sua árvore de dependências. Por vezes, trata-se de uma versão major que não instala sem que faça primeiro uma migração. Atualiza um pacote e pode ter de atualizar mais cinco, sendo que um desses cinco acaba por quebrar algo a jusante.
Porque é que o Aikido Security é melhor do que o Dependabot e o Renovate
Tanto o Dependabot como o Renovate associam a correção de que precisa a uma alteração de versão que talvez não queira. O Aikido Security separa ambas as coisas.
Aikido Libraries aplica retroativamente (backports) uma correção CVE à versão exata que já está a executar, permitindo-lhe colmatar a vulnerabilidade sem ter de lidar com as alterações disruptivas que uma atualização acarreta. A Reachability analysis rastreia se o seu código efetivamente acede ao caminho vulnerável, em vez de se limitar a registar a presença de uma versão com falhas.
O AutoFix resolve vulnerabilidades num único pull request em vez de um por pacote. No repositório de IA deliberadamente vulnerável AI Goat da Orca, o Aikido Security reduziu 48 ocorrências para cerca de 10 ao filtrar o que não era explorável ou estava fora do âmbito (como dependências exclusivas de desenvolvimento fora dos limites de conformidade), resolvendo-as de seguida.
No que respeita a malware, o Aikido Safe Chain analisa um pacote no momento da instalação e bloqueia os maliciosos conhecidos antes de chegarem ao seu build. Por trás dessa filtragem está o Aikido Intel, um feed de malware e ameaças que deteta versões comprometidas antes sequer de lhes ser atribuído um CVE.
Em todo o processo, o AutoTriage filtra as ocorrências para o que é real e alcançável, e o AutoFix encarrega-se da remediação; assim, uma fila de PRs transforma-se numa decisão de merge em vez de um atraso acumulado.
A HeyJobs consolidou um conjunto de ferramentas dispersas, que incluía o Dependabot, no Aikido Security em 95 repositórios, 31 registos de containers e nove ambientes cloud, destacando uma priorização mais clara e o AutoFix como os fatores que mudaram o dia a dia. Conforme explicou a equipa, algumas ferramentas assinalam um problema sem indicar o impacto ou como resolvê-lo, e era exatamente isso que procuravam numa alternativa.
E tudo isto numa única plataforma. O mesmo local que aplica backports a uma correção e rastreia a reachability também executa SAST, DAST, container image scanning, IaC e secrets detection.
{{walkthrough}}
