Escáneres de malware con IA no leen binarios: Databricks cerró la brecha con evidencia

Una suposición común en la seguridad asistida por IA es que un modelo más inteligente detectará más. Databricks Threat Research probó un caso en el que esa suposición falla, y la razón es mundana: el modelo no puede razonar sobre lo que nunca se le mostró.

El caso es el de paquetes npm maliciosos que incluyen un binario compilado. Un modelo de lenguaje que revisa un paquete lee su JavaScript, su manifiesto y sus metadatos. Un ejecutable compilado es, para ese modelo, una carga opaca. Si la carga útil vive ahí, el código que el modelo puede leer puede parecer perfectamente normal.

Una parte pequeña con una gran tasa de fallos

En un corpus de 11,413 versiones de paquete npm maliciosas confirmadas con avisos de malware de OSV, solo el 3.8% (432 versiones) incluía un binario. El resto escondía sus cargas útiles en el código fuente o las descargaba en el momento de la instalación. Proporción pequeña, dificultad desproporcionada: en todo el conjunto confirmado por OSV, los paquetes con binarios no alcanzaron un veredicto malicioso decisivo el 14.4% de las veces, frente al 6.2% de los paquetes solo con código fuente.

Un experimento de laboratorio agudizó la brecha. Los investigadores probaron 10 cargas útiles binarias con nueve modelos de la gama más económica, incluidos Claude Haiku 4.5, Gemini 3.5 Flash, GPT-5.4-nano y Llama 3.1 8B. Sin ayuda, la mitad de las 70 pruebas, 35, no alcanzaron el umbral de escalado, y 20 de ellas se juzgaron benignas.

La solución es un pipeline de evidencia

Databricks no respondió con un modelo más grande. Escribió perfiles de capacidad: playbooks declarativos, uno por técnica maliciosa, como la recolección de credenciales o la persistencia. Cada perfil es un conjunto de condiciones ponderadas sobre evidencia estática producida por un módulo de análisis binario, el escáner existente y comprobaciones de metadatos. Los perfiles puntúan esa evidencia contra sus propios umbrales, con independencia del modelo. Cuando uno se activa, el motor añade al prompt un resumen estructurado de unos 1,800 tokens antes de que el modelo razone. El modelo todavía puede anularlo.

Con los perfiles, 32 de los 35 fallos de laboratorio se convirtieron en detecciones, y la tasa de fallo de escalado cayó del 50% al 4%. El efecto fue mayor en los modelos más pequeños: GPT-5.4-nano pasó de 0 de 10 cargas detectadas a 7, y Llama 3.1 8B, de 4 a 10.

Lea ese resultado como una lección de arquitectura, no como una clasificación de modelos. El conocimiento de dominio está en playbooks revisados y versionados que un equipo de seguridad puede auditar, el análisis determinista produce la evidencia y el modelo la pondera. Esa es la disposición que seguimos encontrando en el trabajo de IA que resiste, donde la prueba tiene que venir de fuera del modelo.

Cómo se veía producción

En un conjunto de validación separado, 425 versiones de paquete maliciosas confirmadas por OSV con binarios nativos y 2,449 versiones benignas de 287 paquetes populares (más de un millón de descargas mensuales cada uno, ninguno en OSV), el escáner, al escalar en «muy sospechoso» o más, produjo 345 verdaderos positivos, 80 omisiones, 104 falsos positivos y 2,345 verdaderos negativos. Eso es 0.77 de precisión, 0.81 de recall y 0.79 de F1, con falsos positivos en el 4.25% de las versiones benignas. De las omisiones, 60 se rebajaron a «sospechoso» y 20 se descartaron como benignas.

Esas cifras describen una herramienta de triaje, no una barrera. Una de cada cinco versiones maliciosas de ese conjunto todavía quedó por debajo del umbral de escalado, y aproximadamente uno de cada cuatro escalados era benigno. Databricks también señala que OSV etiqueta paquetes completos, así que algunas versiones descartadas pueden llevar su carga útil en JavaScript o en metadatos en lugar del binario, y que los modelos alojados cambian de forma continua, lo que hace que la comparación entre condiciones sea más fiable que cualquier puntuación absoluta.

Qué deberían llevarse los equipos de seguridad

Mida lo que su revisor de IA puede ver. Antes de comparar modelos, enumere qué tipos de artefacto llegan al modelo como evidencia y cuáles llegan como bytes opacos: binarios, bundles minificados, scripts de instalación que descargan después, imágenes. Cada tipo ciego es una clase de ataque que el modelo dejará pasar con confianza.

Ponga el conocimiento de dominio donde las personas puedan revisarlo. Los perfiles son reglas versionadas, no un prompt que alguien ajustó una vez. Cuando aparece una técnica nueva, el equipo de seguridad añade un perfil y todos los modelos se benefician.

Planifique la cola de escalado. Con una tasa de falsos positivos del 4.25% en paquetes populares, un parque grande de dependencias genera trabajo de revisión real. Dimensiónelo antes de activar el escáner, el mismo presupuesto de verificación que describimos para hallazgos de seguridad de IA en general.

Mantenga los controles establecidos. Nada de esto reemplaza los lockfiles, los registros internos, las allowlists, las comprobaciones de procedencia ni el bloqueo de scripts de instalación por defecto. Una capa de triaje con IA decide qué merece antes una mirada humana; no es la razón por la que un paquete malicioso no puede llegar a una compilación.