Greg Kroah-Hartman – Seguridad en la era de los LLM [video]

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

Las afirmaciones de que la IA Mythos de Anthropic descubrió decenas de vulnerabilidades críticas en el kernel de Linux se están reexaminando a la luz de informes que indican que solo unas pocas eran reales, en su mayoría errores menores que tardaron alrededor de una hora de trabajo de desarrollador en corregirse. Los comentaristas sostienen que esto pone de relieve un patrón más amplio de exageración de las capacidades de los modelos de lenguaje grandes, especialmente en seguridad, donde los falsos positivos son altos y los medios y la dirección suelen aceptar el marketing sin cuestionarlo. El hilo también plantea preocupaciones sobre el riesgo legal derivado de los datos de entrenamiento, el impacto del ruido generado por LLM en los mantenedores de código abierto y la importancia de tratar estas herramientas como asistentes estrechamente supervisados, no como expertos autónomos.

Resultados de Mythos sobre errores del kernel

  • La charla destacó un desglose de 79 “vulnerabilidades” reportadas: muchas no tenían detalles útiles, algunas ni siquiera eran errores, otras usaban datos inventados, y ~15 ya estaban corregidas.
  • Alrededor de 20 requerían cualquier cambio de código, y solo ~10 se consideraban errores “reales” con un impacto plausible; varias dependían de configuraciones de ataque muy rebuscadas.
  • Mythos contó mal sus propios problemas, reforzando la percepción de que los LLM son frágiles incluso en lo básico, como contar.
  • Algunos comentaristas señalan que Mythos sí encontró errores graves en otros sitios (p. ej., NFS, pilas BSD/OpenBSD), así que no es inútil, pero faltaron “pruebas irrefutables” en Linux.

Ruido, falsos positivos y CVE

  • Los mantenedores informan que los informes de seguridad automatizados y basados en LLM están dominados por falsos positivos largos y demasiado confiados, que son costosos de revisar.
  • La práctica en el kernel es asignar CVE a prácticamente cada corrección de error, lo que explica las altas cifras de CVE; los problemas encontrados por Mythos recibieron CVE, pero en su mayoría tenían poco impacto.
  • Se contrasta una tasa de falsos positivos de ~50% para herramientas LLM con analizadores estáticos más antiguos, de ~20%, que ya tuvieron dificultades para lograr adopción.
  • Asimetría clave: ahora los informes de errores son casi gratis de generar, pero el coste de verificación para expertos sigue siendo el mismo.

LLM como herramientas: capacidad frente a limitaciones

  • Muchos describen los modelos de frontera actuales como potentes detectores de patrones: buenos para encontrar patrones recurrentes de código, débiles en contexto del mundo real y modelado de amenazas.
  • Las analogías van desde “becario demasiado confiado” hasta “estudiante de posgrado en el percentil superior a toda velocidad”, pero varios sostienen que eso halaga a los LLM; los becarios aprenden y asumen responsabilidad, los modelos no.
  • Otros responden que “detectar patrones” es también todo lo que hacen los humanos, y si las máquinas encuentran defectos que los humanos pasan por alto, eso ya es valioso independientemente de su estatus filosófico.

Hype, medios y confianza

  • Mythos es visto ampliamente como exagerado: se promocionó como peligrosamente potente, con acceso fuertemente controlado, pero produjo sobre todo problemas triviales o ya corregidos en Linux.
  • Los comentaristas conectan esto con la PR más amplia de IA (afirmaciones de “demasiado peligrosa para publicarse”, modelos “conscientes”, visitas al Papa) y con periodistas amplificando sin crítica las narrativas de los proveedores.
  • Los ciclos repetidos de “esta vez sí es increíble” cada seis meses llevan a un escepticismo creciente, incluso entre usuarios que encuentran los LLM útiles en la práctica.

Implicaciones de seguridad y modelos de amenaza

  • Algunos sostienen que incluso un solo error real más agentes capaces de encadenar exploits ya es preocupante; los LLM también acortan el tiempo desde el error hasta un exploit funcional.
  • Otros enfatizan que los errores descubiertos en el kernel fueron en gran medida no críticos y/o de nicho (p. ej., imágenes de sistemas de archivos maliciosas, casos de red exóticos).
  • Debate sobre futuros “gusanos de IA autónomos y autorreplicantes”: algunos creen que esto es plausible una vez que los modelos locales capaces sean comunes; otros señalan las limitaciones actuales de hardware y despliegue.

Preocupaciones legales y de proceso

  • Una afirmación citada: solo una minoría de los corpus de entrenamiento comunes es claramente legal de usar; el resto está en una zona gris.
  • Esto plantea dudas sobre incorporar parches generados por LLM en proyectos como el kernel si las salidas se parecen a datos entrenados con copyright.
  • Mecanismos existentes como Developer Certificate of Origin se consideran necesarios pero no resuelven por completo los nuevos riesgos; el resultado de decisiones judiciales pendientes se ve como incierto.

Patrones de uso práctico y consejos

  • Varios recomiendan:
    • Tratar los LLM estrictamente como herramientas de asistencia, no como desarrolladores autónomos.
    • “Ignora los comentarios, mira el código” – las explicaciones generadas suelen estar mal; el código es lo que importa.
    • Nunca subir datos no públicos o sensibles a modelos SaaS; ejecutar modelos de pesos abiertos localmente cuando sea posible.
    • Esperar que el uso de LLM tense la colaboración técnica, ya que algunos colaboradores ahora se remiten a “lo que dijo mi modelo” por encima de la revisión humana.