Introducción
La explosión en la emisión de CVEs del kernel de Linux ha desbordado los procesos de triage tradicionales. Desde que el proyecto del kernel se convirtió en una Autoridad de Numeración de CVEs (CNA) en febrero de 2024, la frecuencia pasó de aproximadamente dos vulnerabilidades semanales a alrededor de 16 diarias. En un solo día, el 15 de agosto de 2026, se publicaron 848 CVEs. Para los equipos de infraestructura que mantienen kernels personalizados, como los que soportan la infraestructura subyacente de Amazon EC2, filtrar esta señal del ruido es una tarea que consume recursos críticos y retrasa la mitigación de riesgos reales.
AWS presentó en la Linux Plumbers Conference en Praga cómo su equipo maneja este volumen mediante una arquitectura de tres etapas: un filtro determinístico, un agente de inteligencia artificial y una revisión humana final. Este modelo no busca reemplazar al ingeniero, sino acelerar la etapa de clasificación para que los expertos se concentren en la validación de contexto y los riesgos específicos de su entorno, ignorando métricas genéricas como la puntuación CVSS cuando no reflejan la realidad operativa.
Qué ocurrió
Dylan Johnson y Justinien Bouron, ingenieros del equipo de kernel de EC2, explicaron que su carga de trabajo es distinta a la de Amazon Linux o a la que ejecutan los clientes en sus máquinas virtuales. Ellos mantienen el kernel que corre debajo de la hipervisor de EC2. La primera línea de defensa no utiliza IA. Bouron detalló que las publicaciones de CVEs en formato JSON incluyen las versiones afectadas y los archivos fuente involucrados. Un script automatizado descarta inmediatamente cualquier CVE si la versión del kernel en producción está fuera del rango afectado o si ninguno de los archivos mencionados está compilado en la imagen del kernel.
Este filtro determinístico elimina cerca del 70% de las CVEs reportadas en el entorno de AWS, aunque Bouron aclaró que este porcentaje depende estrictamente de la configuración del kernel (kernel config). Las CVEs restantes pasan a un agente de IA. Este agente recibe el árbol de código fuente del kernel de AWS, la configuración específica de cada plataforma, una descripción del entorno y del modelo de amenazas, y una rúbrica de severidad propia. El objetivo es producir una tabla que identifique el subsistema afectado, el tipo de vulnerabilidad y el vector de ataque, permitiendo a los ingenieros evaluar el impacto real sin leer todo el reporte de la CVE.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
La adopción de agentes de IA para triage de seguridad marca un cambio en la operatoria de SRE y equipos de seguridad en la nube. El dato más relevante es la disparidad de tiempos: mientras un ingeniero tarda minutos en analizar una CVE compleja, el agente de AWS procesa una en aproximadamente 3.4 segundos. Esto transforma el cuello de botella operativo; la revisión manual se convierte en el paso más lento del flujo, no la identificación inicial.
Sin embargo, el impacto también revela riesgos latentes en la automatización. El equipo de AWS estima que entre el 5% y el 10% de las decisiones del agente son problemáticas o requieren ajuste. Esta tasa de error, aunque baja, exige que la revisión humana no sea un mero formalismo. Para los arquitectos de seguridad, esto implica que la confianza en la automatización debe estar calibrada con una validación rigurosa de falsos negativos y falsos positivos en el contexto específico de la infraestructura. Además, la decisión de ignorar las puntuaciones CVSS estandarizadas subraya la necesidad de rubricas de severidad internas, adaptadas a la arquitectura real de la nube privada o pública.
Detalles técnicos
El pipeline de AWS depende críticamente de la configuración del kernel y de la gestión de las ramas de soporte a largo plazo (LTS). El equipo ha descubierto que las ramas LTS más antiguas acumulan un déficit significativo de parches. Al analizar seis ramas, la mediana de tiempo desde un parche en el mainline hasta su liberación en una LTS fue de 31.8 días para Linux 5.10 y 18.1 días para Linux 6.18. A fecha del 16 de septiembre, existían 1,709 CVEs conocidas sin corregir en la rama 5.10, frente a solo 229 en la 6.18.
La complejidad de la reducción de superficie de ataque también es técnica y delicada. El equipo deshabilitó funciones del kernel innecesarias para reducir las CVEs aplicables. Bouron calificó esto como «engañosa mente difícil» debido a la presencia de más de 32,000 opciones de configuración. Eliminar la opción incorrecta puede provocar bugs sutiles o regresiones de rendimiento que tardan meses en manifestarse.
Respecto al backporting, los registros de CVEs a menudo nombran solo el commit final que corrige el problema. Un equipo que solo aplique ese commit puede seguir siendo vulnerable si faltan los commits previos requeridos como pre-requisitos. AWS ha reducido sus tiempos de migración entre versiones mayores: de 4.19 a 5.10 tardaron dos años; de 5.10 a 6.12, un año; y de 6.12 a 6.18, solo seis meses. Durante la actualización a 6.12, el 43% de los problemas rastreados se resolvieron en el espacio de usuario, ya que las cargas de trabajo dependían de comportamientos del kernel antiguo.
Microsoft, por su parte, presentó una aproximación similar para Azure Linux, donde un agente de IA sugiere entradas para una tabla de reglas de veredicto. Su uso de bucles de retroalimentación de compilación y prueba en el backporting aumentó la tasa de éxito del 50% al 80%.
Qué deberían hacer los administradores y equipos técnicos
Primero, implementen un filtro determinístico basado en la configuración de su kernel antes de considerar cualquier herramienta de IA o análisis manual. Utilicen scripts de parsing de JSON que crucen los archivos fuente afectados por la CVE con los archivos compilados en su imagen de kernel. Esto puede eliminar la mayoría del ruido sin costo computacional significativo.
Segundo, evalúen la migración a ramas LTS más recientes. Los datos de AWS muestran una correlación clara entre la antigüedad de la rama y la deuda de seguridad. Si operan kernels 5.10 o anteriores, prioricen la planificación de la migración a 6.18 o superior, considerando que los tiempos de migración pueden reducirse a medida que la experiencia del equipo madura.
Tercero, si incorporan agentes de IA para triage, no eliminen la revisión humana. Definan una rúbrica de severidad interna que ignore CVSS cuando esta no aplique a su arquitectura. Aseguren que el agente tenga acceso al código fuente completo y a la configuración específica, no solo a los metadatos de la CVE.
Finalmente, en procesos de backporting, no confíen únicamente en los commits listados en la CVE. Realicen análisis de dependencias de commits para asegurar que se aplican todos los parches previos necesarios. Utilicen pipelines de CI/CD con pruebas exhaustivas de regresión para detectar los efectos secundarios de la configuración del kernel.
# Ejemplo conceptual de filtro determinístico (pseudocódigo)
# Verificar si el archivo afectado por la CVE está en la configuración del kernel
grep -q "CONFIG_DRIVER_X" /boot/config-$(uname -r) || discard_cveConclusión
La estrategia de AWS demuestra que la IA no es una bala de plata para la seguridad del kernel, sino una herramienta de eficiencia operativa que debe integrarse con disciplina de ingeniería tradicional. La combinación de filtros lógicos, agentes contextuales y revisión humana experta permite manejar el volumen actual de CVEs sin comprometer la estabilidad del sistema. Para los equipos de infraestructura, el mensaje es claro: la automatización debe filtrar el ruido, pero el criterio humano sigue siendo indispensable para interpretar el riesgo en el contexto de la producción. La migración a kernels LTS modernos y la gestión rigurosa de la configuración del kernel son tan críticas como cualquier herramienta de IA.
Fuentes
https://www.infoq.com/news/2026/10/aws-ai-agents-linux-kernel-cves/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global