De 280 para 581 vulnerabilidades por codebase em um único ano. Esse é o número central do relatório OSSRA 2026, publicado pela Black Duck em fevereiro com base na auditoria de 947 codebases comerciais em 17 indústrias. O salto de 107% não é gradual, não é incremental. É o tipo de curva que faz equipes de segurança perderem o sono.

O que torna esse dado mais pesado é o contexto: 98% das codebases auditadas contêm componentes open-source. Ou seja, não estamos falando de um problema isolado. Estamos falando do software que você está rodando agora.

O que o OSSRA 2026 encontrou

O Open Source Security and Risk Analysis é um relatório anual que a Black Duck, empresa especializada em análise de composição de software (SCA), publica com base em auditorias de codebases comerciais de seus clientes. A edição 2026 analisou 947 projetos e os números são desconfortáveis.

Dos codebases auditados, 87% continham pelo menos uma vulnerabilidade conhecida. Desses, 78% tinham vulnerabilidades de alto risco e 44% tinham pelo menos uma falha crítica com potencial de execução remota de código ou vazamento de dados. Não são vulnerabilidades teóricas. São CVEs com exploits conhecidos rodando em produção.

O volume de componentes open-source por projeto cresceu 30% em relação ao ano anterior. O número de arquivos por codebase cresceu 74%. Mais código, mais dependências, mais superfície exposta. E só 7% dos componentes estão na versão mais recente. O resto é dívida técnica acumulada.

Um dado que me pega: 93% dos codebases contêm componentes inativos há mais de dois anos. São bibliotecas que ninguém mantém, ninguém atualiza, mas que continuam lá, executando em produção como se fossem confiáveis.

Vale notar que parte desse aumento reflete mudanças no processo de divulgação. Em 2024, o time do Linux Kernel tornou-se CVE Numbering Authority, resultando em mais de 5.000 CVEs de kernel divulgados durante o período auditado. Mais vulnerabilidades catalogadas nem sempre significa mais código vulnerável — pode significar melhor visibilidade sobre vulnerabilidades que já existiam.

A superfície de ataque está crescendo mais rápido que sua equipe

O OSSRA aponta que 85% das organizações usam assistentes de código com IA. Ao mesmo tempo, 76% das empresas que proíbem essas ferramentas relatam que desenvolvedores as usam mesmo assim. O resultado é mais código sendo gerado, mais rápido, com menos revisão.

Isso alimenta diretamente o problema de licenciamento. A taxa de conflitos de licença atingiu 68% dos codebases auditados, contra 56% no ano anterior. É o maior salto em um único ano na história do relatório. Modelos de IA podem reproduzir trechos de código sob licenças restritivas como GPL e AGPL sem que ninguém perceba. Apenas 54% das organizações avaliam código gerado por IA quanto a riscos de propriedade intelectual.

Mas segurança é o problema mais imediato. A equação é simples: mais componentes, mais arquivos, mais código gerado automaticamente, mesma equipe de segurança. A superfície de ataque cresce aceleradamente enquanto a capacidade de auditoria cresce linearmente. Em algum ponto, a conta não fecha.

Supply chain: o vetor que ninguém vê chegar

O OSSRA registrou que 65% das organizações sofreram um ataque à supply chain de software no último ano. Mas os números do ecossistema npm contam uma história ainda mais preocupante.

Em setembro de 2025, o Shai-Hulud se tornou o primeiro malware autorreplicante detectado no npm. Em questão de dias, comprometeu mais de 500 pacotes, propagando-se autonomamente entre registros e máquinas de desenvolvedores. Não precisou de interação humana após o ponto inicial de infecção.

Em agosto de 2025, a campanha s1ngularity comprometeu pacotes do Nx e extraiu 2.349 credenciais de 1.079 sistemas de desenvolvedores. O ataque durou cerca de quatro horas, mas o estrago foi massivo: tokens do GitHub, chaves da AWS, credenciais de OpenAI e Anthropic, tudo exfiltrado via scripts de pós-instalação que executam automaticamente quando você roda npm install.

# Isso executa scripts arbitrários definidos no package.json
# do pacote instalado, antes de você escrever uma única linha
npm install pacote-comprometido

O grupo Lazarus foi identificado com mais de 800 pacotes maliciosos no npm. O IndonesianFoods publicou 150.000 pacotes de spam no npm em poucos dias, poluindo o registro em uma campanha de tea token farming. São números de operação industrial, não de hackers amadores.

E em janeiro de 2026, pesquisadores da Koi divulgaram o PackageGate: seis vulnerabilidades zero-day afetando npm, pnpm, vlt e Bun. Essas falhas comprometem exatamente as defesas que a indústria recomendou após o Shai-Hulud: lockfiles e desabilitação de lifecycle scripts. O ciclo se repete mais rápido do que as defesas conseguem acompanhar.

SBOM e SLSA na prática

