N-Day-Bench: LLMs vs Vulnerabilidades Reales

N-Day-Bench es un benchmark adaptativo que mide la capacidad real de los modelos fronterizos para detectar vulnerabilidades divulgadas después de su fecha de corte de conocimiento. En la ejecución más reciente de abril de 2026, GPT-5.4 lideró con un 83.93% de precisión, seguido por Gemini 3.1 Pro con 68.50%. El benchmark se actualiza mensualmente y usa un harness estándar para evitar que los equipos hagan “reward hacking”, midiendo así qué modelo es realmente mejor para encontrar bugs de seguridad en código que antes no existía.

Qué es N-Day-Bench: benchmarking real de seguridad

N-Day-Bench es un benchmark de seguridad desarrollado para medir qué tan bien los modelos de lenguaje grandes pueden encontrar vulnerabilidades reales del mundo. El nombre viene de “N-Day vulnerability” —una falla de seguridad que fue divulgada públicamente (pero que es más nueva que el conocimiento del modelo). Es la diferencia clave con un “Zero-Day”: un N-Day ya existe en el público, el modelo lo “debería” poder encontrar si entiende el código.

Lo piola del benchmark es que se actualiza mensualmente. No es estático. Cada mes agrega nuevas vulnerabilidades (las que fueron divulgadas ese mes) y prueba la última versión de cada modelo. Esto evita que las compañías hagan “reward hacking” —ajusten el modelo solo para ese benchmark en particular— porque si mañana hay vulnerabilidades nuevas, el truco de ayer no funciona.

Todos los modelos reciben exactamente el mismo harness y la misma información sobre el código vulnerable. Sin leeway. Sin ventajas específicas. Solo el código, la descripción del CVE, y “encontrá el bug”. ¿Quién lo encontró primero? Eso es lo que importa.

Cómo funciona el benchmark en la práctica

El proceso es simple pero riguroso. Toman un montón de CVEs divulgados recientemente (vulnerabilidades publicadas después del knowledge cutoff del modelo), descargan el código vulnerable, y lo mandan a cada modelo con la misma entrada. El modelo tiene que devolver el bug que encontró. Si lo encontró bien, suma puntos. Si lo encontró mal, no suma. Si no lo encontró, no suma.

Lo interesante es que no todos los CVEs entran al benchmark. En la última ejecución (13 de abril de 2026) analizaron 1.000 avisos de seguridad y solo aceptaron 47 casos reales para el benchmark. Eso significa que filtraron casi un 95% porque no cumplían algún criterio: el código no era lo suficientemente claro, la vulnerabilidad era demasiado obvia, o el formato no era representativo de un bug real.

Los resultados se publican en la web ndaybench.winfunc.com con trazabilidad completa. Podés ver cuál fue el modelo que corrió, a qué hora, qué encontró, y en qué falló. Eso es lo opuesto a decir “nuestro modelo es el mejor” sin mostrar nada (spoiler: a nadie le creés eso). Más contexto en modelos como Claude Sonnet 4.6.

Resultados actuales: Quién gana en detección de vulnerabilidades

La carrera más reciente de benchmarks en abril de 2026 dejó claro el ranking. En la punta está GPT-5.4, pero no es un dominio abrumador —la diferencia es de puntos decimales.

Claude Opus 4.6 está en el tercero, casi empatado con GLM-5.1. Eso significa que Anthropic está laburando de forma seria en seguridad. Gemini 3.1 Pro queda atrás, pero aclaración: estos benchmarks se hacen con las últimas versiones de los modelos, y Google suelta updates de forma menos predecible que OpenAI o Anthropic.

Ahora bien, ojo con la interpretación. Un modelo que llega a 83% no quiere decir que vas a soltar a GPT-5.4 en tu codebase y que encuentre el 83% de los bugs reales. Estos benchmarks son controlados, con casos específicos, bajo condiciones específicas. En la realidad, el contexto es barullo: el código es viejo, hay dependencias extrañas, los comentarios no dicen nada, y el modelo tiene que adivinar qué hace cada función.

N-Day-Bench vs. otros benchmarks de seguridad

No es el único benchmark que mide capacidades de LLMs en seguridad. Hay competencia, y cada uno mide algo un poco diferente.

ZeroDayBench es más pequeño pero más enfocado. Toma 22 vulnerabilidades reales en código abierto (cosas como bugs en navegadores, librerías populares) y ve si el modelo las encuentra sin conocerlas. Es más apegado a “verdaderas zero-days”. Problema: son solo 22 casos, suficiente para una prueba de concepto pero insuficiente para sacar conclusiones firmes.

