Leer un aviso de vulnerabilidad de un paquete

Los avisos de paquetes describen las versiones afectadas como intervalos marcados por eventos: la versión en la que se introdujo el fallo y la primera versión en la que ya está corregido. Un paquete puede tener varias líneas vivas a la vez (la 7 y la 8, por ejemplo), y cada una lleva su propio par de eventos. Una versión está afectada si cae en algún intervalo: igual o posterior a la de introducción y anterior a la corregida.

De ahí salen dos trampas. La versión corregida no está afectada, aunque esté justo en el borde. Y una versión más alta no es necesariamente más segura: la 8.0.3 de la línea 8 puede estar afectada mientras la 7.9.6 de la línea 7 ya no lo está. Tampoco lo está una versión anterior a la introducción del fallo, por vieja que sea; eso sí, si la línea ya no recibe mantenimiento, el problema es otro y se trata en otra sala.

Abre el laboratorio y lee encargo.txt y el primer aviso de avisos.txt. Después cruza sus intervalos con inventario-versiones.txt. Haz la comprobación versión por versión, sin fiarte de cuál parece más nueva.

El mismo fallo se publica a menudo en más de una base de datos, cada una con su identificador. Los avisos suelen enlazarse entre sí con un campo de alias, y un escáner que consulta varias bases puede abrir una alerta por cada identificador. Contar alertas no es contar fallos: dos alertas que son alias del mismo fallo se corrigen con un solo cambio y se cierran juntas.

Un aviso también puede retirarse cuando quien lo publicó concluye que no describía un fallo. El aviso sigue existiendo con su marca de retirado y su motivo, y algunos escáneres siguen mostrándolo. Lee las cuatro alertas de alertas-simulador.txt contra los cuatro avisos.

La severidad de un aviso suele venir como un vector CVSS, el sistema de puntuación que mantiene FIRST, con su puntuación base. La base describe el fallo en abstracto: cómo se alcanza, qué hace falta y qué pierde un sistema cualquiera que lo tenga. No sabe si tu aplicación llama a la función afectada ni si el dato que la dispara viene de fuera. Además, cada base de datos puede puntuar el mismo fallo de forma distinta, o no publicar vector.

Hay otras dos señales públicas que se suman a la base. EPSS, también de FIRST, estima la probabilidad de que se observe explotación de una vulnerabilidad con identificador CVE en los 30 días siguientes. Y el catálogo KEV de CISA lista las vulnerabilidades de las que hay evidencia de explotación activa. Ninguna de las tres sustituye a la pregunta que se trabaja en la sala siguiente: ¿se usa de verdad la función afectada?

Cuando un paquete tiene varias líneas corregidas, la actualización más segura para el día a día suele ser la menor que salga del rango afectado sin cambiar de versión mayor: los cambios mayores pueden romper la compatibilidad y piden su propia revisión. Mira la versión que tiene el simulador y la línea a la que pertenece.