El análisis de vulnerabilidades es el proceso automatizado de examinar sistemas, redes y aplicaciones en busca de debilidades de seguridad conocidas, comparando las configuraciones y versiones de software detectadas con bases de datos de vulnerabilidades como la Base de Datos Nacional de Vulnerabilidades (NVD) y las entradas del sistema Common Vulnerabilities and Exposures (CVE). Se trata de la fase de detección sistemática que permite a una organización identificar dónde existen brechas en sus defensas.
La urgencia de realizar análisis de seguridad nunca ha sido mayor. Según el Informe de Investigaciones sobre Fugas de Datos 2025 de Verizon, el aprovechamiento de vulnerabilidades representó el 20 % de todas las fugas de datos, lo que supone un aumento interanual del 34 %. Los atacantes también actúan con mayor rapidez. Las investigaciones de VulnCheck muestran que el tiempo medio hasta la explotación se ha reducido a cinco días, y que el 28,96 % de las entradas del catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la CISA fueron explotadas el mismo día de la publicación del CVE o antes. Cuando el intervalo entre la divulgación y la explotación se mide en horas, y no en meses, el escaneo continuo se convierte en un requisito de supervivencia.
El análisis de vulnerabilidades es uno de los componentes del ciclo de vida más amplio de la gestión de vulnerabilidades, que abarca la detección, la priorización, la corrección y la verificación. Comprender dónde encaja el análisis —y dónde no— es fundamental para crear un programa de seguridad eficaz.
Los equipos de seguridad suelen utilizar indistintamente los términos «análisis», «evaluación», «pruebas de penetración» y «gestión de vulnerabilidades». No son lo mismo.
Comparación entre el análisis de vulnerabilidades y la evaluación de riesgos, las pruebas de penetración y la gestión de vulnerabilidades.
El escaneo identifica las vulnerabilidades conocidas mediante herramientas automatizadas. La evaluación integra el escaneo en un análisis más amplio que incluye una revisión manual y un análisis contextual. Las pruebas de penetración van un paso más allá, ya que intentan explotar realmente las vulnerabilidades para validar el riesgo en el mundo real. La gestión de vulnerabilidades es el programa continuo que rige todas estas actividades en toda la organización.
El proceso de análisis de vulnerabilidades consta de siete pasos secuenciales. Cada uno se basa en el anterior, y el ciclo se repite continuamente a medida que cambian los entornos.
El proceso de análisis de vulnerabilidades consta de siete pasos secuenciales, seguidos de un nuevo análisis para verificar los resultados.
El escáner envía solicitudes a los sistemas de destino, recopila respuestas sobre los puertos abiertos y las versiones de software, y luego compara esas huellas con las firmas de vulnerabilidades conocidas. ¿El análisis de vulnerabilidades está automatizado? Sí: el proceso de detección principal está automatizado, aunque la validación, la priorización y la corrección requieren el criterio humano y el contexto de la organización.
¿Qué detecta un análisis de vulnerabilidades? Los escáneres identifican parches que faltan, servicios mal configurados, credenciales predeterminadas, software obsoleto, protocolos inseguros y fallos conocidos en las aplicaciones. Sin embargo, no pueden detectar vulnerabilidades para las que no exista una firma, una limitación crítica que se aborda más adelante en esta guía.
Durante años, las organizaciones se basaron exclusivamente en el Sistema Común de Puntuación de Vulnerabilidades (CVSS) para priorizar las medidas correctivas. Las vulnerabilidades con una puntuación crítica (de 9,0 a 10,0) pasaban a ocupar el primer lugar de la lista. Este enfoque resulta cada vez más insuficiente.
CVSS v4.0, publicado junto con una nueva Guía de implementación para usuarios en enero de 2026, incorpora métricas ambientales y de amenazas que proporcionan un mejor contexto. Sin embargo, el CVSS por sí solo sigue sin responder a la pregunta más importante: «¿Se explotará realmente esta vulnerabilidad en mi entorno?».
Ahí es donde entra en juego la puntuación complementaria. El Sistema de Puntuación de Predicción de Explotación (EPSS) calcula la probabilidad de que una vulnerabilidad sea explotada en el mundo real en un plazo de 30 días. El análisis de accesibilidad determina si un atacante puede llegar realmente al componente vulnerable a través de la red. Los análisis del sector indican que el 84 % de las brechas de seguridad de 2025 se debieron a la explotación de vulnerabilidades «accesibles», no necesariamente aquellas con las puntuaciones CVSS más altas.
La realidad pone de relieve la urgencia. Según el informe DBIR 2025 de Verizon, solo el 54 % de los dispositivos vulnerables se corrigieron por completo en el plazo de un año, con una mediana de 32 días para aplicar los parches. La priorización basada en el riesgo garantiza que los limitados recursos de corrección se centren en lo que los atacantes tienen más probabilidades de aprovechar.
Los escáneres cotejan sus resultados con tres fuentes de datos principales. La NVD sirve como base de datos de referencia principal, asociando los identificadores CVE a las puntuaciones CVSS y a los productos afectados. El catálogo KEV de la CISA —que en 2025 se amplió un 20 % hasta alcanzar las 1 484 entradas— señala las vulnerabilidades que se ha confirmado que están siendo explotadas activamente en el mundo real. Los canales de avisos específicos de los proveedores aportan detalles a nivel de producto que a veces no recogen las bases de datos genéricas.
Los escáneres modernos recurren a estas tres fuentes para crear una visión por capas del riesgo. Cuando un escáner identifica una versión de software en un sistema de destino, la compara con las entradas del NVD, marca cualquier coincidencia en el catálogo KEV para que se le preste atención inmediata y consulta los avisos de los proveedores en busca de parches o soluciones provisionales.
Las organizaciones necesitan diferentes enfoques de análisis en función del entorno, el nivel de acceso y el objetivo. Existen seis tipos principales que abarcan todo el espectro.
Seis tipos de análisis de vulnerabilidades y sus casos de uso adecuados.
La elección entre análisis con credenciales y sin credenciales es una de las decisiones más importantes en un programa de análisis. Los análisis con credenciales detectan un número significativamente mayor de vulnerabilidades, ya que pueden acceder a los componentes internos del sistema: el software instalado, la configuración del registro, los permisos de los archivos y los niveles de parches. Los análisis sin credenciales ofrecen la perspectiva externa del atacante, lo cual resulta valioso para evaluar el perímetro, pero no detecta las debilidades internas.
Los análisis internos y externos abordan diferentes modelos de amenazas. Los análisis internos evalúan la red desde dentro, identificando posibles movimientos laterales y errores de configuración. Los análisis externos evalúan los activos expuestos a Internet tal y como lo haría un atacante externo. La mayoría de los marcos de seguridad requieren ambos.
Cloud contribuyeron al 43 % de todas las filtraciones de datos registradas en 2025, mientras que los dispositivos periféricos representaron el 22 % de los incidentes de explotación —lo que supone un aumento de ocho veces con respecto al año anterior, según el informe DBIR 2025 de Verizon—. Estas cifras explican por qué el análisis cloud y sin agentes se ha convertido en algo esencial.
Los escáneres basados en agentes instalan un software ligero en cada host, lo que proporciona una visibilidad más detallada y una supervisión en tiempo real. Destacan por su capacidad de evaluación continua, pero requieren su implementación, actualización y mantenimiento en todos los sistemas.
Los escáneres sin agente utilizan API y técnicas basadas en la red para evaluar los sistemas sin necesidad de instalar nada. Ofrecen una cobertura completa sin afectar al rendimiento y son esenciales para cargas de trabajo cloud efímeras, en las que los contenedores y las funciones sin servidor pueden existir durante tan solo unos minutos.
El consenso del sector se decanta por un enfoque híbrido. Los entornos tradicionales locales se benefician de la profundidad que ofrece el uso de agentes. Los entornos Cloud apuestan cada vez más por el análisis sin agentes, debido a su capacidad para cubrir cargas de trabajo efímeras y a su capacidad de detección y prevención de intrusiones en infraestructuras dinámicas.
El análisis de vulnerabilidades ocupa un lugar único en el MITRE ATT&CK : aparece en ambos lados del campo de batalla.
Por parte del adversario, T1595.002 (Análisis activo: análisis de vulnerabilidades) es un reconocimiento técnica bajo 0043. Los atacantes utilizan las mismas herramientas de análisis que los defensores para detectar vulnerabilidades explotables en los entornos objetivo. La técnica relacionada T1046 (Análisis de servicios de red) en la sección «Descubrimiento» (0007) muestra cómo los atacantes enumeran los servicios tras obtener acceso inicial.
En el aspecto defensivo, M1016 (Análisis de vulnerabilidades) es una medida de mitigación oficial que aborda técnicas como T1190 (Aplicación de explotación orientada al público), T1210 (Aprovechamiento de servicios a distancia), y T1195 (Supply Chain ). El análisis proactivo reduce la superficie de ataque que los atacantes pueden aprovechar.
Esta doble función implica que los responsables de la seguridad deben, por un lado, realizar sus propios análisis y, por otro, vigilar la actividad de exploración de los adversarios en sus redes —como barridos de puertos inusuales, comprobaciones de versiones o patrones de enumeración que indiquen que un atacante está mapeando el entorno—.
La brecha entre los requisitos mínimos de cumplimiento y las mejores prácticas de seguridad es peligrosamente amplia.
Una matriz de frecuencia basada en el riesgo ayuda a las organizaciones a asignar los recursos de análisis de forma eficaz.
Los análisis trimestrales generan «puntos ciegos» de entre 45 y 90 días. Dado que el tiempo medio hasta la explotación es de cinco días, una periodicidad trimestral implica que una organización puede estar expuesta durante semanas antes de que se ejecute el siguiente análisis.
MOVEit Transfer (CVE-2023-34362). Una vulnerabilidadde inyección SQL zero-day en la aplicación de transferencia de archivos MOVEit fue explotada antes de su divulgación, lo que afectó a más de 3.000 organizaciones en Estados Unidos y a más de 8.000 en todo el mundo. La lección: las aplicaciones conectadas a Internet requieren un análisis continuo y, aun así, las vulnerabilidades de día cero exigen métodos de detección complementarios.
Log4Shell (CVE-2021-44228). Cuando se descubrió la vulnerabilidad de Log4j, se implementaron escáneres a gran escala. Un estudio que analizó 28 proyectos a través de 140 escaneos reveló que los escáneres alcanzaron una precisión del 91,4 %: un resultado impresionante, pero insuficiente. La brecha se debía a las dependencias transitivas que los escáneres no podían detectar. El aviso de la CISA hacía hincapié en el uso de múltiples métodos de escaneo para lograr una cobertura completa.
Trivy ataque a la cadena de suministro (marzo de 2026). Un escáner de vulnerabilidades de código abierto se vio comprometido a su vez a través de un ataque a la cadena de suministro en varias fases. La lección: las organizaciones deben verificar la integridad de sus herramientas de análisis, no solo los resultados de los análisis.
React2Shell (CVE-2025-55182). Una vulnerabilidad con una puntuación CVSS de 10,0 que afecta a más de 592 000 dominios, de los cuales más de 172 000 se han confirmado como vulnerables y más de 30 000 ya habían sido comprometidos en el momento de su descubrimiento. El plazo para su explotación se redujo a unas pocas horas, lo que refuerza la importancia de realizar análisis continuos con alertas automatizadas.
Para crear un programa de análisis eficaz no basta con elegir las herramientas adecuadas. Estas prácticas recomendadas abordan las deficiencias más habituales.
El informe DBIR 2025 de Verizon reveló que solo el 54 % de los dispositivos vulnerables se corrigieron por completo en el plazo de un año, con una mediana de 32 días para aplicar los parches. Los dispositivos periféricos representaron el 22 % de los incidentes de explotación —lo que supone un aumento de ocho veces con respecto al año anterior—, lo que pone de relieve la necesidad de ampliar los análisis más allá de los entornos tradicionales de servidores y terminales.
Una evaluación honesta de los puntos ciegos del escáner evita una confianza excesiva que puede resultar peligrosa.
Los falsos positivos —resultados de análisis que señalan erróneamente una vulnerabilidad que en realidad no existe— minan la confianza en los programas de análisis y hacen perder tiempo a los analistas.
Entre las causas más comunes se encuentran las firmas obsoletas, las discrepancias en la cadena de versión —cuando se ha retroportado un parche sin cambiar el número de versión— y las diferencias de entorno entre las condiciones de prueba del escáner y la configuración real del sistema.
Las estrategias de reducción incluyen la realización de análisis con credenciales para lograr una mayor precisión, mantener actualizadas las firmas del escáner, validar los resultados mediante un análisis contextual y correlacionar los resultados entre varias herramientas. Los análisis con credenciales son especialmente eficaces, ya que permiten verificar los niveles reales de parches en lugar de basarse en la detección externa de versiones.
Los principales marcos normativos exigen la realización de análisis de vulnerabilidades con una periodicidad determinada. Esta tabla de correspondencias de cumplimiento ofrece una referencia rápida.
Requisitos del marco de cumplimiento normativo para el análisis de vulnerabilidades.
Las organizaciones de la UE se enfrentan a una presión adicional en virtud de la Directiva NIS 2, que coincide en un 70-80 % con los controles de la norma ISO 27001 y prevé sanciones de hasta 10 millones de euros en caso de incumplimiento. La norma PCI DSS v4.0 se aplica a nivel mundial a cualquier organización que procese datos de tarjetas de pago. Las organizaciones que operan en múltiples marcos normativos se benefician de la adaptación a los requisitos más estrictos —por lo general, la periodicidad semanal o mensual del Control 7 del CIS— para cumplir con todos los marcos simultáneamente.
El panorama del análisis de vulnerabilidades está evolucionando rápidamente. Hay tres cambios que definen el enfoque actual.
De periódico a continuo. El análisis continuo de vulnerabilidades sustituye los intervalos trimestrales o mensuales por una supervisión permanente. Teniendo en cuenta que el tiempo medio para explotar una vulnerabilidad es de cinco días, cualquier laguna en la cobertura del análisis supone una oportunidad para los atacantes. El análisis continuo se integra en los marcos de gestión continua de la exposición a amenazas (CTEM), en los que el análisis constituye uno de los elementos de un programa más amplio de evaluación de la superficie de ataque y reducción de riesgos.
De la priorización basada únicamente en CVSS a la priorización multifactorial. CVSS v4.0 mejora la precisión de la puntuación, pero los programas líderes ahora combinan el EPSS, el análisis de accesibilidad y las fuentes de inteligencia sobre amenazas para centrarse en las vulnerabilidades que son a la vez explotables y accesibles en su entorno específico.
Desde análisis periódicos hasta el análisis de la infraestructura como código. Los entornos Cloud exigen nuevos enfoques: análisis basados en API, análisis de imágenes de contenedores y revisión de la infraestructura como código que detecte errores de configuración antes de la implementación.
La filosofía Vectra AI parte de una premisa sencilla: dar por hecho que se ha producido una intrusión. Cuando el 28,96 % de las vulnerabilidades explotadas se utilizan como arma el mismo día de la publicación del CVE o incluso antes, incluso el mejor programa de análisis se enfrentará a lagunas. El análisis de vulnerabilidades identifica los puntos débiles. La detección de amenazas basada en IA identifica lo que ocurre cuando se explotan esos puntos débiles: el movimiento lateral, la escalada de privilegios y la preparación de datos que siguen al acceso inicial. Attack Signal Intelligence al escaneo de vulnerabilidades. Detecta lo que el escaneo no puede: zero-day , los ataques basados en la identidad y los comportamientos posteriores a la compromisión que ninguna base de datos de firmas contiene. Juntos, el escaneo de vulnerabilidades y la detección y respuesta de red forman una postura defensiva completa: encontrar debilidades antes de que sean explotadas y detectar el comportamiento del atacante cuando la explotación tiene éxito.
El ámbito del análisis de vulnerabilidades se enfrentará a una importante evolución en los próximos 12 a 24 meses, impulsada por tres factores que convergen.
Los ataques se están acelerando. La reducción del tiempo que transcurre desde el ataque hasta su explotación —de semanas a días, y cada vez más a horas— empujará a las organizaciones a adoptar capacidades de análisis en tiempo real integradas con respuestas automatizadas. La cronología de explotación de React2Shell, en la que más de 30 000 dominios fueron infectados con puertas traseras antes de que la mayoría de las organizaciones completaran su primer análisis, nos da una idea de lo que nos depara el futuro.
La inteligencia artificial está transformando tanto el ataque como la defensa. Los atacantes utilizan la inteligencia artificial para identificar y explotar vulnerabilidades con mayor rapidez. Las herramientas de análisis defensivo están incorporando el aprendizaje automático para mejorar la precisión de la detección, reducir los falsos positivos y predecir qué vulnerabilidades son las más propensas a ser explotadas en el futuro. La adopción de los sistemas de gestión de seguridad de perímetro (EPSS) seguirá creciendo a medida que las organizaciones dejen de basar su priorización únicamente en el CVSS.
La presión normativa va en aumento. La aplicación de la Directiva NIS2 en toda la UE, los requisitos ampliados de la norma PCI DSS v4.0 y los nuevos marcos normativos en torno a las infraestructuras críticas impulsarán a las organizaciones a adoptar programas de análisis más frecuentes y exhaustivos. Las organizaciones que hayan establecido programas que apenas cumplan los requisitos mínimos de cumplimiento deberán pasar a un sistema de supervisión continua.
Las propias herramientas de análisis se convierten en objetivos. El incidente de seguridad en la cadena de suministro de Trivy en 2026 demostró que los escáneres de vulnerabilidades son objetivos muy valiosos para los atacantes. Cabe esperar un mayor escrutinio en torno a la verificación de la integridad de los escáneres, las actualizaciones firmadas y la seguridad de la cadena de suministro de las herramientas de seguridad.
Las organizaciones que se preparan para estos cambios deberían invertir en tres áreas: una infraestructura de análisis continuo que elimine las lagunas entre los ciclos de análisis; una priorización multifactorial que combine el CVSS, el EPSS, la accesibilidad y la inteligencia sobre amenazas; y capacidades de detección de comportamientos que detecten los intentos de explotación cuando el análisis, inevitablemente, pase algo por alto.
El análisis de vulnerabilidades ya no es opcional: se trata de una práctica de seguridad fundamental que toda organización debe implementar de manera eficaz. Dado que la explotación de vulnerabilidades es la causa del 20 % de las filtraciones, que el tiempo necesario para explotarlas se ha reducido a cinco días y que cada año se publican 50 000 nuevas CVE, el coste de descuidar el análisis de vulnerabilidades aumenta cada trimestre.
El camino a seguir exige ir más allá de los requisitos mínimos de cumplimiento. Crea un programa basado en el riesgo que realice análisis continuos, establezca prioridades utilizando el CVSS junto con el EPSS y el análisis de accesibilidad, y abarque todo el entorno, incluidas cloud , los contenedores y los dispositivos periféricos. Combina varios métodos de análisis para lograr una cobertura exhaustiva e incorpora la detección de comportamientos para detectar lo que los escáneres no pueden detectar.
Empiece por realizar un inventario claro de activos, implemente un análisis continuo de sus sistemas más críticos y siga avanzando a partir de ahí. Si su organización está preparada para reducir la brecha entre la detección de vulnerabilidades y la detección activa de amenazas, descubra cómo la Vectra AIAttack Signal Intelligence complementa los programas de análisis al detectar comportamientos de los atacantes que ninguna base de datos de vulnerabilidades puede captar.
El análisis de vulnerabilidades es el proceso automatizado de examinar sistemas, redes y aplicaciones en busca de debilidades de seguridad conocidas, comparando las configuraciones detectadas con bases de datos de vulnerabilidades. El NIST lo define como la identificación sistemática de vulnerabilidades conocidas en la infraestructura informática. Los escáneres envían sondeos a los sistemas de destino, recopilan información sobre el software instalado y las configuraciones, y luego comparan esos resultados con bases de datos como la Base de Datos Nacional de Vulnerabilidades (NVD) y el catálogo de vulnerabilidades explotadas conocidas de la CISA. El proceso es automatizado y repetible, lo que lo hace escalable en entornos de grandes empresas. El análisis de vulnerabilidades es un componente dentro del ciclo de vida más amplio de la gestión de vulnerabilidades, que también incluye la priorización, la corrección y la verificación. Dado que la explotación de vulnerabilidades representa ahora el 20 % de todas las brechas de seguridad, el análisis se ha convertido en un requisito fundamental para cualquier programa de seguridad.
El análisis de vulnerabilidades sigue un proceso de siete pasos. En primer lugar, el escáner detecta todos los activos incluidos en el alcance: servidores, terminales, dispositivos de red y cloud . En segundo lugar, enumera los objetivos identificando los puertos abiertos, los servicios en ejecución y las versiones de software. En tercer lugar, detecta vulnerabilidades comparando las configuraciones detectadas con las bases de datos CVE y los avisos de los proveedores. En cuarto lugar, valida los hallazgos correlacionando los resultados y filtrando el ruido. En quinto lugar, puntúa y prioriza utilizando CVSS, EPSS y el contexto empresarial. En sexto lugar, genera informes procesables con clasificaciones de gravedad y directrices de corrección. Por último, las organizaciones vuelven a escanear para verificar que las medidas de corrección han resuelto las vulnerabilidades identificadas. El ciclo completo se repite continuamente a medida que los entornos cambian, se revelan nuevas vulnerabilidades y se actualizan los sistemas.
El análisis de vulnerabilidades identifica los puntos débiles conocidos mediante herramientas automatizadas que comparan las configuraciones del sistema con bases de datos de vulnerabilidades. Las pruebas de penetración comprueban si determinadas vulnerabilidades pueden explotarse realmente mediante ataques simulados llevados a cabo por evaluadores cualificados. El análisis es amplio, automatizado y repetible, y abarca entornos completos en cuestión de horas. Las pruebas de penetración son específicas, manuales y requieren muchos recursos, centrándose en sistemas concretos o vías de ataque. El análisis le indica que «este sistema tiene una debilidad conocida». Las pruebas de penetración le indican que «un atacante puede explotar esta debilidad para lograr este impacto específico». La mayoría de los programas de seguridad necesitan ambos: análisis para una cobertura continua y pruebas de penetración para un examen en profundidad periódico.
La frecuencia depende de la importancia de los activos y de los requisitos de cumplimiento. La norma PCI DSS exige, como mínimo, análisis internos y externos trimestrales. El control 7 del CIS recomienda análisis semanales para los activos conectados a Internet. Las mejores prácticas de seguridad aconsejan el análisis continuo de los sistemas críticos. Dado que el tiempo medio hasta la explotación es de cinco días, los análisis trimestrales crean «puntos ciegos» de entre 45 y 90 días durante los cuales los atacantes pueden descubrir y explotar vulnerabilidades. Lo más eficaz es un enfoque basado en el riesgo: supervisión continua de los sistemas críticos conectados a Internet, análisis semanales de los entornos de producción estándar, análisis posteriores a la implementación de los sistemas de desarrollo y análisis mensuales o trimestrales de los activos internos de bajo riesgo.
Los escáneres tienen cinco puntos ciegos importantes. No pueden detectar zero-day porque no existe ninguna firma. No pueden identificar fallos en la lógica de negocio que requieran comprender los flujos de trabajo específicos de cada aplicación. Tienen una visibilidad limitada de las dependencias transitivas, como demostró Log4Shell, cuando los escáneres solo alcanzaron una precisión del 91,4 % debido a que pasaron por alto dependencias anidadas. No pueden evaluar vulnerabilidades dependientes del contexto sin acceso con credenciales. Y no pueden detectar la explotación activa: un escáner encuentra debilidades, pero detectar a un atacante que las aprovecha requiere capacidades de detección de amenazas basadas en el comportamiento. Comprender estas limitaciones evita una confianza excesiva y peligrosa, y ayuda a las organizaciones a construir defensas en capas.
Sí. El requisito 11.3 de la norma PCI DSS v4.0 exige que se realicen, como mínimo, análisis de vulnerabilidades internos y externos cada trimestre. Los análisis externos deben ser realizados por un proveedor de análisis autorizado (ASV) certificado por el Consejo de Normas de Seguridad PCI. Todas las vulnerabilidades de alto riesgo y críticas identificadas en los análisis deben resolverse antes del siguiente análisis trimestral. Más allá de la norma PCI DSS, existen múltiples marcos que exigen la realización de análisis. La norma NIST SP 800-53 RA-5 exige análisis periódicos y análisis tras cambios significativos en el sistema. Los controles CIS recomiendan análisis automatizados semanales o mensuales. La norma ISO 27001 exige un proceso documentado para la gestión de vulnerabilidades técnicas.
El análisis continuo de vulnerabilidades sustituye los ciclos de análisis periódicos —trimestrales, mensuales o semanales— por una supervisión permanente que detecta nuevas vulnerabilidades tan pronto como se dan a conocer o se introducen. Este cambio viene impulsado por el hecho de que el 28,96 % de las vulnerabilidades explotadas se utilizan con fines maliciosos el mismo día de la publicación del CVE o incluso antes. Cualquier intervalo entre análisis representa una ventana de exposición. El análisis continuo se integra con los marcos de gestión continua de la exposición a amenazas (CTEM), incorporando los resultados de los análisis a un programa más amplio de evaluación y priorización de riesgos. Es cada vez más esencial para cloud , donde la infraestructura cambia constantemente a través de implementaciones automatizadas, la orquestación de contenedores y las arquitecturas sin servidor.