CVE-Bench toma CVEs publicados y los corre en un sandbox real. No solo pide al modelo que encuentre el bug, sino que lo prueba de verdad. Ejecuta el exploit, ve si la vulnerabilidad existe. Así que hay menos margen para falsos positivos (el modelo no puede “decir que encontró algo” si no funciona). Esto lo hace más riguroso pero también más lento.

SEC-bench evaluó 200 CVEs verificados con una métrica diferente: quién mejoró más en la tarea después de ver la descripción del CVE. Ahí encontraron que los modelos mejoraban un 85.7% en precisión si les dabas contexto adicional. El problema de SEC-bench es que la mayoría de benchmarks no miden “si el modelo mejora con información”, miden “qué tan bien funciona con lo que tiene”. Esto se conecta con lo que analizamos en cómo funcionan los modelos grandes.

N-Day-Bench se ubica en el medio: casos reales (como CVE-Bench), pero solo los divulgados después del cutoff (como ZeroDayBench), actualizados mensualmente (lo que ningún otro hace), y con un harness estándar (sin reward hacking). Es el más ambicioso.

Limitaciones reales: Dónde los LLMs fallan

Antes de saltar a la conclusión de que “vamos a dejar que Claude encuentre todos nuestros bugs de seguridad”, necesitás saber dónde pifiá. Hay limitaciones importantes que el benchmark mismo revela.

Mejor explotando que detectando. Los modelos son increíblemente mejores si les das la descripción del CVE (“esta es una buffer overflow en este archivo”). Sin esa descripción, sin ese contexto, el número cae dramáticamente. GPT-4 fue probado sin descripciones de CVE en código abierto, y cayó del 60% al 7%. Eso es una caída abismal. Significa que los modelos están leyendo el describe del CVE y validando si existe, no está encontrando independientemente.

Falsos positivos en la vida real. En plataformas de bug bounty, cuando probás un modelo generando reportes de seguridad, la mayoría son falsos positivos. El modelo ve algo, cree que es un bug, pero no lo es. Después tienen que revisar cada reporte humano, y es un trabajo tedioso. El benchmark no penaliza suficientemente los falsos positivos porque mide solo los “hallazgos válidos”, pero en la realidad cada falso positivo cuesta tiempo.

Tasa de fallo en código limpio: 100%. Un estudio de Armis Labs mostró que si le pasas a un modelo código que NO tiene vulnerabilidades, ¿adivina qué pasó? Inventó bugs que no existen. Los modelos tienden a alucinaciones en seguridad. Si el prompt dice “encuentra el bug”, el modelo asume que hay un bug, y después inventa uno.

El factor contexto. Estos benchmarks dan al modelo el código vulnerable aislado. En la realidad, el código está integrado en millones de líneas de codebase, tiene dependencias oblicuas, y el modelo nunca vio exactamente ese patrón.

Casos de éxito: Lo que los modelos ya encontraron

No todo es limitaciones. Los modelos ya han encontrado bugs reales, en código real, que importa. En ejecutar estos modelos en tu máquina profundizamos sobre esto.

Claude y Firefox. Anthropic reportó que cuando sometió Claude a auditoría de código de Firefox, encontró 22 bugs en dos semanas. De esos, 14 fueron clasificados como high severity. Firefox es código maduro, auditado miles de veces, y aun así un modelo encontró cosas. Eso es importante porque significa que los LLMs ven patrones que los análisis estáticos tradicionales pierden.

Project Glasswing. Anthropic identificó vulnerabilidades en repositorios open source a escala. Miles de bugs encontrados en librerías populares. El proyecto fue publicado en papers académicos. Comprobó que si usás un LLM de forma seria, sin alucinaciones descontroladas, podés descubrir de verdad.

Big Sleep en SQLite. Un modelo encontró un Stack Buffer Underflow en SQLite, una librería que existe hace décadas y que millones de sistemas usan. Si eso no es relevante, no sé qué es.

El patrón es claro: los modelos funcionan bien en código abierto que está accesible para auditoría, sin contexto de millones de líneas. Es distinto al mundo real, pero funciona.

Errores comunes en la interpretación de N-Day-Bench

• Pensar que el porcentaje del benchmark es el porcentaje de precisión en tu codebase. N-Day-Bench: 83%. Tu codebase: realidad diferente. Las vulnerabilidades que mide el benchmark son divulgadas públicamente, están documentadas, el modelo aprendió de ellas (no está en su cutoff pero están ahí de forma pública). En tu código privado, antiguo, sin documentar, el performance será peor. Mucho peor.
• Asumir que si el modelo “encontró el bug” en el benchmark, sabe cómo escribir un patch seguro. El benchmark mide detección. No mide corrección. Un modelo puede ver el bug y decir “hay un buffer overflow acá”, pero no puede necesariamente escribir la corrección de forma segura. Podrá ayudar, pero necesita revisión.
• Ignorar los falsos positivos. Si un modelo genera 100 reportes y 80 son válidos, 20 son falso. Eso significa que en tu empresa, alguien va a tener que revisar esos 20 reportes inútiles. A escala, eso es un drenaje de recursos. El benchmark no muestra el costo operacional real.
• Creer que un modelo es “invencible” porque ganó en el benchmark. Todos los modelos están mejorando constantemente. Un modelo que gana hoy puede quedar atrás en 6 meses. El benchmark es una foto de un momento. No es un predictor del futuro.

