Publicações | Codurance

Dependency Vulnerabilities

Written by Mauro Ribeiro | 11 ago. 2026

Dezembro 2021. Sexta-feira à tarde. Pesquisador de segurança chinês publica detalhes de Log4Shell — vulnerability crítica em log4j-core, biblioteca Java de logging. Score CVSS 10.0 (máximo). Exploit trivial: incluir uma string em qualquer log produzido pela aplicação, e o atacante consegue execução remota de código.

A questão que matou times de plantão no mundo todo: "a gente usa log4j?". Resposta honesta para a maioria: ninguém sabia. Direto, raramente. Indireto via dependency tree, em quase todos os projetos Java. Dependency Vulnerability é o sinal que mede esse risco como número, não como adrenalina.

TL;DR

Bibliotecas externas representam 80%+ do código que roda em produção na maioria das aplicações modernas. CVEs em dependências (Log4Shell, Polyfill.io, event-stream) atingem times que não escreveram a vulnerability — mas continuam responsáveis pelo incidente. SCA (Software Composition Analysis) detecta CVEs conhecidos; SBOM documenta o que você usa; supply chain attestations verificam que você usa o que pensa que usa.

Para quem  Tech Leads que receberam alerta do Dependabot às 3h da manhã Leitura  ~6 min Funil  Awareness → Consideration

What this article explores:

  • A semana que parou o mundo — Log4Shell e a pergunta "a gente usa log4j?"
  • Os 3 tipos de risco em uma dependência: vulnerable, outdated, supply chain
  • Como SCA funciona — e onde ele falha (transitive deps, lockfile, reachability)
  • SBOM — o documento que mata pânico (de dias para horas em resposta a CVE)
  • Supply chain — onde a fronteira mudou (typosquatting, post-install, CDN comprometido)
  • Por que IA generativa amplifica o problema de dependência
  • Plano operacional em 4 passos para começar hoje
  • Cinco pontos-chave para levar embora
§ 1 Cena

A semana que parou o mundo

Spring Boot, Apache Kafka, Elasticsearch — todos tinham log4j em algum nível. Times passaram o final de semana auditando árvores de dependência. Empresas que não tinham SBOM levaram dias só para descobrir onde a vulnerability estava ativa. Empresas que tinham SBOM tinham relatório em horas — patch em vez de pânico.

Você não escreveu o bug. Mas continua responsável pelo incidente.

§ 2 Tipologia

Três tipos de risco em uma dependência

Quando você adiciona npm install ou pip install, está aceitando três tipos de risco que se confundem em conversa mas precisam ser distinguidos:

Tipo 01
Vulnerable dependency
A versão que você usa tem CVE conhecido. Solução: bump de versão.
Tipo 02
Outdated dependency
Você está em versão atrás do upstream — sem CVE conhecido ainda, mas com janela maior de exposição. Solução: política de atualização.
Tipo 03
Supply chain risk
A biblioteca em si é o vetor. Typosquatting, abandoned package vendido para mantenedor malicioso, post-install scripts comprometidos. Caso recente: Polyfill.io (2024).

A maioria dos times monitora só o primeiro. O segundo aparece em janela larga (6 meses–2 anos). O terceiro é onde os incidents recentes mais impactantes aconteceram (Polyfill, event-stream, ua-parser-js).

Como SCA funciona — e onde ele falha

Software Composition Analysis (SCA) é a categoria de ferramenta que analisa dependências. Mecânica: lê manifest (package.json, pom.xml, requirements.txt, go.mod), resolve dependency tree completa, cruza cada package@version com bases de CVE (NVD, GitHub Advisory Database), reporta matches.

Onde SCA puro falha:

  • Falsos positivos por uso não-alcançado. Você usa lodash mas não usa o método vulnerável. SCA básico reporta vulnerable; SCA com análise de uso real (reachability) filtra.
  • Versão range ambígua. ^4.17.10 significa qualquer 4.x acima de 4.17.10 — versão real instalada depende do lockfile.
  • Lockfile desatualizado. Dependency tree resolvida hoje pode ser diferente da resolvida há 6 meses.
  • Transitivos profundos. Package A depende de B que depende de C vulnerável. Você ataca C diretamente? Não — bumpa A, espera A bumpar B, espera B bumpar C. Pode levar meses.
§ 3 SBOM

SBOM — o documento que mata pânico

SBOM (Software Bill of Materials) é a lista completa de tudo que está em produção: pacote, versão, hash, licença, mantenedor. Formato padronizado (SPDX, CycloneDX) que ferramentas processam automaticamente.

Por que isso importa virou tema executivo desde 2021: Executive Order 14028 dos EUA exige SBOM para fornecedores federais. UE seguiu com Cyber Resilience Act. Bancos brasileiros incluem em RFP de fornecedores.

— Sem SBOM

"Estamos investigando se Log4Shell nos afeta" — comunicado evasivo, dias para resposta.

+ Com SBOM

"Log4Shell afeta 12 sistemas internos, patches deployados, 0 produtos cliente expostos" — comunicado com fato, em horas.

