Lo que más se repite en los incidentes que he visto no es falta de tecnología ni falta de presupuesto. Es que la organización creía que estaba cubierta porque cumplía con lo que le pedían: el scan trimestral, el informe para el directorio, la casilla marcada en la auditoría. Y sin embargo, terminó comprometida.
La diferencia entre cumplir y estar protegido nunca fue tan grande como hoy.
La ventana que se cerró
Hace algunos años, cuando se publicaba una vulnerabilidad crítica, los equipos de seguridad tenían un margen razonable para actuar. Entre la publicación del CVE, la aparición de un exploit público funcional y la explotación activa en ataques reales, pasaban semanas. A veces meses. Ese tiempo era suficiente para identificar los sistemas afectados, priorizar y parchear.
Ese margen ya no existe de la misma forma.
Hoy, con modelos de lenguaje y herramientas de análisis de código asistidas por IA, el tiempo entre que se publica una vulnerabilidad y que aparece un exploit funcional se redujo a horas en muchos casos. No porque los atacantes sean más inteligentes, sino porque la IA les permite analizar el advisory, leer el diff del parche, entender el vector de ataque y generar un proof-of-concept con una velocidad que antes era imposible.
El caso de Log4Shell en 2021 fue una advertencia temprana: a las pocas horas de la divulgación ya había intentos masivos de explotación en internet. Desde entonces, ese patrón se aceleró. Lo que antes era la excepción hoy tiende a ser la norma en vulnerabilidades de alto impacto.
El error de priorizar por score
El CVSS es el estándar más usado para medir la gravedad de una vulnerabilidad. Da un número entre 0 y 10, y la lógica natural es: parchea primero lo que tiene score más alto.
El problema es que el CVSS mide severidad teórica. Qué tan grave sería la vulnerabilidad si alguien la explotara, en las condiciones más adversas posibles. No mide si alguien la está explotando realmente, ni si existe un exploit funcional y accesible.
Esto genera una distorsión práctica: una vulnerabilidad con CVSS 9.8 que afecta a un protocolo oscuro sin exploit conocido ocupa el primer lugar de la lista, mientras que una con CVSS 7.2 que lleva semanas siendo usada en ataques activos queda enterrada más abajo. Si priorizas solo por score, parcheas en el orden equivocado.
Lo mismo pasa cuando se prioriza por cumplimiento normativo. La norma puede exigir remediar vulnerabilidades críticas en X días. Pero “crítica” según el estándar normativo y “crítica según el riesgo real que enfrenta tu organización hoy” son dos cosas distintas.
La pregunta que cambia todo
La pregunta correcta no es “¿qué tan grave es esta vulnerabilidad en teoría?”. Es: “¿esta vulnerabilidad ya la están usando activamente atacantes reales contra organizaciones como la mía?”
Para responder esa pregunta existen dos fuentes concretas:
EPSS (Exploit Prediction Scoring System): un modelo estadístico que combina características técnicas de la vulnerabilidad con datos de actividad en internet para predecir la probabilidad de explotación en los próximos 30 días. No es teoría: usa evidencia de lo que está pasando. Un CVE con CVSS 9.8 puede tener EPSS de 0.3%. Otro con CVSS 7.5 puede tener EPSS de 85%. Esa diferencia importa más que el score cuando decides qué parcheas esta semana.
KEV de CISA (Catálogo de Vulnerabilidades Explotadas Conocidas): una lista mantenida con vulnerabilidades para las que hay evidencia confirmada de explotación activa en ataques reales. Sin predicciones, sin modelos: si está en el KEV, ya la están usando. Para cualquier equipo de seguridad, el KEV es la lista que nunca debería ignorar, independientemente de lo que diga el score.
Combinar ambas fuentes, cruzadas con el inventario real de activos de la organización, da una imagen mucho más precisa del riesgo que enfrentas que cualquier número del 1 al 10.
Por qué esto no funciona sin automatización
El problema operacional es que este análisis tiene que hacerse de forma continua, sobre todos los activos relevantes, y actualizarse a medida que cambia el panorama. No es algo que se pueda hacer manualmente una vez al trimestre.
Cuando se publican decenas de CVEs por semana, cruzar cada uno contra el inventario de activos, consultar su EPSS actualizado, verificar si está en el KEV y generar una lista de prioridad accionable es un proceso que no escala sin automatización. Un analista que intenta hacerlo a mano termina en uno de dos extremos: o procesa todo con la misma urgencia (y colapsa), o filtra por intuición (y se le escapa lo importante).
La automatización no reemplaza el criterio: lo amplifica. Te dice qué mirar. El analista decide qué hacer con eso.
Lo que la experiencia enseña
Después de años trabajando en respuesta a incidentes y evaluando la postura de seguridad de distintas organizaciones, el patrón es consistente: las que terminan comprometidas no son necesariamente las que tenían menos recursos. Son las que confundieron cumplir con estar protegidas.
Cumplir un estándar es un punto de partida, no un destino. El objetivo real es no ser la próxima víctima, y para eso necesitas saber qué riesgo estás enfrentando hoy, no qué score tiene una vulnerabilidad en un documento.
La IA cambió el terreno de juego. La respuesta no es entrar en pánico ni contratar más herramientas: es cambiar la pregunta que le haces a los datos que ya tienes.