Implicaciones para tu equipo de seguridad

¿Qué hacés con esta información? N-Day-Bench te muestra que los modelos pueden ser herramientas útiles en seguridad, pero no reemplazos de humanos.

Estrategia posible: usá un LLM como primera pasada en auditoría de código. Mandá el código a Claude Opus 4.6 o GPT-5.4, pedile que busque bugs de seguridad conocidos (inyecciones, buffer overflows, race conditions). El modelo va a atrapar lo obvio y algunos casos más sutiles. Después, un humano revisa lo que el modelo propuso. Es un flujo asimétrico: el modelo reduce el espacio de búsqueda, el humano valida.

Herramientas emergentes como Glasswing están usando esta filosofía: LLM + orquestación + revisión humana. No es “el modelo resuelve seguridad”, es “el modelo automaliza la búsqueda, los humanos deciden”. Sobre eso hablamos en otras capacidades avanzadas de IA.

Para CI/CD, podría funcionar como SAST complementario. No reemplaces SonarQube o Semgrep, pero agregá un paso que corre un LLM sobre cambios de código antes de merge. Es una capa más.

Preguntas Frecuentes

¿Qué es exactamente un N-Day en seguridad?

Un N-Day es una vulnerabilidad que fue divulgada públicamente hace N días (donde N es cualquier número mayor a cero). La diferencia con Zero-Day es que el Zero-Day aún no fue divulgado, es secreto. Un N-Day está en el internet, en CVE databases, en papers de seguridad. El modelo debería poder encontrarlo si lo ve en código.

¿Cuál es el mejor modelo para detectar vulnerabilidades según N-Day-Bench?

GPT-5.4 lidera con 83.93% en la carrera más reciente de abril de 2026. Pero Claude Opus 4.6 está muy cerca con 79.95%, a solo 4 puntos de diferencia. Para casos de uso empresarial, ambos funcionan. La diferencia real está en API pricing, rate limits, y qué tan cómodo te sentís con cada compañía.

¿Se actualiza N-Day-Bench? ¿Con qué frecuencia?

Sí, se actualiza mensualmente. Cada mes agrega nuevas vulnerabilidades divulgadas ese mes y prueba la última versión de cada modelo. Esto lo hace único comparado con benchmarks estáticos que nunca cambian. La última carrera fue el 13 de abril de 2026.

¿Puedo confiar solo en un LLM para auditoría de seguridad?

No. Los benchmarks muestran que los modelos alucinen en código sin vulnerabilidades, generan falsos positivos, y necesitan descripciones del CVE para funcionar bien. Tratá un LLM como primera pasada, no como solución final. El humano siempre tiene que revisar.

¿Qué pasa si el modelo no encuentra una vulnerabilidad en N-Day-Bench?

Que cae en el porcentaje que no alcanzó. Un modelo con 83% significa que en 17 de cada 100 casos, falló. Esos fallos pueden ser bugs que se pasó, reportes incorrectos, o código que no pudo analizar. El benchmark es transparente: podés ver los casos específicos donde cada modelo falló.

Conclusión

N-Day-Bench cambió el juego de medición en seguridad porque hizo lo que nadie hacía: benchmarks reales, adaptables, transparentes, y sin incentivos para hacer trampas. GPT-5.4 y Claude Opus 4.6 demostraron que los LLMs pueden encontrar bugs que importan, pero con límites claros.

Para tu empresa, significa que los LLMs merecen un lugar en el tooling de seguridad, pero nunca como único validador. Úsalos como capa inicial automática. Invertí en herramientas que orquesten el flujo (modelo + reviewer humano). Y entendé que cada modelo fallaría en casos reales que el benchmark no cubre.

El futuro probablemente sea híbrido: SAST tradicional + LLM + revisión humana. No es “reemplazamos auditores con IA”, es “aceleramos auditores con IA”. Eso sí, mirá el benchmark antes de elegir modelo. Las diferencias son pequeñas pero reales.

Fuentes

• N-Day-Bench – Benchmark adaptativo de vulnerabilidades
• Arxiv – Papers sobre benchmarks de seguridad en LLMs
• IBM Research – Limitaciones de LLMs en detección de vulnerabilidades
• Cloudflare – CASB e integraciones de IA
• Ecosistema Startup – Claude encontró 22 bugs en Firefox