Un programa preemptivo actúa sobre la exposición antes de que exista una alerta, no después. Dos números dicen si el suyo lo hace: el tiempo entre que un activo queda expuesto y el equipo se entera, y la fracción de lo detectado que pasó por alguna prueba de que era explotable. Un programa periódico responde lo primero en días o semanas, y no responde lo segundo.
Todo fabricante de seguridad pegó la palabra preemptivo en alguna página en los últimos doce meses. Cuando un adjetivo lo adopta todo el mundo a la vez, deja de separar nada.
Lo que sigue separando es la medición. Y aquí está la parte que suele sorprender: bastan dos números, los dos salen de una tarde de trabajo, y ninguno exige comprar nada. Juntos dan un diagnóstico más específico que cualquier evaluación de madurez que usted contrate.
Por qué la pregunta se volvió urgente
El DBIR 2026 de Verizon trae tres datos que solo tienen sentido leídos juntos.
Tres medidas del informe sostienen esto. La explotación de vulnerabilidades pasó a ser la forma más común de entrada, adelantando al robo de credenciales, y a la vez la velocidad de quien cierra la puerta retrocedió, con la mediana de corrección alargándose de 32 a 43 días. La tercera escuece más, porque habla de ejecución y no de descubrimiento. Del catálogo de CISA, que recoge lo que está comprobadamente bajo explotación, un 26% figuraba como corregido.
La puerta principal pasó a ser el fallo expuesto, y la cola que debería cerrarla avanza más despacio que antes. Corregir más rápido se convirtió en una promesa que los números no sostienen.
Queda reducir lo que está expuesto. Y reducirlo exige saber qué está expuesto antes de que lo sepa el adversario. Ahí entran las dos pruebas.
Prueba 1: cuánto tarda usted en saberlo
Tome los últimos diez activos que aparecieron en su superficie externa. Un subdominio nuevo, un entorno de preproducción publicado por error, un panel administrativo que subió con una integración, un bucket que alguien abrió para resolver un problema de viernes.
Para cada uno, anote dos fechas. Cuándo quedó alcanzable desde internet, y cuándo alguien del equipo de seguridad supo que existía.
La diferencia entre ambas es su tiempo hasta el descubrimiento.
Si la mediana cae en horas, el programa es preemptivo en esa dimensión. Si cae en días, es periódico con nombre nuevo. Y si no consigue establecer la primera fecha, ese es el hallazgo, mayor que el número que quería calcular.
Una salvedad sobre lo que esta prueba no mide: nada dice de si el activo era peligroso, y un entorno de preproducción sin datos reales y con la autenticación al día puede estar expuesto meses sin consecuencia alguna. Lo que mide es la velocidad de su conocimiento.
Y cuidado con la trampa del inventario. Muchas empresas miden esto contra su propia lista de activos, lo que garantiza un resultado bueno y falso. El activo que importa para la prueba es justamente el que no estaba en la lista.
Prueba 2: cuánto de lo que sabe significa algo
Tome todo lo que su herramienta reportó el último trimestre. Súmelo. Después cuente cuántos de esos elementos pasaron por alguna verificación de que el fallo era realmente alcanzable y explotable en ese activo concreto.
Divida el segundo entre el primero.
En la mayoría de los programas que veo, ese número queda por debajo del 5%. El resto de la cola son hallazgos en bruto, ordenados por CVSS, esperando a alguien con tiempo para revisarlos uno a uno.
Ahí se evapora la mayor parte del presupuesto de seguridad. El CVSS mide daño potencial en condiciones ideales para el atacante y no dice nada sobre la probabilidad de que alguien lo intente. Hay fallos 9.8 publicados hace años sin un solo exploit conocido. Y hay fallos de nota media en campaña activa ahora mismo, sentados en la posición 400 de una cola ordenada por gravedad teórica.
Un programa que valida poco no es perezoso. Es un programa que recibió más hallazgos de los que puede procesar, y su salida natural es trabajar de arriba abajo en una lista que está en el orden equivocado.
Los dos números se multiplican, no se suman
Esta es la parte que cambia cómo se lee el resultado.
Descubrimiento rápido sin validación no mejora el programa. Entrega un montón más grande, más deprisa, y el montón sigue en el orden equivocado. El equipo encuentra más cosas y se paraliza más.
Validación alta sobre un inventario incompleto es peor de una forma más sutil: produce confianza. Usted trata muy bien todo lo que conoce, cierra el trimestre con buena métrica, y el activo que va a tumbarle nunca entró en la cuenta.
Por eso los dos números solo significan algo juntos. Combinados, dan cuatro diagnósticos.
Descubrimiento rápido y validación alta. El programa es preemptivo. Lo que queda es movilización: convertir el hallazgo validado en ticket con dueño y plazo, que es donde la mayoría se atasca tras resolver las dos primeras partes.
Descubrimiento rápido y validación baja. Usted sabe lo que tiene y no sabe lo que importa. Es la situación más común en una empresa que compró una buena herramienta de descubrimiento. El siguiente paso es la validación de explotabilidad, y no más descubrimiento.
Descubrimiento lento y validación alta. El perfil clásico de una gestión de vulnerabilidades madura sin gestión de superficie. La métrica interna se ve excelente y la superficie real no está en el informe.
Descubrimiento lento y validación baja. Donde empieza casi todo programa. El orden importa: resuelva primero el descubrimiento, porque validar bien una lista incompleta solo le ancla a la parte equivocada del problema.
Las mismas dos preguntas, giradas hacia el proveedor
Las dos pruebas funcionan mejor que cualquier pregunta sobre funcionalidades en una reunión comercial.
Pregunte cuánto tiempo pasa entre que el activo queda expuesto y la plataforma avisa. Fíjese si la respuesta habla de frecuencia de escaneo o de tiempo hasta el aviso. Escaneo diario con procesamiento semanal produce aviso semanal.
Pregunte cuánto de lo que reportan viene con prueba de explotabilidad. La respuesta honesta suele traer una distinción entre hallazgo y hallazgo validado. Si el fabricante trata ambos como lo mismo, su recuento de hallazgos está inflado por construcción.
Hay una tercera pregunta que revela más que las dos anteriores, y casi nadie la hace: ¿qué no hacen? Una cuenta de nube con permisos de más y una credencial válida en las manos equivocadas siguen invisibles desde fuera, porque ninguna de las dos responde en un puerto. Quien promete las dos mitades en un mismo producto está vendiendo el nombre de la categoría.
Una tarde, ninguna compra
El primer número se levanta con el histórico de DNS y el registro de cambios que ya existen. El segundo, con el informe que su herramienta actual ya emite.
Eso importa más de lo que parece. Significa que usted puede descubrir dónde está roto su programa antes de sentarse con cualquier proveedor, y llegar a la reunión sabiendo cuál de los cuatro cuadrantes es el suyo. Quien llega sin esos dos números compra por la palabra impresa en la portada de la propuesta, y esa palabra, ahora que toda la industria la adoptó a la vez, ya no significa nada.
Preemptivo es una afirmación. Estos dos números son su recibo.
Preguntas frecuentes
¿Qué es un buen tiempo hasta el descubrimiento?
Depende del tamaño y de la velocidad de cambio de la superficie. Como referencia práctica: horas es bueno, un día es aceptable en la mayoría de los contextos, una semana significa que el adversario tuvo seis días de ventaja en cada activo nuevo. El escaneo automatizado de internet entera corre en ciclos de horas, así que esa es la regla real.
¿Por qué la tasa de validación importa más que el total de hallazgos?
Porque el total mide el volumen que produce la herramienta, no el riesgo que usted tiene. Una cola de 3.000 elementos sin validar y una de 40 validados pueden describir la misma empresa. La segunda se puede ejecutar.
¿Mi programa de gestión de vulnerabilidades ya cubre esto?
Cubre la segunda prueba en parte, y la primera casi nunca. La gestión de vulnerabilidades trabaja sobre el activo que ya está en el inventario, así que nace ciega al activo que nadie registró. Esa es la diferencia con la gestión de exposición.
¿Se pueden mejorar los dos números sin ampliar el equipo?
El primero sí, porque el descubrimiento es trabajo de máquina y no escala con personas. El segundo depende de automatizar la validación, ya que revisar a mano una cola de miles de elementos no es viable con ningún tamaño de equipo.
¿Y si no consigo establecer la primera fecha de la prueba 1?
Ese es el resultado de la prueba. No saber cuándo un activo quedó expuesto significa que nadie está observando la superficie desde fuera, y esa es la brecha que hay que cerrar antes que cualquier otra.
¿Estas pruebas sirven para medir a un proveedor en una POC?
Sirven, y son mejores que contar hallazgos. Pida al fabricante que le muestre un activo que usted no conocía, con la fecha en que apareció, y la prueba de explotabilidad de al menos un hallazgo. Las dos cosas juntas separan un producto de un informe.