A principios de octubre de 2026, ingenieros de Amazon Web Services (AWS) describieron un sistema para clasificar los CVE, identificadores de vulnerabilidades, del kernel Linux que mantienen para la infraestructura de EC2. Un script filtra primero los casos aplicables; después, un agente de inteligencia artificial (IA) clasifica los restantes y los ingenieros revisan el resultado. El agente ayuda a priorizar el análisis, pero no aplica parches por su cuenta.
El proceso se ocupa del kernel de la infraestructura de EC2, no de Amazon Linux ni de los kernels que los clientes ejecutan dentro de sus máquinas virtuales. AWS presentó el flujo en la Linux Plumbers Conference, celebrada en octubre en Praga. En este contexto, LTS significa soporte de larga duración y se refiere a ramas del kernel mantenidas durante periodos prolongados.
Cómo se encadenan el filtro, la IA y la revisión humana
El filtro inicial no utiliza IA: compara las versiones afectadas que indica cada CVE y los archivos enumerados con la versión del kernel y los archivos incluidos en la imagen de AWS. Según AWS, esta comprobación descartaba aproximadamente el 70% de los CVE de su entorno. La proporción depende de la configuración y del entorno; los casos restantes pasan al agente.
Para clasificarlos, el agente recibe el árbol de código del kernel personalizado, sus configuraciones, un modelo de amenazas y criterios de gravedad. Devuelve una tabla con una fila por CVE y campos como el subsistema, el tipo de vulnerabilidad y la vía de ataque. Dos ingenieros suelen revisar esa tabla antes de decidir qué hacer.
AWS calculó en unos 3,4 segundos por CVE el tiempo de procesamiento del agente, frente a varios minutos para el triaje humano. Esa cifra mide la clasificación, no la revisión ni el trabajo posterior de corregir, probar y desplegar un cambio. AWS describió la revisión humana como el cuello de botella del flujo.
Justinien Bouron estimó informalmente que entre el 5% y el 10% de las decisiones del agente podían ser problemáticas. La cifra no corresponde a una evaluación formal presentada en la charla, por lo que no debe leerse como una tasa de error medida con un protocolo de referencia.
Actualizar el kernel también exige trabajo fuera de él
En la actualización de Linux 5.10 a 6.12, AWS clasificó los problemas seguidos por el equipo según dónde se resolvieron. Las proporciones suman el total de esos problemas, no los CVE ni el tiempo de reparación.
| Categoría del problema seguido | Porcentaje |
| Espacio del kernel | 45 % |
| Espacio de usuario | 43 % |
| Configuración del kernel | 7 % |
| Firmware o hardware | 5 % |
AWS indicó además que se integró en el kernel principal el 15 % de las correcciones realizadas en el espacio del kernel. La clasificación muestra que preparar una actualización puede requerir cambios en programas de usuario, configuración y plataforma, además del trabajo sobre el kernel.
Los ejemplos de AWS ilustran ese alcance. Un cambio en el almacenamiento de áreas de memoria virtual ralentizó mmap() y munmap(), así que AWS redujo las operaciones de mapeo. Un cambio del planificador alteró los tiempos de fork(), lo que llevó a modificar los patrones de uso de esa llamada. Y un aumento del tamaño máximo predeterminado de las solicitudes de la capa de bloques provocó tiempos de espera en la entrada y salida del firmware, que AWS abordó ajustando sysctl.
AWS atribuyó la reducción del tiempo de sus actualizaciones a mejores herramientas, más cobertura de pruebas y un equipo con experiencia. La transición de 4.19 a 5.10 duró 24 meses; la de 5.10 a 6.12, 12 meses; y la de 6.12 a 6.18, seis meses. Son duraciones de esos trabajos de actualización, no plazos para corregir cada CVE.
Qué muestran las cifras de las ramas LTS
La instantánea de AWS del 16 de septiembre de 2026 cuenta CVE sin corregir por rama LTS. Los recuentos describen cada rama Linux y no indican cuántas vulnerabilidades afectan al kernel desplegado por AWS en EC2.
| Rama LTS de Linux | CVE sin corregir | Mediana desde la integración de la corrección en mainline hasta su publicación en LTS |
| 5.10 | 1.709 | 31,8 días |
| 5.15 | 1.567 | 31,5 días |
| 6.1 | 1.062 | 28,8 días |
| 6.6 | 762 | 23,1 días |
| 6.12 | 483 | 19,0 días |
| 6.18 | 229 | 18,1 días |
En la misma instantánea, las ramas 4.19 y 5.4, ambas marcadas como EOL, tenían 3.725 y 3.481 CVE sin corregir, respectivamente. La mediana de la tabla mide el intervalo entre la incorporación de una corrección a mainline y su publicación en una rama LTS; no mide cuánto tarda AWS en desplegarla.
La respuesta a un CVE depende del caso
AWS describió cuatro opciones: no actuar si el CVE no afecta al entorno; esperar al siguiente parche LTS si el impacto permite esperar; seleccionar e integrar una corrección concreta, o aplicar una solución alternativa cuando no sea posible actualizar el kernel. En la matriz de AWS, esas opciones se etiquetan, en ese orden, como ninguna, lenta, rápida y la más rápida; el riesgo asociado se clasifica como ninguno, medio, alto y bajo.
La integración de correcciones en ramas antiguas también puede complicarse porque el código se ha alejado más de la versión principal y los registros de CVE pueden omitir cambios previos necesarios. Según AWS, una adaptación incompleta puede dejar la vulnerabilidad sin resolver o causar errores y regresiones de rendimiento.
A 27 de octubre de 2026, las herramientas descritas por AWS aún no se habían publicado. Dylan Johnson dijo que el equipo quería explorar la posibilidad de compartir el filtro, sin anunciar un compromiso de lanzamiento.
