Hace unos días publicamos IA y vulnerabilidades: por qué el compliance no te salva de ser la próxima víctima. Ese artículo terminaba en una idea: dejar de preguntarle a los datos “¿qué tan grave es?” y empezar a preguntar “¿esto me va a explotar esta semana?”.
Esa idea no se quedó en el blog. La convertimos en una herramienta: RealRisk, un consultor de CVEs sin cuenta que cruza la severidad (CVSS), la probabilidad de explotación (EPSS) y la explotación confirmada (CISA KEV) en una sola vista, con un análisis ejecutivo en español.
RealRisk no nació de un experimento, sino de aplicar criterio y experiencia acumulada a un problema que conocemos bien, con la misma filosofía de nuestras otras herramientas. Las decisiones de diseño que tomamos parten de trampas que ya teníamos identificadas de la práctica, las mismas en las que cae la mayoría de las herramientas de gestión de vulnerabilidades. Estas son las tres que más pesan.
Trampa 1: lo que un score te da es riesgo inherente, no residual
Cualquier herramienta que mire solo el CVE (su CVSS base, su EPSS, si está en el KEV) te entrega riesgo inherente: el riesgo intrínseco de la vulnerabilidad, sin saber nada de tu entorno. No conoce tu exposición real, ni si tienes un WAF adelante, ni un EDR en el endpoint, ni si ese servicio está segmentado o publicado a internet.
El riesgo residual, el que de verdad importa para decidir, aparece recién cuando pones tu contexto encima. Una vulnerabilidad de riesgo inherente crítico puede tener riesgo residual bajo en tu red si el activo no está expuesto y tienes controles compensatorios. Y al revés.
Por eso RealRisk es explícito sobre lo que entrega: el piso, el riesgo inherente bien calculado y en español; el techo lo pones tú con el conocimiento de tu entorno. Una herramienta que te promete “riesgo residual” sin conocer tu red te está vendiendo humo.
Trampa 2: a veces hay que corregir algo con “baja probabilidad”
El EPSS es un pronóstico: la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, calculada para toda la población de internet. El KEV de CISA es otra cosa: un hecho observado. Si está en el KEV, ya la usaron en ataques reales.
Cuando los dos no coinciden, manda el hecho, no el pronóstico. Es habitual encontrar vulnerabilidades en el KEV con un EPSS bajísimo, y no es una contradicción: el EPSS modela explotación masiva y remota, pero hay vulnerabilidades que no encajan en ese molde (un compromiso de cadena de suministro, un ataque dirigido a un producto de nicho) y aun así ya causaron daño real. Por eso RealRisk, ante explotación confirmada, recomienda parchado inmediato aunque el número de probabilidad se vea tranquilizador. El número no te puede tranquilizar de algo que ya pasó.
Trampa 3: el falso positivo que más cuesta, los backports de distro
Esta es la que hace fallar a casi todos los verificadores genéricos. Debian, Ubuntu y Red Hat corrigen vulnerabilidades sin subir el número de versión del software: aplican el parche por dentro del paquete y mantienen la versión base (por ejemplo, 1.1.1f-1ubuntu2.19). Una herramienta que compara solo contra la versión “de fábrica” del proyecto marca como vulnerable algo que está parchado hace meses.
El resultado es un falso positivo, y los falsos positivos son veneno: cuando una herramienta grita lobo seguido, el equipo deja de creerle, que es lo último que necesita alguien que ya vive con fatiga de alertas. Resolverlo bien exige conocer la versión corregida por cada distribución, mirar el paquete instalado y no solo el banner, y cuando no se puede determinar con certeza, decirlo en vez de inventar una alarma. Es un problema que tenemos identificado y en el que ya estamos trabajando. Todavía no está resuelto en RealRisk, pero pronto tendrán noticias.
Por qué abierto y para todos
Hay una frase que se repite en seguridad: una cadena es tan fuerte como su eslabón más débil. En una sociedad hiperconectada eso no es una metáfora. El sitio mal protegido de una organización chica, el equipo de quien no tiene presupuesto, el sistema de quien nunca tuvo acceso a herramientas de calidad: cada uno es un eslabón, y cuando se rompe, el daño no se queda ahí.
Por eso RealRisk no tiene costo ni pide cuenta, y no es una estrategia de enganche. Es la convicción con la que nos formamos, la del software libre y el open source: las buenas herramientas no deberían ser un privilegio. No estamos regalando trabajo, estamos compartiendo conocimiento. Una herramienta completamente funcional, que aporte valor real a quien no puede pagar por ella, fortalece toda la cadena, y esa cadena nos incluye a todos.
Es la misma idea detrás de FreeScan, nuestra herramienta de postura web, y de todo lo que liberamos en Asentic: dar algo útil antes de pedir nada a cambio.
Lo que no cambia
La herramienta no reemplaza el criterio, lo amplifica. RealRisk te dice qué mirar y por qué; la decisión de qué hacer con eso, con el contexto de tu organización, sigue siendo tuya. Esa fue la conclusión del artículo anterior y sigue siendo la misma: la IA y la automatización cambiaron la velocidad del juego, pero no la pregunta que importa.
RealRisk no es una herramienta perfecta, y no pretende serlo. Es un aporte bien encaminado y bien intencionado para quienes se dedican a proteger y cargan, día a día, con la fatiga de demasiadas alertas. Si te ahorra una mala decisión o un rato de ruido, cumplió su propósito. Puedes probarlo en realrisk.asentic.cl con cualquier CVE que tengas en la mira.
Y te dejamos una pregunta, porque nos interesa de verdad cómo lo resuelves tú: cuando tienes diez vulnerabilidades sobre la mesa y tiempo para tres, ¿qué usas para decidir cuáles van primero, el score, lo que exige la norma, o el riesgo real? ¿Y qué es lo que más te cuesta de esa decisión?
