Scanners de malware com IA erram o que não leem. A Databricks fechou a lacuna com evidências, sem modelo maior

Uma suposição comum em segurança assistida por IA é que um modelo mais inteligente vai detectar mais. A Databricks Threat Research testou um caso em que essa suposição falha, e o motivo é prosaico: o modelo não consegue raciocinar sobre o que nunca lhe foi mostrado.

O caso são pacotes npm maliciosos que trazem um binário compilado. Um modelo de linguagem que revisa um pacote lê seu JavaScript, seu manifesto e seus metadados. Um executável compilado é, para esse modelo, uma carga opaca. Se o payload estiver ali, o código que o modelo consegue ler pode parecer perfeitamente comum.

Uma parcela pequena com alta taxa de erro

Em um corpus de 11,413 versões de pacotes npm maliciosos confirmadas contra avisos de malware do OSV, apenas 3.8% (432 versões) traziam um binário. O resto escondia os payloads no código-fonte ou os buscava na hora da instalação. Parcela pequena, dificuldade desproporcional: no conjunto confirmado pelo OSV, pacotes com binários não chegavam a um veredito decisivo de malicioso em 14.4% das vezes, contra 6.2% dos pacotes só com código-fonte.

Um experimento de laboratório tornou a lacuna mais nítida. Os pesquisadores rodaram 10 payloads binários em nove modelos da faixa mais barata, incluindo Claude Haiku 4.5, Gemini 3.5 Flash, GPT-5.4-nano e Llama 3.1 8B. Sem ajuda, metade dos 70 testes, 35, não atingiu o limite de escalonamento, e 20 deles foram julgados benignos.

A correção é um pipeline de evidências

A Databricks não respondeu com um modelo maior. Escreveu perfis de capacidade: playbooks declarativos, um por técnica maliciosa, como coleta de credenciais ou persistência. Cada perfil é um conjunto de condições ponderadas sobre evidências estáticas produzidas por um módulo de análise binária, pelo scanner existente e por checagens de metadados. Os perfis pontuam essas evidências contra seus próprios limiares, independentemente do modelo. Quando um dispara, o mecanismo adiciona ao prompt um resumo estruturado de cerca de 1,800 tokens antes de o modelo raciocinar. O modelo ainda pode anular essa decisão.

Com os perfis, 32 das 35 falhas de laboratório viraram detecções, e a taxa de falha de escalonamento caiu de 50% para 4%. O efeito foi maior nos modelos menores: o GPT-5.4-nano passou de 0 de 10 payloads detectados para 7, e o Llama 3.1 8B, de 4 para 10.

Leia esse resultado como uma lição de arquitetura, não como um ranking de modelos. O conhecimento de domínio fica em playbooks revisados e versionados que um time de segurança consegue auditar, a análise determinística produz as evidências, e o modelo as pondera. Essa é a configuração que continuamos encontrando em trabalhos de IA que se sustentam, onde a prova precisa vir de fora do modelo.

Como era a produção

Em um conjunto de validação separado, com 425 versões de pacotes maliciosos confirmadas pelo OSV e binários nativos, e 2,449 versões benignas de 287 pacotes populares (mais de um milhão de downloads mensais cada, nenhum no OSV), o scanner escalando em “altamente suspeito” ou acima produziu 345 verdadeiros positivos, 80 falsos negativos, 104 falsos positivos e 2,345 verdadeiros negativos. Isso é precisão de 0.77, recall de 0.81 e F1 de 0.79, com falsos positivos em 4.25% das versões benignas. Dos falsos negativos, 60 foram rebaixados para “suspeito” e 20 liberados como benignos.

Esses números descrevem uma ferramenta de triagem, não um portão. Uma em cada cinco versões maliciosas nesse conjunto ainda ficou abaixo da barra de escalonamento, e aproximadamente um em cada quatro escalonamentos era benigno. A Databricks também observa que o OSV rotula pacotes inteiros, então algumas versões liberadas podem carregar o payload em JavaScript ou metadados, não no binário, e que modelos hospedados mudam continuamente, o que torna a comparação entre condições mais confiável do que qualquer pontuação absoluta.

O que os times de segurança devem tirar disso

Meça o que seu revisor de IA consegue ver. Antes de comparar modelos, liste quais tipos de artefato chegam ao modelo como evidência e quais chegam como bytes opacos: binários, bundles minificados, scripts de instalação que baixam algo depois, imagens. Cada tipo cego é uma classe de ataque que o modelo vai liberar com confiança.

Coloque o conhecimento de domínio onde as pessoas possam revisá-lo. Perfis são regras versionadas, não um prompt que alguém ajustou uma vez. Quando uma nova técnica aparece, o time de segurança adiciona um perfil, e todo modelo se beneficia.

Planeje a fila de escalonamento. Com uma taxa de 4.25% de falsos positivos em pacotes populares, um grande conjunto de dependências gera trabalho real de revisão. Dimensione essa fila antes de ligar o scanner, o mesmo orçamento de verificação que descrevemos para achados de segurança de IA em geral.

Mantenha os controles estabelecidos. Nada disso substitui lockfiles, registries internos, allowlists, checagens de proveniência ou o bloqueio de scripts de instalação por padrão. Uma camada de triagem de IA decide o que merece uma olhada humana mais cedo; ela não é o motivo pelo qual um pacote malicioso não consegue chegar a um build.