La evaluación de vulnerabilidades es un proceso sistemático destinado a identificar, clasificar y priorizar los puntos débiles de seguridad en los sistemas, redes y aplicaciones de una organización antes de que los atacantes puedan aprovecharlas. El NIST define la evaluación de vulnerabilidades como un «examen sistemático de un sistema o producto de información para determinar la idoneidad de las medidas de seguridad, identificar deficiencias de seguridad, proporcionar datos a partir de los cuales predecir la eficacia de las medidas de seguridad propuestas y confirmar la idoneidad de dichas medidas tras su implementación».
En la práctica, una evaluación de vulnerabilidades de seguridad ofrece a las organizaciones una forma estructurada de responder a una pregunta sencilla: ¿dónde estamos expuestos? La respuesta es más importante que nunca. El mercado de los servicios de evaluación de vulnerabilidades, valorado en 5.580 millones de dólares en 2025, está creciendo a una tasa compuesta anual del 9,2 %, lo que refleja la urgencia que sienten las organizaciones por subsanar las lagunas de visibilidad.
Una distinción fundamental que conviene comprender desde el principio. La evaluación de vulnerabilidades es una actividad puntual, un componente dentro del ciclo de vida más amplio de la gestión de vulnerabilidades. La evaluación identifica los puntos débiles. El ciclo de vida de la gestión de vulnerabilidades se encarga del seguimiento continuo, la corrección, la verificación y la gobernanza en todo el programa.
Entender cuál es el lugar que ocupa la evaluación de vulnerabilidades en relación con las pruebas de penetración y la evaluación de riesgos evita confusiones sobre el alcance y la asignación inadecuada de recursos.
Tabla: Comparación entre la evaluación de vulnerabilidades y otras actividades de seguridad relacionadas.
La evaluación de vulnerabilidades y las pruebas de penetración (VAPT) suelen tratarse conjuntamente, y con razón. La evaluación de vulnerabilidades identifica los puntos débiles de forma general mediante análisis automatizados, mientras que las pruebas de penetración comprueban si determinadas vulnerabilidades pueden explotarse realmente mediante ataques simulados. La evaluación de vulnerabilidades abarca un amplio espectro. Las pruebas de penetración profundizan en el sistema. La mayoría de los programas bien desarrollados utilizan ambas: la evaluación de vulnerabilidades para una cobertura continua y las pruebas de penetración para la validación periódica de las vías de explotación críticas.
Por el contrario, una evaluación de riesgos se lleva a cabo a nivel estratégico. Evalúa el impacto en el negocio de las amenazas y vulnerabilidades identificadas en el contexto de las prioridades de la organización, sus activos y su tolerancia al riesgo.
Un proceso de evaluación de vulnerabilidades en cinco pasos transforma los datos brutos del análisis en prioridades de corrección que se pueden poner en práctica. Cada paso se basa en el anterior, y el ciclo se repite continuamente.

