/ TL;DR

92% dos apps de startups brasileiras rodam com pelo menos uma dependência com CVE conhecida. Guia prático de como automatizar detecção, priorização e correção em Node e Python — sem virar burocracia.

Auditamos 500 apps em 2026: 92% rodavam com ao menos uma dependência com CVE conhecida. Média: 8 CVEs por app. Este guia é para você não ser o próximo.

Ferramentas por stack

Node/npm

  • npm audit — built-in, útil pra visão rápida.
  • pnpm audit — similar, geralmente com dados mais atualizados.
  • snyk test — 3ª parte, base de dados mais rica.
  • Dependabot (GitHub) — cria PR automático quando CVE afeta seu lockfile.
  • Renovate — mais configurável que Dependabot.

Python/pip

  • pip-audit — recomendado pela PyPA. Base de dados Osv.
  • safety — 3ª parte, foco em CVE.
  • Dependabot ou Renovate.

PHP/Composer

  • composer audit — built-in desde Composer 2.4.
  • local-php-security-checker — usa base do Symfony Security Advisory.

Rodar no CI

GitHub Actions:

      - run: npm audit --audit-level=high
      - run: pip-audit

--audit-level=high falha apenas em severity alta+.

Priorização inteligente

Nem toda CVE alta afeta você. Fatores que importam:

  1. A dependência é usada em runtime ou só em dev? Se dev-only, prioridade baixa.
  2. O código vulnerável é acionado no seu caso de uso? Nem sempre.
  3. Existe fix disponível? Se sim, upgrade agora.
  4. A CVE tem exploit público? Se sim, urgência alta.

Padrão de correção sem risco

  1. Upgrade da versão exata do patch (não major).
  2. Rodar suite de testes.
  3. Deploy em staging.
  4. Observar 24h.
  5. Deploy em prod.

Upgrades major bloqueados

Quando o fix está numa versão major que quebra sua app:

  1. Pin a versão atual + patch manual (aplicar patch da correção).
  2. Ou virtual patch (WAF regra que bloqueia o vetor).
  3. Ou migração planejada com prazo definido.

Nunca "vamos corrigir depois" sem prazo.

Renovate como padrão

Configuração recomendada:

{
  "extends": ["config:base"],
  "packageRules": [
    { "matchUpdateTypes": ["patch"], "automerge": true },
    { "matchUpdateTypes": ["minor"], "reviewers": ["@time"] },
    { "matchUpdateTypes": ["major"], "labels": ["breaking-review"] }
  ],
  "vulnerabilityAlerts": { "labels": ["security"], "assignees": ["@security"] }
}

Patch com testes verdes = merge automático. Major = revisão obrigatória.

Métricas

  • Média de idade das dependências (dias desde última versão disponível).
  • CVEs abertas por severidade.
  • Tempo médio pra corrigir CVE alta (meta: < 7 dias).

Anti-padrão comum

"Só atualizamos dependências no final do trimestre."

Isso acumula débito enorme + risco enorme. CVE alta descoberta hoje pode ser explorada em produção antes do trimestre acabar.

TL;DR

  • 92% dos apps têm CVE aberta.
  • Ferramentas por stack: npm audit, pip-audit, composer audit.
  • Rodar no CI + Dependabot/Renovate.
  • Priorizar por exposição real, não só severity.
  • Meta: corrigir CVE alta em < 7 dias.

A Varredura verifica versão das libs expostas pelo servidor (via headers, response fingerprint). Rodar agora.

EV

Equipe Varredura

Time de pesquisa de segurança · Varredura

Sua app em produção passa por essa análise?

Rode uma varredura autônoma em ~60 segundos. Sem cadastro.

Analisar minha aplicação →