Desative o Dependabot

• O excesso de alertas do Dependabot faz com que os desenvolvedores percam tempo em vez de resolver problemas reais de segurança
• Como no caso ocorrido no ecossistema Go, milhares de PRs e alertas são gerados até para repositórios não afetados, causando confusão
• Usando uma GitHub Action baseada em govulncheck, é possível detectar apenas o código realmente vulnerável e eliminar alertas desnecessários
• Atualizações de dependências são mais seguras e eficientes quando gerenciadas com testes periódicos e validação das versões mais recentes, em vez de PRs automatizados
• Essa abordagem é importante para reduzir a fadiga de alertas (alert fatigue) e aliviar a carga sobre mantenedores de código aberto

---

Problemas do Dependabot

• O Dependabot gera em massa alertas de segurança e PRs automáticos, dificultando que os desenvolvedores identifiquem o que realmente importa
  • Até uma pequena alteração no pacote Go filippo.io/edwards25519 gerou milhares de PRs
  • Alertas de segurança incorretos foram enviados até para repositórios não afetados, como o Wycheproof
• Os alertas incluem pontuações CVSS incorretas e indicadores de compatibilidade baixos, gerando preocupação desnecessária
• Esse excesso de notificações é apontado como um fator que reduz a confiança e a eficiência da resposta de segurança

Alternativa com govulncheck

• O Go Vulnerability Database fornece metadados detalhados por versão, pacote e símbolo
  • Por exemplo, a vulnerabilidade GO-2026-4503 afeta apenas o símbolo Point.MultiScalarMult
• O govulncheck usa análise estática para detectar apenas código vulnerável que realmente pode ser chamado
  • Quando usado junto com go mod why, é possível determinar com precisão se uma dependência indireta tem impacto
  • Mesmo que uma vulnerabilidade exista, não há alerta se o código não chamar aquele símbolo
• A integração é simples pela CLI (govulncheck -json) ou pela API Go (golang.org/x/vuln/scan)

Substituição com GitHub Actions

• Em vez do Dependabot, é possível configurar uma GitHub Action do govulncheck para executar verificações automáticas diárias
  • Os alertas são enviados apenas quando uma vulnerabilidade real é encontrada
  • Como não cria PRs automáticos, os desenvolvedores podem focar em problemas de segurança realmente importantes
• Reduzir alertas incorretos também ajuda a aliviar a fadiga de alertas de segurança (alert fatigue) e melhora a qualidade da resposta
• Isso também resolve o problema de enviar PRs desnecessários para mantenedores de código aberto

Como gerenciar atualizações de dependências

• As dependências devem ser gerenciadas em bloco de acordo com o ciclo de desenvolvimento de cada projeto
  • Testes com as versões mais recentes podem ser executados diariamente, mas a atualização real deve ocorrer apenas quando necessário
  • Em Go, é possível testar com as versões mais recentes usando go get -u -t ./...; em npm, com o comando npm update
• Essa abordagem garante velocidade de resposta a vulnerabilidades de segurança e estabilidade ao mesmo tempo
  • Testar com as versões mais recentes ajuda a detectar cedo problemas de compatibilidade
  • Também evita que dependências com código malicioso sejam implantadas imediatamente
• Com geomys/sandboxed-step, é possível executar de forma isolada com gVisor em um ambiente de CI

Conclusão e contexto de apoio

• A automação do Dependabot frequentemente gera mais ruído (noise) do que segurança real
• Uma abordagem baseada em govulncheck e testes periódicos é uma forma mais precisa e sustentável de gerenciar segurança
• A manutenção de código aberto pelo autor do texto continua graças ao apoio, por meio da organização Geomys, de Ava Labs, Teleport, Tailscale, Sentry e outros
• Esse modelo contribui para a manutenção estável do ecossistema de código aberto e para a melhoria da qualidade de segurança

[GN⁺]

Comentários do Hacker News

• O Dependabot tem algum valor
  Mas uma ferramenta que apenas compara números de versão com um banco de dados de vulnerabilidades não consegue determinar se o código real está exposto àquela vulnerabilidade, então gera muito ruído
  A ferramenta que mais me impressionou recentemente foi o CodeQL. Ele pode ser executado no GitHub Advanced Security e mostra visualmente o caminho completo, rastreando o fluxo real do código até como uma entrada leva a um uso perigoso
  Graças a isso, ele fornece informações que permitem correções práticas e tem poucos falsos positivos. Claro, em linguagens dinâmicas como Python pode haver código que escape da detecção, mas na maioria dos casos é útil o suficiente
  • Antigamente o CodeQL ajudava no projeto, mas recentemente ficou em um nível tão irritante que o time desativou
    Surgiram comentários do tipo adicionar variáveis intermediárias inúteis só para evitar alertas do CodeQL. Parece uma ferramenta sobreajustada aos dados
  • É difícil concordar com a afirmação de que “quase não há falsos positivos”. Pelo teorema de Rice, esse tipo de análise perfeita é impossível
  • Na minha experiência, o CodeQL tem muitos falsos positivos e não há um jeito fácil de executá-lo localmente, o que cria dependência de fornecedor
  • Atualizar a versão de uma dependência não garante melhora na segurança. Uma versão nova também pode trazer novas vulnerabilidades
