Dependency Vulnerabilities

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.

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

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.

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:

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.

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.

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.

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.

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.

Como a Codurance pode ajudar sua empresa

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.