SBOM (Software Bill of Materials) e SLSA (Supply-chain Levels for Software Artifacts) são duas iniciativas que tentam trazer ordem a esse cenário. Ambas têm limitações reais, mas também oferecem benefícios concretos.

Um SBOM é, essencialmente, uma lista de todos os componentes de software presentes em uma aplicação, com versões, licenças e origens. A ideia é simples: você não pode proteger o que não conhece.

O cenário regulatório está fragmentado. A União Europeia, através do Cyber Resilience Act, exige que fabricantes de software criem e mantenham SBOMs em formato padronizado. Nos Estados Unidos, o caminho foi diferente: em janeiro de 2026, o OMB revogou a obrigatoriedade de SBOMs, substituindo por uma abordagem baseada em risco. Agências federais ainda podem exigir SBOMs, mas não há mais mandato universal.

A adoção encontra barreiras práticas. Uma pesquisa apontou que 69% dos respondentes citam falta de conhecimento como o principal obstáculo para adotar SBOMs. Para empresas menores, o custo de gerar e manter SBOMs atualizados compete com outras prioridades.

O SLSA ataca o problema de outra forma. Em vez de listar componentes, ele define níveis de garantia para o processo de build. São quatro níveis (0 a 3), cada um adicionando controles:

  • SLSA 0: sem garantias
  • SLSA 1: processo de build documentado, proveniência básica
  • SLSA 2: build em serviço hospedado (CI/CD), proveniência assinada
  • SLSA 3: build isolado, proveniência não-falsificável

O npm já suporta proveniência SLSA Build Level 2 via GitHub Actions. Quando um mantenedor publica com --provenance, o CLI gera uma atestação assinada via Sigstore vinculando o pacote ao repositório de origem e ao commit exato.

# Publicar com proveniência (requer GitHub Actions ou GitLab CI)
npm publish --provenance

# Verificar assinaturas dos pacotes instalados
npm audit signatures

Isso não resolve tudo. Um mantenedor com conta comprometida ainda pode publicar um pacote malicioso com proveniência válida. Mas reduz significativamente o espaço de atuação de ataques como typosquatting e hijacking de pacotes abandonados.

Defesas concretas para seu projeto

Não existe bala de prata, mas existe um conjunto de práticas que reduz a exposição de forma mensurável.

A primeira linha de defesa é o lockfile. Use npm ci no CI/CD, nunca npm install. O npm ci instala exatamente o que está no lockfile, sem resolver novas versões. Combine isso com versões exatas no package.json, removendo ^ e ~ de dependências críticas. Ranges flutuantes como ^1.2.3 podem trazer uma versão 1.3.0 que você nunca testou.

# No pipeline de CI, garante reprodutibilidade
npm ci --ignore-scripts
{
  "dependencies": {
    "express": "5.2.1",
    "zod": "3.24.2"
  }
}

A segunda camada é bloquear lifecycle scripts. Scripts de preinstall e postinstall são o principal vetor de execução de malware no npm. Adicione ignore-scripts=true no .npmrc do projeto e depois habilite seletivamente os pacotes que precisam compilar binários nativos. O npm não suporta allowlists nativas para scripts, mas o @lavamoat/allow-scripts resolve isso:

# .npmrc do projeto
ignore-scripts=true

No package.json, configure quais pacotes podem executar scripts:

{
  "lavamoat": {
    "allowScripts": {
      "esbuild": true,
      "sharp": true
    }
  }
}

Pesquisadores de segurança recomendam também aguardar 7 a 14 dias após uma nova release antes de atualizar. A maioria dos pacotes maliciosos é detectada e removida nessa janela. Além do tempo de espera, rode auditorias regulares no CI para pegar o que escapar:

# Verificar vulnerabilidades conhecidas
npm audit --omit=dev

# Verificar assinaturas e proveniência
npm audit signatures

Por fim, gere e mantenha um SBOM. Mesmo sem obrigatoriedade regulatória, saber o que está dentro do seu build é o primeiro passo para qualquer resposta a incidentes.

# Gerar SBOM no formato CycloneDX
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

Conclusão

O OSSRA 2026 não traz notícias novas no sentido conceitual. A comunidade de segurança alerta sobre riscos em dependências open-source há anos. O que muda é a escala. De 280 para 581 vulnerabilidades por codebase não é uma tendência. É uma ruptura.

A combinação de geração de código por IA, expansão acelerada de dependências e ataques industrializados à supply chain cria um ambiente onde auditar manualmente não é mais viável. Ferramentas como SBOM e SLSA não são perfeitas, mas oferecem uma base de visibilidade e verificação que a maioria dos projetos simplesmente não tem.

O próximo OSSRA vai mostrar se a indústria reagiu ou se dobrou a aposta na velocidade sem contrapartida de segurança. Se o seu projeto hoje não tem lockfile travado, lifecycle scripts desabilitados e um processo mínimo de auditoria de dependências, o momento de corrigir isso é agora.

Referências pesquisadas nesta publicação