¿CVEs críticos de SQLite o basura de LLM?

Artículo original ↗ Discusión en Hacker News ↗

Varias vulnerabilidades “críticas” recientes de SQLite resultaron ser fabricadas, probablemente generadas por modelos de lenguaje grandes, pero aun así se propagaron por canales oficiales de CVE y escáneres empresariales. Los comentaristas sostienen que esto expone cuán sobrecargado y ruidoso se ha vuelto el ecosistema de vulnerabilidades actual, especialmente para las organizaciones obligadas por cumplimiento, seguros o políticas internas a parchear cada CVE sin importar el contexto. Aunque muchos ven los LLM como herramientas potentes para encontrar bugs reales, advierten que la basura generada por IA está elevando los costes de triage, socavando la confianza en los datos de CVE y creando presión para añadir pasos de validación más fuertes, potencialmente usando otra vez IA en el lado defensivo.

Impacto en las organizaciones y los flujos de trabajo de seguridad

  • Muchos comentaristas dicen que las políticas de “parchar todos los CVE” (impulsadas por SOC2, ISO27001, HIPAA, cláusulas de seguros, trabajo gubernamental, etc.) ya son apenas viables; los CVE falsos o de baja calidad las empeoran.
  • Los equipos de seguridad informan que pasan la mayor parte de su tiempo desmintiendo hallazgos inexplotables o irrelevantes (por ejemplo, vulnerabilidades de Bluetooth en servidores sin interfaz, problemas solo para Windows en stacks de Linux).
  • Los auditores, las aseguradoras y las políticas internas a menudo hacen más fácil parchear o actualizar que argumentar que una vulnerabilidad es irrelevante, incluso cuando claramente no es alcanzable.
  • Algunas organizaciones lo mitigan usando excepciones/SLA basados en riesgo, pero conseguir que se aprueben excepciones puede ser doloroso y políticamente delicado.

Problemas con el ecosistema CVE

  • Las puntuaciones base de CVSS se ven como malos sustitutos del riesgo real; el scoring ambiental/contextual es difícil y requiere mucho trabajo.
  • Muchos CVE apuntan a componentes oscuros o no usados (por ejemplo, utilidades incluidas con bibliotecas), pero aun así fuerzan actualizaciones globales.
  • La cadena de explotación y la defensa en profundidad complican las afirmaciones de “no es explotable”: fallos menores pueden volverse graves cuando se combinan.
  • NIST/NVD está sobrecargado; la asignación de CVE es en gran medida clerical y confía en quienes lo reportan, sin un requisito sistemático de PoC.
  • Los grandes proyectos que se convierten en CNA intentan recuperar el control, pero ahora están inundados por informes generados por IA; algunos programas de recompensas han eliminado pagos por culpa de la basura.

LLMs en el descubrimiento de vulnerabilidades

  • El hilo coincide en que los LLM ahora son capaces de encontrar bugs reales, especialmente en código antiguo en C/C++; los mantenedores informan de un volumen creciente de incidencias genuinas.
  • Al mismo tiempo, los LLM alucinan código, versiones y exploits, lo que lleva a CVE falsos y a tiempo de triage desperdiciado.
  • Preocupa que los atacantes combinen LLM de escaneo con LLM de escritura de exploits y gran capacidad de cómputo para automatizar compromisos profundos y laterales.
  • El siguiente paso esperado: agentes que reproduzcan automáticamente PoC y filtren la basura antes de que los humanos vean los informes, aunque el coste y la fiabilidad siguen abiertos.

Debate sobre las capacidades y la confianza en los LLM

  • Un bando enfatiza que los LLM son predictores estocásticos del siguiente token que requieren verificación humana estricta, advirtiendo contra confiar demasiado en ellos en flujos de trabajo críticos para la seguridad.
  • Otro bando sostiene que, pese a ser probabilísticos, ya muestran una resolución de problemas y un análisis de código no triviales, y deben tratarse como herramientas potentes pero falibles.
  • Debate filosófico más amplio sobre si los cerebros son “solo” máquinas probabilísticas y qué implica eso para la inteligencia de las máquinas.

Mitigaciones y gobernanza propuestas

  • Entre las sugerencias están: exigir exploits funcionales para CVE de alta severidad; escáneres de vulnerabilidades más granulares y conscientes del uso; ejecutores automáticos de PoC; mejor financiación para NIST; y posiblemente licencias profesionales o una mayor rendición de cuentas por el uso indebido de la IA en dominios críticos.