El kernel de Linux asigna tal cantidad de identificadores CVE que el cuello de botella ya no está en encontrar los fallos, sino en decidir cuáles importan y en aplicarlos a tiempo. La conferencia Linux Plumbers de 2026 dedicó una sesión al problema, con dos ingenieros de Amazon contando cómo responde la infraestructura que sostiene sus servicios. La conclusión fue incómoda: el sistema funciona por la disciplina de unos pocos y no por un proceso diseñado para este volumen.
El caso del CVE-2026-98432 ilustra el ritmo. Un fallo de 9.8 en el código TCP del kernel afectó a Ubuntu, RHEL y otras distribuciones, con un exploit escrito por un modelo de Anthropic y sin parche inmediato en algunas plataformas. Cuando un solo fallo exige coordinación entre el equipo del kernel, media docena de distribuciones y miles de administradores, la cifra de CVE publicados por semana deja de ser una estadística y se convierte en una carga operativa.
La respuesta que se está abriendo paso no es contratar más gente. Es automatizar la parte del trabajo que consiste en leer, clasificar y priorizar, dejando a los humanos la decisión final. Esa división tiene sentido y también un riesgo evidente, porque un agente que se equivoca al descartar un fallo produce el mismo resultado que un fallo no parcheado.
Un grifo que no se cierra
El equipo de seguridad del kernel publica avisos con una cadencia que ninguna distribución puede seguir al mismo ritmo. Cada CVE implica identificar la versión afectada, escribir el parche, retroportarlo a las ramas estables y avisar a los consumidores. Las ramas antiguas añaden una capa extra, porque lo que se arregla en la última versión tiene que viajar hacia atrás sin romper nada.
Ese trabajo se sostiene sobre un grupo pequeño de personas con mucho criterio y poco tiempo. La sesión de Linux Plumbers se centró precisamente en los usuarios y no en los desarrolladores, una elección reveladora. El problema ya no es la detección, es la absorción por parte de quienes tienen que decidir si actualizan su parque o asumen el riesgo.
La cifra que manejan las distribuciones es brutal. Un administrador de sistemas ve decenas de avisos por semana, muchos sin explotación conocida, y tiene que distinguir el que exige una ventana de mantenimiento urgente del que puede esperar al ciclo mensual. Esa clasificación la hace una persona cansada a las once de la noche, con una lista que no deja de crecer.
La IA entra por donde duele
Amazon presentó en la conferencia un sistema que usa agentes para triar los CVE del kernel que afectan a su infraestructura. La idea es que un modelo lea el aviso, localice el código afectado, compruebe si el sistema en cuestión usa esa ruta y proponga una prioridad. Lo que antes requería un ingeniero durante media hora pasa a resolverse en segundos, con revisión humana en los casos dudosos.
El resultado práctico aparece en los tiempos de respuesta. Un fallo que afecta a un servicio expuesto se puede aislar y parchear antes de que alguien publique un exploit, y uno que afecta a un módulo que nadie carga se puede posponer sin remordimiento. La clasificación fina es justamente lo que faltaba cuando el volumen se disparó.
El riesgo también es proporcional. Un agente que lee mal un aviso puede concluir que una ruta no se usa cuando sí se usa, y esa conclusión errónea viaja hacia una decisión de no parchear. La diferencia con un humano es que el error se repite mil veces sin cansancio. Cualquier despliegue de este tipo necesita auditoría de las decisiones descartadas, no solo de las aceptadas.
Del CVE al parche en tiempo récord
La otra mitad del problema es el parche. Las distribuciones comerciales mantienen versiones antiguas con retroportes, y ahí la IA también empieza a usarse para adaptar correcciones a ramas que ya no reciben el código original. Es un trabajo mecánico y delicado, ideal para automatizar y terrible para automatizar mal.
El ecosistema tiene un incentivo perverso en este punto. Un fallo sin parche en una distribución con soporte largo genera titulares, y el equipo que lo atiende suele ser más pequeño que el que lo reporta. Las empresas que dependen de esas distribuciones no siempre contribuyen al mantenimiento, aunque sean las primeras interesadas en que exista.
En ese contexto, la automatización es una forma de ganar tiempo y no una solución. Si el 80 % de los avisos se puede triar automáticamente, el equipo libera horas para los casos graves. Si el sistema se usa para no mirar, el mismo 80 % se convierte en deuda invisible que aparece el día del incidente.
El criterio de quien decide no parchear
Hay una pregunta que la sesión dejó flotando. Cuando un agente decide que un CVE no aplica, ¿quién firma esa decisión? En un banco, la respuesta es un comité con nombre y apellidos. En la mayoría de las empresas, la respuesta es un ticket cerrado sin más rastro que un comentario automático.
Ese vacío es el mismo que ya existe con las herramientas de gestión de vulnerabilidades, solo que ahora se llena más rápido. La diferencia es que un modelo puede justificar una decisión con un razonamiento plausible y equivocado, y ese texto acaba pareciendo una evaluación cuando solo era una inferencia.
La recomendación que sale de la conferencia es razonable y poco glamurosa. Registrar la decisión, separar los descartes de los pendientes y revisar por muestreo lo que el sistema decidió ignorar. Sin esa disciplina, la automatización no reduce el riesgo, solo lo hace menos visible.
La parte menos visible del problema son las ramas que ya no reciben desarrollo. Una distribución con soporte de diez años tiene que retroportar cada corrección a un árbol que no se parece al actual, y ese trabajo se hace con menos manos de las que hicieron el código original.
Ahí la automatización ayuda de verdad, porque adaptar un parche a una versión antigua es mecánico y comprobable. También ahí es donde un error se propaga a miles de servidores que nadie va a revisar uno por uno. La revisión humana sigue siendo el cuello de botella y seguirá siéndolo.
Lo que el kernel enseña al resto
El kernel es un caso extremo y por eso sirve de aviso. Cualquier proyecto que acumule avisos de seguridad acabará en la misma situación, desde una biblioteca de cifrado hasta un framework web. La diferencia es que el kernel tiene una comunidad enorme para responder y la mayoría de los proyectos no.
Con más de 40 millones de líneas de código, casi 20.000 cambios por ventana de fusión y un flujo de vulnerabilidades que no se detiene, el kernel se ha convertido en el mejor laboratorio para medir cuánto puede automatizarse la seguridad sin perder el control. Lo que se aprenda aquí se copiará en el resto del software libre en menos tiempo del que parece.
La pregunta que queda no es si los agentes van a triar CVE, porque ya lo están haciendo. Es si las organizaciones van a conservar la capacidad de entender por qué decidieron no parchear algo, o si dentro de un año nadie podrá explicar por qué un servidor concreto sigue en una versión vulnerable.