• Em pacotes NPM aparecem alertas demais de ReDoS. A maioria é de pacotes usados só no código cliente, mas há alertas demais sem relação com o backend. ReDoS no lado do cliente não significa nada para nós
  • Na verdade, acho que DoS não é uma vulnerabilidade de segurança, e sim um problema de disponibilidade. É um dos elementos do CIA da segurança, mas na prática está mais para um problema operacional. Classificar DoS como problema de segurança é só um resquício histórico
  • Eu mantenho o pacote debug, e chegam relatórios de ReDoS completamente ruins demais. Em alguns casos até registraram CVE, a ponto de eu querer largar o ecossistema JS
  • Vejo problema parecido em ferramentas de revisão de código com IA. Mesmo sendo ferramentas executadas localmente com permissões de usuário, elas mandam sanitizar entradas sem necessidade. No fim, é perda de tempo
  • Nós também passamos pelo mesmo problema. Especialmente alertas de ReDoS vindos de Dev dependency geram muito ruído desnecessário
  • ReDoS é um bug do mecanismo de regex, mas motores como o V8 ainda não oferecem por padrão um mecanismo de regex seguro
• O Govulncheck é uma das melhores coisas do ecossistema Go
  Estou usando uma GitHub Action que criei para avisar quando uma chamada vulnerável é adicionada em um PR.
  Junto com auto-merge do Dependabot, é uma combinação boa também para gerenciar codebases em JS
  • O Govulncheck também não é perfeito. Há falsos positivos, e não existe uma forma de excluir uma vulnerabilidade específica pelo número do CVE
• O Dependabot é útil, mas ao mesmo tempo me lembra todos os dias da importância de minimizar dependências
  • Eu também começo o dia lidando com PRs do Dependabot todas as manhãs.
    Se os testes forem bons o suficiente, às vezes você encontra bugs na versão nova, mas nesse processo isso também pode virar contribuição open source. É incômodo, mas ajuda a criar um bom hábito
  • Também concordo. Não tenho tantos projetos, mas o Dependabot é bem aproveitável
• Seria bom se o Dependabot fosse gerenciado em forma de aba dentro do repositório, em vez de por e-mail.
  Notificações por e-mail incomodam, e também não gosto de PRs se acumulando. Queria poder resolver isso só em horários específicos
  • Dá para ajustar a frequência de execução e a quantidade de PRs com a configuração dependabot.yml
    Veja a documentação oficial
  • Também dá para desligar os PRs automáticos e gerar manualmente só quando necessário.
    Também é possível reduzir a quantidade de issues fazendo as correções diretamente
  • Se você usar a extensão Refined GitHub, a visualização padrão fica um pouco mais limpa.
    Pessoalmente, eu recomendo o Renovate. Ele suporta mais linguagens e opções de auto-merge
• A abordagem do govulncheck no Go, que rastreia o caminho real das chamadas, deveria ser o padrão em todos os ecossistemas
  O problema fundamental do Dependabot é tratar gestão de dependências como se fosse um problema de segurança.
  Vulnerabilidades em funções que nunca são chamadas não são problema de segurança, são ruído
  Em Python, tenho a impressão de que pip-audit --desc é melhor que o Dependabot.
  Até surgir uma análise estática perfeita, talvez uma revisão manual trimestral seja até mais segura
  • Mas quando clientes escaneiam o código com esse tipo de ferramenta, eles não acreditam na resposta de que “essa função não é usada”.
    É aqui que surge o descompasso entre segurança real e práticas de segurança
  • A pergunta “se não é usada, por que essa função ainda está no código?” também faz sentido
• Não sei por que a indústria aceitou esses scanners de segurança superficiais
  A maioria dos CVEs não afeta de fato, mas as empresas se esforçam para zerar a contagem de vulnerabilidades em imagens de contêiner
  Além disso, ao atualizar dependências, novos CVEs acabam surgindo. A maioria dos softwares não faz backport de correções
  • Não entendi muito bem como a parte de “não fazem backport” se conecta com a frase anterior
• A vantagem do Dependabot ou do Renovate é que eles funcionam independentemente da linguagem
  Quanto mais repositórios você tiver e quanto mais variadas forem as linguagens, menos realista fica adicionar um workflow de CI perfeito
  Não é perfeito, mas ainda acho muito melhor do que não fazer nada
• Tenho curiosidade sobre de onde vem a pontuação CVSS do Dependabot.
  Ele gera CVEs automaticamente?
  • O CVSS é uma pontuação assumindo o pior caso, então não reflete o risco real.
    O banco de dados de vulnerabilidades do GitHub foca mais em quantidade do que em qualidade, e o Dependabot funciona como um gerador de spam sem inteligência
  • Dá até para questionar se aquele bug é realmente uma vulnerabilidade.
    Se o problema só acontece quando a função é chamada de forma errada, é bem possível que o código já nem funcionasse direito
• Na nossa empresa acontece algo parecido.
  O escaneamento de imagens de contêiner no GCP despeja uma enorme quantidade de alertas de CVE no Vanta, e a maioria ou não pode ser corrigida ou está em caminhos que nem são usados de verdade
  Fico me perguntando se existe alguma ferramenta que faça esse tipo de filtragem baseada em contexto
  • Na nossa empresa usamos o Aikido Code. Ele tenta filtrar com IA o impacto real das vulnerabilidades.
    Os resultados em geral são positivos, mas como a codebase é grande e há muitas dependências, ainda é difícil reduzir a quantidade de CVEs