Debian ha publicado una actualización de seguridad del kernel con 1.313 CVE en la lista. Antes de que alguien de dirección te reenvíe el titular: no son 1.313 agujeros nuevos, y la cifra dice mucho menos de lo que parece.
Qué ha pasado
El 29 de septiembre salió el aviso DSA-6528-1, que cubre la versión 6.12.111-1 del paquete del kernel para Debian 13, nombre en clave Trixie. La lista de identificadores adjunta tiene 1.313 entradas. Debian 13.7 se había publicado el 12 de septiembre, y el kernel 6.12.111 de upstream llegó nueve días más tarde, así que el aviso recoge todo lo acumulado desde la actualización anterior.
Dos datos que ponen la cifra en su sitio. El primero: quien lo ha revisado ha comprobado varias entradas al azar y afectan también a kernels más antiguos, de modo que la lista no es un recuento de fallos introducidos en 6.12.111. El segundo: el proyecto del kernel de Linux es Autoridad de Numeración de CVE (CNA, la entidad que puede asignar identificadores por su cuenta) desde febrero de 2024, y su política es asignar CVE de forma automática a las correcciones una vez llegan a un árbol estable. Greg Kroah-Hartman lo explicó con números a principios de este año: el desarrollo del kernel va a una media de unos nueve cambios por hora, y el equipo que revisa trabaja sobre un flujo de alrededor de treinta correcciones de fallos conocidos al día. El propio equipo reconoce que es un enfoque deliberadamente conservador, porque cuando arreglas un fallo muchas veces no sabes todavía si tenía implicaciones de seguridad. Lo tienes documentado en el kernel.
Para rematar: el 3 de octubre salió 6.12.112, con un changelog detallado de más de 27.000 líneas.
Por qué importa
Si tu proceso de parcheo tiene un paso que dice «analizar cada CVE antes de aplicar», ese proceso acaba de morir. Haz la cuenta tú mismo: pongamos dos minutos por identificador —leer la descripción, mirar si te afecta, anotarlo—. Son más de cuarenta horas de trabajo para una sola actualización de kernel de una sola distribución. Y en octubre llega la siguiente.
Esto golpea en tres sitios concretos:
- Los escáneres de imágenes. Si construyes contenedores sobre Debian y tienes una puerta de CI que falla cuando aparecen vulnerabilidades sin resolver, vas a ver listados absurdos. El problema no es el escáner, es usar el recuento como umbral.
- Los informes a cliente y auditoría. Cualquier documento que diga «este mes hemos cerrado X vulnerabilidades» pasa a ser ruido. Un número que se dispara porque cambió la política de asignación no mide tu postura de seguridad.
- Los contratos. Si alguien firmó un acuerdo de nivel de servicio con la frase «cero vulnerabilidades conocidas», tiene un problema contractual, no técnico.
Lo que yo cambiaría a partir de hoy es la unidad de trabajo. Deja de razonar por CVE y razona por versión: «estamos en la última estable de Debian, con el kernel al día, y tenemos ventana de reinicio el primer martes de mes». Esa frase es verificable, se audita en treinta segundos y no se infla. La severidad, cuando de verdad la necesites, búscala fuera del identificador: en el catálogo de vulnerabilidades explotadas que publican los organismos de seguridad, en si hay prueba de concepto pública, y en si el subsistema afectado lo tienes siquiera compilado. El rastreador de seguridad de Debian sigue siendo la vía rápida para mirar una entrada concreta cuando toca.
Qué no cambia
El aviso se está contando peor de lo que es. Tres contrapesos.
Uno: Debian no está más rota que el mes pasado. Lo que ha cambiado es que ahora se etiqueta y se publica lo que antes se arreglaba en silencio dentro de un parche de mantenimiento. Eso es más transparencia, no más agujeros.
Dos: la atribución a los bots. La fuente original sospecha que detrás de este volumen hay modelos de lenguaje buscando fallos, y posiblemente arreglándolos. Es una sospecha razonable —la lista de seguridad del kernel lleva meses desbordada de informes asistidos por IA—, pero es una sospecha, no un dato, y conviene leerla así. El grueso de la cifra lo explica la política CNA de febrero de 2024, que es anterior a todo esto.
Y tres: el trabajo real no ha crecido. Sigues ejecutando el gestor de paquetes y reiniciando. Lo que ha crecido es el papeleo que algunos han montado alrededor del parcheo.
Nuestra lectura
El titular original —1.313 razones para parchear— es ingenioso y es falso. Hay una sola razón: estás por detrás del kernel estable. Siempre fue esa.
Mi postura: contar CVE como métrica de seguridad fue una mala idea desde el principio y ahora está oficialmente muerta. Era una métrica cómoda porque se podía poner en una diapositiva, y las métricas cómodas sobreviven años después de dejar de significar algo. Esto va a obligar a mucha gente a admitir que su «gestión de vulnerabilidades» era en realidad un recuento, y me parece bien que se note.
La predicción que puede envejecer mal, y la firmo igual: en año y medio alguien tendrá que publicar una lista curada de «CVE del kernel que de verdad importan», porque la automática ya no sirve para priorizar. Se parecerá mucho a los catálogos de vulnerabilidades explotadas que ya existen, y la discusión será quién la mantiene y con qué criterio.
Sobre los bots, lo diré claro: que una máquina encuentre fallos me parece estupendo. Lo que me preocupa es la asimetría de coste. Generar un informe de vulnerabilidad plausible cuesta céntimos; descartarlo bien le cuesta a un mantenedor humano una tarde. Esa asimetría no se arregla pidiendo menos IA, se arregla poniendo filtros con criterio delante de las personas. Ya escribí aquí sobre una auditoría con dos modelos revisando y dos humanos decidiendo, y sigo pensando lo mismo: el modelo propone, la persona firma.
Esto es exactamente lo que nos encontramos cuando entramos a gestionar servidores de alguien: no falta un escáner, falta una ventana de reinicio acordada por escrito y alguien que la cumpla en agosto. Y para las máquinas que supuestamente no se pueden reiniciar nunca, la conversación honesta empieza por preguntar por qué, no por buscar un parche en caliente.
Cualquier duda me dices y lo vemos. Un saludo, Vicente.