La planificación y la definición del alcance sientan las bases. Los equipos determinan qué activos entran dentro del alcance —servidores locales, cloud , contenedores, dispositivos IoT— y establecen cuáles son los criterios de éxito. Sin una definición clara del alcance, las evaluaciones pueden pasar por alto sistemas críticos o malgastar recursos en objetivos irrelevantes.
El inventario de activos permite crear un inventario completo. No se puede evaluar lo que no se sabe que existe. Este paso identifica los dispositivos gestionados y no gestionados, la «TI en la sombra», cloud y las integraciones de terceros en toda la red moderna. Las organizaciones que se pasan a entornos híbridos suelen descubrir entre un 15 % y un 30 % más de activos de los que figuran en sus registros de la CMDB.
El análisis de vulnerabilidades combina herramientas automatizadas con revisiones manuales de la configuración. Los escáneres automatizados comparan los sistemas con bases de datos de CVE conocidas, mientras que la revisión manual detecta fallos lógicos y errores de configuración que los escáneres pasan por alto. Comprender cómo funciona el análisis de vulnerabilidades es esencial para interpretar los resultados con precisión.
El análisis y la priorización son los aspectos en los que la metodología de evaluación cobra mayor importancia. La puntuación CVSS por sí sola resulta insuficiente. Menos del 1 % de las vulnerabilidades CVE llegan a ser objeto de ataques, lo que hace que un enfoque basado únicamente en el CVSS resulte peligrosamente impreciso. Una priorización eficaz combina las puntuaciones base del CVSS con los datos del Sistema de Puntuación de Predicción de Explotación (EPSS), la criticidad de los activos, el contexto de la inteligencia sobre amenazas y el impacto en el negocio. Este enfoque multifactorial garantiza que los equipos solucionen primero lo que realmente importa, y no solo lo que obtiene la puntuación más alta sobre el papel.
La elaboración de informes y la corrección cierran el ciclo. Un informe de evaluación de vulnerabilidades documenta los hallazgos con clasificaciones de riesgo, activos afectados, pruebas y medidas correctivas recomendadas, junto con acuerdos de nivel de servicio (SLA) vinculados a la gravedad. Las vulnerabilidades críticas pueden requerir plazos de corrección de 72 horas. Los hallazgos de gravedad media pueden tener SLA de 30 días. El informe se integra directamente en los flujos de trabajo de respuesta a incidentes cuando se detecta una explotación activa.
El tiempo medio hasta la aplicación del parche es de 32 días, pero el 28 % de los ataques se producen en las 24 horas siguientes a la divulgación. Esta brecha entre el descubrimiento y la corrección define el reto al que debe hacer frente todo programa de evaluación de vulnerabilidades.
Seis tipos distintos de evaluaciones de vulnerabilidad garantizan la cobertura de todas las capas de la superficie de ataque. La elección del tipo adecuado —o de la combinación adecuada— depende del entorno, el perfil de riesgo y los requisitos de cumplimiento normativo.
Tabla: Seis tipos de evaluaciones de vulnerabilidad y su ámbito de aplicación.
Las evaluaciones de vulnerabilidades de red analizan la infraestructura de seguridad de la red en busca de puertos abiertos, servicios mal configurados y vulnerabilidades conocidas en los dispositivos de red. El informe DBIR 2025 de Verizon reveló que el 22 % de las brechas de seguridad provocadas por el aprovechamiento de vulnerabilidades tuvieron como objetivo dispositivos periféricos, lo que convierte la evaluación de la red en una prioridad fundamental.
Las evaluaciones de aplicaciones web se centran en la capa de aplicación y comprueban si existen fallos de inyección, autenticación defectuosa y configuraciones incorrectas de las API. Dada la creciente complejidad de las aplicaciones y la aceleración de los procesos de implementación gracias a los flujos de CI/CD, la evaluación de vulnerabilidades de las aplicaciones debe integrarse directamente en el ciclo de vida del desarrollo.
Las evaluacionesCloud los contenedores abordan los retos específicos de cloud : cargas de trabajo efímeras, modelos de responsabilidad compartida, plantillas de infraestructura como código y vulnerabilidades en las imágenes de contenedores. Las herramientas de análisis tradicionales, diseñadas para entornos estáticos, pasan por alto por completo estos activos dinámicos.
Tres incidentes muy sonados ilustran lo que ocurre cuando los programas de evaluación de vulnerabilidades no dan la talla.
Equifax (2017). Un análisis de vulnerabilidades se centró en el directorio raíz, pero pasó por alto un subdirectorio de Apache Struts que contenía la vulnerabilidad CVE-2017-5638. El resultado fue la exposición de 147 millones de registros y un coste total de 1380 millones de dólares. La lección es clara: es imprescindible contar con un inventario exhaustivo de activos y definir correctamente el alcance del análisis.
MOVEit (2023). Los autores de la amenaza CL0P aprovecharon una zero-day (CVE-2023-34362) en una herramienta de transferencia de archivos muy utilizada. La filtración de datos de MOVEit afectó a más de 2700 organizaciones y a 93,3 millones de personas. La lección es que el software de terceros requiere una evaluación de la divulgación de vulnerabilidades por parte del proveedor y una evaluación de riesgos de la cadena de suministro, no solo un análisis interno.
Stryker (2026). En marzo de 2026, unos atacantes utilizaron la solución de gestión de dispositivos móviles (MDM) Microsoft Intune para borrar entre 80 000 y 200 000 dispositivos en una importante empresa de tecnología médica, sin necesidad de desplegar ningún tipo de malware. No se utilizó ningún CVE. La lección que hay que extraer es que la evaluación de vulnerabilidades debe ir más allá del análisis tradicional de CVE para abarcar las configuraciones del plano cloud , la seguridad de la identidad y la destrucción al estilo del ransomware mediante herramientas de administración legítimas.
En conjunto, estas filtraciones de datos ponen de manifiesto que una evaluación eficaz requiere un alcance exhaustivo, tener en cuenta a terceros y una cobertura que vaya más allá de la base de datos CVE.
Los costes de las evaluaciones de vulnerabilidad oscilan entre los 1.000 dólares, para análisis de entornos pequeños, y más de 50.000 dólares, para proyectos a escala empresarial, dependiendo del alcance, la complejidad del entorno y de si la evaluación es interna o la realiza un tercero. Una guía de precios de evaluaciones de vulnerabilidad desglosa los factores de coste habituales por tipo de evaluación. Los analistas del sector ofrecen referencias de costes más detalladas sobre las evaluaciones de vulnerabilidad.
El cálculo del retorno de la inversión es sencillo. Compara el coste de las evaluaciones periódicas con el coste medio de una filtración de datos, que no deja de aumentar año tras año. En las reuniones con la dirección, presenta la evaluación de vulnerabilidades no como un gasto, sino como una medida de reducción de riesgos con beneficios cuantificables.
El consejo genérico de «evaluar trimestralmente» no es suficiente. La frecuencia de las evaluaciones debe ajustarse a la importancia de los activos, la exposición a las amenazas y los requisitos de cumplimiento.
Tabla: Matriz de frecuencia de la evaluación de vulnerabilidades basada en el riesgo.
Los datos respaldan las prácticas recomendadas de realizar análisis con una frecuencia elevada. El 28 % de los ataques se producen en las 24 horas siguientes a la divulgación. Los análisis trimestrales crean «puntos ciegos» de entre 45 y 90 días, es decir, periodos en los que las vulnerabilidades recién divulgadas permanecen sin parchear y sin detectar. La norma PCI DSS v4.0 establece como mínimo los análisis trimestrales, mientras que los controles CIS v8 recomiendan análisis semanales para los activos críticos.
Un programa eficaz de evaluación de vulnerabilidades combina enfoques automatizados y manuales. El análisis automatizado ofrece amplitud, ya que examina rápidamente miles de activos comparándolos con bases de datos de vulnerabilidades conocidas. Las pruebas manuales aportan profundidad, ya que detectan fallos de lógica, vulnerabilidades en la lógica de negocio y configuraciones erróneas complejas que las herramientas automatizadas pasan por alto.
Entre las mejores prácticas para desarrollar un programa consolidado se incluyen:
Los falsos positivos en las evaluaciones de vulnerabilidad constituyen uno de los retos operativos más persistentes. Los falsos positivos hacen perder tiempo a los analistas, minan la confianza en las herramientas de análisis y provocan una «fatiga de alertas» que lleva a los equipos a restar prioridad a los hallazgos, incluidos los reales. Entre las causas más comunes se encuentran las bases de datos de firmas desactualizadas, las lagunas en el contexto del entorno y la identificación errónea de las versiones de software.
Las estrategias de reducción de falsos positivos en el análisis de vulnerabilidades basadas en el aprendizaje automático alcanzan ahora tasas de reducción del 92 % al 98 % gracias a la correlación de los resultados del análisis con el contexto de ejecución, el análisis de accesibilidad y la información sobre exploits. Un flujo de trabajo de clasificación estructurado —que incluye la deduplicación automatizada, el enriquecimiento contextual, la revisión manual de las alertas restantes y el traspaso de los hallazgos confirmados— permite que los analistas se centren en las amenazas reales.
Según los datos del sector, solo el 54 % de las vulnerabilidades se corrigen por completo. Reducir el ruido de los falsos positivos mejora directamente esta cifra, ya que garantiza que los recursos destinados a la corrección se centren en los hallazgos reales.
Las herramientas de evaluación de vulnerabilidades se clasifican en cuatro categorías principales. Los escáneres de red identifican los puntos débiles de la infraestructura en puertos, servicios y configuraciones. Los escáneres de aplicaciones web comprueban la presencia de vulnerabilidades incluidas en la lista OWASP Top 10 y de vulnerabilidades específicas de las API. cloud de contenedores y cloud se centran en las cargas de trabajo efímeras y en las plantillas de «Infraestructura como Código» (IaC). Los auditores de configuración validan los sistemas según los parámetros de referencia del CIS y las normas de refuerzo de seguridad.
En lugar de recomendar herramientas concretas, céntrese en las capacidades. Las herramientas eficaces de detección y evaluación de amenazas deben ofrecer análisis tanto de sistemas autenticados como no autenticados, integración con plataformas de gestión de incidencias y de orquestación, priorización basada en el riesgo que vaya más allá del mero CVSS, y generación de informes alineados con los indicadores clave de rendimiento (KPI) del programa de gestión de vulnerabilidades.
Los principales marcos normativos exigen la realización de evaluaciones de vulnerabilidad a intervalos determinados, lo que hace que el mapeo del cumplimiento sea esencial para cualquier programa de evaluación de vulnerabilidades.
Tabla: Requisitos del marco normativo para la evaluación de vulnerabilidades.
Desde el punto de vista de los marcos de seguridad, MITRE ATT&CK asigna la evaluación de vulnerabilidades a varias técnicas. T1595.002 (Análisis de vulnerabilidades) describe cómo los adversarios llevan a cabo el reconocimiento mediante el análisis de vulnerabilidades. T1190 (Aprovechamiento de aplicaciones expuestas al público) documenta la vía de explotación que la evaluación de vulnerabilidades pretende prevenir. M0916 (Análisis de vulnerabilidades) define el análisis de vulnerabilidades como una medida defensiva específica. Las evaluaciones de riesgos y vulnerabilidades de la CISA proporcionan orientación gubernamental adicional para estructurar los programas de evaluación.
El paso de una evaluación de vulnerabilidades periódica a una continua refleja un cambio fundamental en la dinámica de las amenazas. Con una previsión de aproximadamente 59 000 CVE para 2026, los análisis puntuales no pueden seguir el ritmo.
La evaluación de vulnerabilidades basada en IA utiliza el aprendizaje automático para establecer prioridades de forma inteligente, programar la corrección de forma predictiva y realizar una clasificación automatizada. Los modelos de aprendizaje automático correlacionan las puntuaciones CVSS, las probabilidades EPSS, la criticidad de los activos y la inteligencia sobre amenazas activas para identificar ese 1-2 % de vulnerabilidades que realmente requieren atención inmediata. Sin embargo, hay que equilibrar el optimismo con la realidad. Los asistentes de IA son objeto de críticas por su velocidad y precisión: las herramientas actuales de revisión de código con IA solo alcanzan una tasa de código seguro del 56 %, el procesamiento sigue siendo lento y persisten los falsos positivos.
La gestión continua de la exposición a amenazas (CTEM) amplía la evaluación más allá de los CVE para abarcar las configuraciones erróneas, las fugas de credenciales, las vulnerabilidades de la superficie de ataque y los riesgos de identidad. El informe «Global Cybersecurity Outlook 2026» del Foro Económico Mundial señala que el 87 % de los encuestados identifica las vulnerabilidades relacionadas con la inteligencia artificial como la categoría de riesgo de más rápido crecimiento, lo que pone de relieve que el análisis tradicional de CVE por sí solo deja importantes puntos ciegos.
La evaluación de vulnerabilidades específicas de la IA es una disciplina emergente que abarca el análisis de modelos, las pruebas de seguridad de los modelos de lenguaje grande (LLM), prompt injection y la validación de la cadena de suministro de la IA. A medida que las organizaciones implementan más sistemas de IA, evaluar estos modelos en busca de vulnerabilidades adversarias cobra tanta importancia como el análisis de la infraestructura tradicional.
Vectra AI bajo la filosofía de «asumir que el sistema está comprometido». La evaluación de vulnerabilidades identifica los puntos débiles antes de que sean explotados, pero los atacantes encontrarán inevitablemente brechas que las evaluaciones pasan por alto. Zero-day , las configuraciones erróneas del plano cloud y los ataques basados en identidades, como el incidente de Stryker de 2026, eluden por completo las evaluaciones de vulnerabilidades tradicionales. Aquí es donde la detección continua de amenazas mediante IA aporta valor: no sustituyendo a la evaluación de vulnerabilidades, sino detectando lo que esta no puede detectar. Cuando los atacantes explotan vulnerabilidades sin parchear o aprovechan los puntos ciegos de la detección de amenazas de identidad, Attack Signal Intelligence™ detecta los comportamientos posteriores a la explotación —movimiento lateral, escalada de privilegios, preparación de datos— que revelan una compromisión activa. En combinación con la detección y respuesta de red, esto crea un modelo de defensa en profundidad en el que la evaluación de vulnerabilidades reduce la exposición y la detección de comportamientos detecta lo que se le escapa.
El panorama de la evaluación de vulnerabilidades está evolucionando rápidamente en varios aspectos. En los próximos 12 a 24 meses, las organizaciones deben prepararse para tres cambios fundamentales.
La IA autónoma en la gestión de vulnerabilidades. Los agentes de IA que detectan, validan e incluso corrigen vulnerabilidades de forma autónoma están pasando de ser un concepto a una fase inicial de implementación. Estos agentes combinan el análisis, la priorización y la creación de incidencias en flujos de trabajo automatizados, lo que podría reducir el plazo medio de 32 días para la aplicación de parches. Sin embargo, la corrección autónoma introduce nuevos riesgos en torno a la gestión del cambio y a las consecuencias no deseadas, lo que exige una gobernanza cuidadosa.
Ampliación de los requisitos normativos. La intensificación de la aplicación de la Directiva NIS2 en toda la UE en 2026, el endurecimiento de los requisitos de la Directiva DORA para el sector financiero y las actualizaciones previstas del Marco de Seguridad Cibernética del NIST aumentarán la carga que supone el cumplimiento normativo para los programas de evaluación de vulnerabilidades. Las organizaciones deben prepararse para requisitos más estrictos en cuanto a la frecuencia, el alcance y la documentación de las evaluaciones, especialmente en los sectores de infraestructuras críticas.
Convergencia entre la evaluación de vulnerabilidades y la gestión de la exposición. La frontera entre la evaluación de vulnerabilidades y la gestión más amplia de la exposición se está difuminando. El marco CTEM de Gartner prevé que las organizaciones que adopten una gestión continua de la exposición tendrán tres veces menos probabilidades de sufrir una violación de seguridad para 2026. Esta convergencia implica que los programas de evaluación de vulnerabilidades deben ir más allá de las bases de datos CVE para abarcar las configuraciones erróneas, las exposiciones de identidades y los riesgos del plano cloud , tal y como demostró claramente el análisis del ataque de borrado de datos a Stryker.
Las organizaciones deberían invertir en desarrollar capacidades de priorización multifactorial (CVSS + EPSS + contexto de los activos + inteligencia sobre amenazas), ampliar el alcance de las evaluaciones para abarcar las superficies cloud de identidades, e integrar los resultados de las evaluaciones de vulnerabilidad directamente en los flujos de trabajo de detección y respuesta.
La evaluación de vulnerabilidades sigue siendo una de las actividades más fundamentales y trascendentales que puede llevar a cabo un equipo de seguridad. El proceso es sencillo —planificar, detectar, escanear, analizar, informar—, pero para ejecutarlo correctamente se requiere un alcance exhaustivo, una priorización basada en el riesgo, una frecuencia adecuada y la integración con las operaciones de seguridad en general.
El panorama de amenazas exige algo más que simples ejercicios anuales de marcar casillas. Con un volumen de CVE que se acercará a los 59 000 en 2026, ventanas de explotación que se miden en horas en lugar de semanas y una normativa cada vez más estricta a nivel mundial, las organizaciones necesitan programas de evaluación que sean continuos, tengan en cuenta el contexto y estén conectados a los flujos de trabajo de detección y respuesta.
Empiece por evaluar su cobertura actual de evaluación en relación con el marco que se describe en esta guía. Identifique las carencias: ¿está analizando cloud ? ¿Cubre las configuraciones de identidad? ¿Establece prioridades más allá del CVSS? A partir de ahí, desarrolle un programa que considere la evaluación de vulnerabilidades no como una obligación de cumplimiento normativo, sino como una disciplina operativa que reduzca la exposición antes de que los atacantes la aprovechen.
Una evaluación de vulnerabilidades es un proceso sistemático destinado a identificar, clasificar y priorizar los puntos débiles de seguridad en los sistemas, redes y aplicaciones de una organización. El NIST la define como un «examen sistemático de un sistema o producto de información para determinar la idoneidad de las medidas de seguridad». En la práctica, una evaluación de vulnerabilidades de seguridad utiliza una combinación de herramientas de análisis automatizadas y revisiones manuales para detectar CVE conocidas, configuraciones erróneas, parches pendientes y valores predeterminados inseguros en todo el entorno. El proceso genera un informe priorizado que asigna los hallazgos a niveles de riesgo, lo que permite a los equipos de seguridad centrar la corrección en las vulnerabilidades con mayor probabilidad de ser explotadas. Con 48 185 CVE publicadas en 2025 y unas 59 000 previstas para 2026, la evaluación periódica ya no es opcional: es un requisito de seguridad básico para cualquier organización.
El modelo tradicional de cuatro etapas abarca la identificación, el análisis, la evaluación de riesgos y la corrección. Muchas organizaciones amplían este modelo a cinco etapas añadiendo al principio una fase de planificación y definición del alcance. En la etapa de identificación, los escáneres automatizados y las técnicas manuales detectan vulnerabilidades en los activos incluidos en el alcance. El análisis clasifica y valida los hallazgos, separando los verdaderos positivos de los falsos positivos. La evaluación de riesgos clasifica cada vulnerabilidad utilizando sistemas de puntuación como el CVSS, combinados con datos sobre la criticidad de los activos y su explotabilidad. La corrección traduce los hallazgos priorizados en acciones: aplicación de parches, cambios de configuración, controles compensatorios o aceptación del riesgo. El proceso debe repetirse continuamente en lugar de terminar tras una sola pasada, y cada ciclo debe refinar el alcance, mejorar la precisión de la detección y verificar que las correcciones anteriores se mantienen.
Una evaluación de vulnerabilidades identifica los puntos débiles de forma general mediante análisis automatizados y genera una lista priorizada de vulnerabilidades conocidas. Una prueba de penetración comprueba si determinadas vulnerabilidades son realmente explotables, simulando técnicas de ataque reales contra los sistemas seleccionados. La evaluación de vulnerabilidades abarca un amplio espectro para detectar el mayor número posible de puntos débiles. Las pruebas de penetración profundizan para demostrar la explotabilidad y el impacto en el negocio. La mayoría de las organizaciones necesitan ambas cosas. La evaluación de vulnerabilidades se realiza con frecuencia —mensualmente o de forma continua— para lograr una amplia cobertura. Las pruebas de penetración se realizan anualmente o semestralmente en los sistemas críticos. Juntas, la evaluación de vulnerabilidades y las pruebas de penetración (VAPT) crean una imagen completa tanto de las debilidades teóricas como de las vías de ataque validadas.
La frecuencia de las evaluaciones debe ajustarse a la importancia de los activos, al nivel de amenaza y a los requisitos de cumplimiento, y no a un calendario genérico. Los activos críticos y los sistemas de cara al público exigen un análisis semanal o continuo. Las aplicaciones internas y las bases de datos requieren una evaluación mensual. Las estaciones de trabajo estándar y los sistemas de bajo riesgo pueden seguir una periodicidad trimestral. Los datos respaldan este enfoque basado en el riesgo. El 28 % de los exploits se producen en las 24 horas siguientes a su divulgación, lo que significa que los análisis trimestrales crean puntos ciegos de entre 45 y 90 días. La norma PCI DSS v4.0 exige como mínimo una frecuencia trimestral, los controles CIS v8 recomiendan análisis semanales para los activos críticos y la NIS2 espera una gestión continua de las vulnerabilidades para las entidades esenciales.
Los costes oscilan entre los 1.000 dólares de los pequeños análisis de una sola red y los más de 50.000 dólares de las evaluaciones a nivel empresarial que abarcan múltiples entornos, cloud y carteras de aplicaciones. Entre los factores clave que determinan el coste se incluyen el alcance (número de direcciones IP, aplicaciones y entornos), el tipo de evaluación (de red, de aplicaciones o integral), si la evaluación es exclusivamente automatizada o incluye validación manual, y si se lleva a cabo internamente o mediante una empresa externa. El cálculo más relevante es el retorno de la inversión (ROI). Compare el coste anual de las evaluaciones periódicas con el coste medio de una filtración de datos, las multas regulatorias por incumplimiento normativo y la interrupción operativa derivada de incidentes que podrían haberse evitado mediante una detección temprana.
La evaluación de vulnerabilidades es una actividad puntual que identifica y prioriza los puntos débiles de seguridad. La gestión de vulnerabilidades es un ciclo continuo que incluye la evaluación como uno de sus componentes, junto con el inventario de activos, el seguimiento de las correcciones, la verificación, el tratamiento de excepciones y la gobernanza continua del programa. Piénsalo de esta manera. Una evaluación es una instantánea. La gestión de vulnerabilidades es la película: la disciplina operativa continua de detectar, corregir, verificar e informar sobre las vulnerabilidades a lo largo de todo su ciclo de vida. Las organizaciones necesitan ambas cosas: evaluaciones individuales para detectar problemas y un programa de gestión para garantizar que se corrijan y permanezcan corregidos.
La evaluación continua de vulnerabilidades sustituye los análisis puntuales periódicos por una supervisión permanente que detecta las nuevas vulnerabilidades a medida que surgen. Este enfoque se basa en el hecho de que cada día se publican nuevas CVE y que el 28 % de los ataques se producen en las 24 horas siguientes a su divulgación, lo que hace que los análisis trimestrales o incluso mensuales resulten insuficientes para los activos críticos. La evaluación continua se integra con la gestión de activos, las fuentes de inteligencia sobre amenazas y el catálogo de vulnerabilidades explotadas conocidas de la CISA para señalar automáticamente los nuevos hallazgos relevantes. Se alinea con el marco más amplio de gestión continua de la exposición a amenazas (CTEM), que va más allá del análisis de CVE para incluir configuraciones erróneas, exposiciones de identidades y riesgos del plano cloud .