A diferença: tempo de resposta a CVE público cai de dias para horas. Em incident grave, isso é a diferença entre reputação intacta e manchete.

§ 4 Supply Chain

Onde a fronteira mudou

Os últimos 5 anos mostraram que o vetor de risco mais crescente não está na versão vulnerável — está no caminho que o pacote tomou até você:

  • Typosquatting — atacante publica reacct, lodahs, colors-js esperando typo de instalação
  • Dependency confusion — pacote interno da empresa com mesmo nome de um pacote público; npm/pip resolvem para o público
  • Abandoned package takeover — mantenedor abandona, atacante adquire e injeta payload
  • Post-install scripts — código executado durante npm install, antes mesmo do app rodar
  • CDN comprometido — Polyfill.io, jQuery via CDN, etc.

Defesas contra supply chain são diferentes das defesas contra CVE: SLSA (framework de cadeia de build verificável), Sigstore/Cosign (assinatura criptográfica), lockfiles + integrity hashes, permissions/sandboxing de install (--ignore-scripts), dependency pinning + manual review. Não dá para resolver tudo. Dá para reduzir surface drasticamente.

§ 5 IA Generativa

O impacto das Dependency Vulnerabilities no uso de IA

A IA generativa acelera o problema da dependência. Quando você pede "função para parsear XML", o LLM frequentemente sugere bibliotecas — às vezes obscuras, às vezes desatualizadas, às vezes obsoletas. Pior: a IA não consulta CVE database antes de sugerir.

O que acontece em código gerado por IA sem SCA configurado

  • Bibliotecas obscuras viram dependências. A IA viu uma vez no treinamento, recomenda agora — sem saber que o pacote tem 12 stars no GitHub e mantenedor sumido.
  • Versões desatualizadas em sugestões. Treinamento tem cutoff. LLM sugere lodash@4.17.10 (vulnerable) porque era a versão estável quando o modelo foi treinado.
  • Aumento de superfície sem visibilidade. Cada prompt pode adicionar 1–2 dependências; em 6 meses de uso, isso multiplica a árvore.
  • Typosquatting facilitado. LLM ocasionalmente alucina nome de package — react-router-redux-saga-thunk que não existe, mas alguém pode publicar.
A boa notícia

SCA + dependency review automatizam o que a IA esqueceu. Cada PR gerado por IA que toca package.json ou pom.xml aciona scan automático. Versão vulnerável volta com erro. Pacote desconhecido entra no fluxo de aprovação. A IA escreve mais rápido; o pipeline impede que o que ela escreve introduza CVE conhecido.

§ 6 Operacional
O que fazer agora
Plano operacional · 4 passos
  1. 1 Ative SCA hoje, mesmo que básico. Dependabot é gratuito e cobre os principais ecossistemas. Renovate é open source e mais customizável. Para cobertura mais profunda, Snyk/Mend ou a plataforma SQA da Codurance, que integra Dependency com os outros 2 sinais do pilar Code Security.
  2. 2 Gere SBOM em cada build. GitHub Actions tem ações nativas. CycloneDX e SPDX são os formatos. Versione o SBOM junto com o release.
  3. 3 Política de atualização explícita. "Atualizamos patches de segurança em 7 dias, minor releases em 30 dias, majors em 90 dias com revisão". Sem política, atualização é reação a alarme.
  4. 4 Trate supply chain como camada separada. Lockfile committed, integrity hashes, --ignore-scripts por default em CI, audit de novas dependências antes de adicionar.
Resumo · Pontos-chave
Cinco frases para levar embora.
  • Você é responsável pelo bug que herdou. SCA mede esse risco como número.
  • Três tipos distintos: vulnerable (CVE conhecido), outdated (janela larga), supply chain (vetor muda o jogo).
  • SBOM é o documento que mata pânico — corta tempo de resposta a incident de dias para horas.
  • Supply chain é onde 2020+ mais machucou. Defesas são diferentes (SLSA, sigstore, lockfile, permissions).
  • IA generativa amplifica sugestões de dependência sem visibilidade de CVE — SCA vira pré-condição.
Próximo passo

Você cobriu os três sinais individuais — Hotspots, Vulnerabilities, Dependencies. Cada um tem mecânica própria, mecanismo de detecção próprio, ROI próprio. O último post da série fecha a virada: por que olhar os três juntos importa mais do que olhar um por vez — e como o pilar Code Security do método SQA integra os sinais em diagnóstico operacional.

Post 04 Visão Holística — Pilar Code Security

How Codurance can help

A Codurance acompanha times de engenharia que querem instrumentar a saúde de segurança do código sem virar AppSec. Ajudamos Tech Leads e Staff Engineers a configurar SCA, gerar SBOM em cada release, definir política de atualização defensável e tratar supply chain como camada separada de risco.

Se você quer aplicar essas práticas no seu time, entre em contato hoje.

About the Author

[PARÁGRAFO_BIOGRAFICO_AUTOR]