DefenceLevel Index · Metodología v1.30

Cómo se calcula el DefenceLevel Index

Esta página describe por completo, sin simplificaciones, la regla con la que el DefenceLevel Index asigna cada día un nivel del 5 al 1. La regla es determinista: con los mismos datos produce siempre el mismo resultado, y cada nivel va acompañado de las razones que lo han determinado.

Versión de la metodología: 1.30 · Vigente desde el 4 de noviembre de 2026 · Última actualización de esta página: 4 de noviembre de 2026

1. Qué mide y qué no mide

El DefenceLevel Index mide la urgencia de las nuevas amenazas informáticas: lo probable que es que, en un día determinado, una organización tenga que actuar con rapidez sobre vulnerabilidades de software y dispositivos de uso común, porque atacantes reales las están explotando o están a punto de hacerlo.

No mide:

• el riesgo de una organización concreta, que depende de los productos que usa, de cómo los configura y de cuánto está expuesta en internet;
• el volumen total de vulnerabilidades publicadas: miles cada mes, la mayoría sin consecuencias prácticas;
• ataques dirigidos a víctimas concretas, campañas de phishing, robos de credenciales o incidentes que no pasan por una vulnerabilidad de software pública.

Un nivel bajo no significa que el mundo sea seguro: significa que en esas 24 horas no ha surgido nada nuevo que requiera una intervención extraordinaria más allá del mantenimiento normal.

2. La escala del 5 al 1

El índice adopta la escala militar estadounidense DEFCON: 5 es la condición ordinaria, 1 la más grave. DefenceLevel no está afiliado al Departamento de Defensa de Estados Unidos ni a la conferencia DEF CON®, marca de Def Con Communications, Inc.

Las condiciones exactas de cada nivel están en la sección 8.

3. Las fuentes

El sistema lee fuentes públicas, agrupadas por función. La función decide dos cosas: cuánto pesa la fuente en la señal de atención y si puede confirmar una vulnerabilidad o su explotación. Solo los organismos oficiales, los CERT y los fabricantes pueden confirmar que una vulnerabilidad existe; los laboratorios de investigación también pueden confirmar la explotación activa; la prensa y las redes sociales contribuyen a la atención, pero por sí solas no confirman nada.

Los datos de VulnCheck KEV se usan según los términos de VulnCheck, que exigen citar la fuente: VulnCheck KEV (vulncheck.com). Los datos del catálogo europeo de vulnerabilidades explotadas se reutilizan según el aviso legal de ENISA, citando la fuente: ENISA EUVD (euvd.enisa.europa.eu).

Enriquecimiento: para cada vulnerabilidad se leen también la probabilidad de explotación EPSS publicada por FIRST y la ficha oficial en cve.org.

La consola en directo de la página de inicio muestra cuántas fuentes han respondido en las últimas 24 horas. La lista se amplía con el tiempo: cada incorporación se registra en la sección 14.

4. El ciclo de recogida

• Cada 30 minutos: fuentes rápidas (investigación, prensa, exploits públicos, código, redes sociales).
• Cada hora: fuentes oficiales y fabricantes (NVD, CISA KEV, Microsoft, GitHub Advisories, CERT, avisos de los fabricantes).
• Cada 12 horas: Wordfence Intelligence, la base de datos de vulnerabilidades de plugins y temas de WordPress.
• En cada recogida se reevalúa cada vulnerabilidad afectada y se recalcula el nivel actual sobre las últimas 24 horas.
• A las 04:00 UTC, todos los días del año, se fijan el nivel del día y el contenido del informe, con los datos recogidos hasta ese momento; a las 05:00 UTC, tras la verificación, el informe se envía a los suscriptores.

Cada aviso recogido registra una fuente, un instante, una o varias vulnerabilidades citadas (identificadas por su código CVE) y algunos indicadores extraídos del texto, como la mención explícita de explotación activa. Los avisos no se borran: el cálculo usa siempre el historial completo. Un aviso atribuido por error a una vulnerabilidad, por ejemplo un boletín sobre otras vulnerabilidades que solo la cita como contexto, se excluye del cálculo para esa vulnerabilidad tras la verificación: la corrección queda registrada y el nivel se recalcula con las mismas reglas. En un boletín sobre varias vulnerabilidades, una explotada desde hace al menos 7 días (catálogo KEV o primera confirmación), citada junto a otras nuevas (publicadas hace menos de 14 días o aún no publicadas) y no nombrada en el título del aviso, es una remisión y no una señal: ese aviso no cuenta para ella. Un aviso oficial o del fabricante publicado en las 48 horas posteriores a la publicación de la vulnerabilidad es el aviso sobre ella: solo se excluye si le atribuye por error una explotación. El comunicado de CISA sobre la inclusión en el catálogo KEV solo cuenta para las vulnerabilidades que el catálogo recoge con su fecha (o con el día anterior, por la zona horaria): para las demás que cita no cuenta.

5. El análisis de cada vulnerabilidad

Cada vulnerabilidad se evalúa en cuatro ejes, cada uno de 0 a 10.

5.1 Gravedad técnica (S)

Es la puntuación CVSS oficial. Si la ficha CVE aún no está publicada pero un aviso oficial, de un CERT nacional o del fabricante, confirma la vulnerabilidad, se aplica la gravedad indicada en el aviso: su puntuación CVSS o, en su defecto, el mínimo de la clase indicada (crítica 9, alta 7, media 4, baja 0,1); del mismo aviso se toman el producto afectado y la indicación de un ataque sin credenciales. Si no, se estima a partir de la categoría de la vulnerabilidad (por ejemplo: ejecución remota de código 9; omisión de autenticación 8,5; escritura de archivos arbitrarios 8,5; escalada de privilegios 7,5; divulgación de información 5,5; cross-site scripting 4,5), con −1 si hay requisitos difíciles (credenciales administrativas, acceso local o físico) y +0,5 si es atacable por red sin credenciales. «Atacable por red sin credenciales» viene del vector CVSS, pero no vale si el fabricante escribe que hace falta acceso local, privilegios o una cuenta ya obtenidos, o un cliente autenticado: entonces cuentan los requisitos difíciles. Si la ficha CVE no tiene fabricante ni producto, valen los que los catálogos de vulnerabilidades explotadas y ENISA EUVD indican de forma estructurada; después, los productos afectados que indican la propia ficha o NVD, si nombran un solo fabricante (con solo productos de una distribución de Linux, que incluye el componente, vale la evaluación más grave); sin ellos, el producto nombrado en los títulos de los avisos y de los catálogos, con su fabricante cuando es un producto conocido. Si no tiene descripción, la categoría se toma de los títulos de los avisos.

5.2 Explotación real (E)

Depende del estado más avanzado documentado:

El valor sube hasta 10 × EPSS si la probabilidad EPSS es mayor, y al menos a 6 si la vulnerabilidad está en el 5 % más probable según EPSS. Baja 1,5 si hay requisitos difíciles (salvo explotación activa) y 1 si la complejidad de ataque CVSS es alta.

La «explotación activa» se reconoce en los textos por expresiones explícitas («exploited in the wild», «actively exploited», «under active exploitation» y similares). Solo cuenta si la fuente es oficial, un fabricante o la investigación; si solo lo afirman la prensa, o al menos dos cuentas distintas en redes sociales, la vulnerabilidad queda en observación con la indicación «explotación notificada, no confirmada» y nunca pasa al ruido. También se reconoce en italiano, francés, español, alemán y neerlandés, los idiomas de los CERT que leemos, y no cuenta si está negada («not aware of active exploitation», «no hay constancia de explotación activa»). En los boletines sobre varias vulnerabilidades solo cuenta para las nombradas en la frase sobre la explotación; si esa frase no nombra ninguna, cuenta para todas si son tres como máximo y, si son más, solo para aquella en cuyo párrafo está la frase, cuando el boletín las describe una por una. Un artículo de prensa o una publicación en redes sociales que en el título o en las primeras líneas solo nombra otras CVE no cuenta como notificación de ataques para las vulnerabilidades que menciona más adelante, salvo que la frase sobre la explotación las nombre. En los resúmenes en lista solo cuenta para la vulnerabilidad de la línea que la contiene, y no cuenta cuando describe solo lo que la falla permitiría («lets attackers…»). Un artículo de investigación cuyo título nombra otras CVE y no esta la menciona como contexto: para ella no es una señal. Un artículo de investigación o de prensa sobre una vulnerabilidad que lleva más de 30 días en el catálogo CISA KEV la menciona como contexto y no cuenta para ella, salvo que el título o la dirección nombre la vulnerabilidad, su producto o su fabricante, o hable de ataques, o que, en un texto sobre varias vulnerabilidades, la frase sobre la explotación la nombre. Lo mismo vale para cualquier vulnerabilidad cuando un artículo de investigación menciona solo esa, sin nombrar en el título o en la dirección la vulnerabilidad, su producto o su fabricante y sin hablar de ataques: la menciona como contexto y, como una remisión, no cuenta para ella.

5.3 Impacto (I)

Parte de la categoría (ejecución de código 9,5; omisión de autenticación 9; compromiso de la cadena de suministro 9; escritura de archivos arbitrarios 8,5; escalada de privilegios, corrupción de memoria, inyección SQL 7; …) y se corrige con la difusión del producto (véase la sección 6): +1,5 componentes presentes en casi todas partes, +1 dispositivos perimetrales, 0 productos comunes, −1,5 productos de nicho, −4 generadores de vulnerabilidades de bajo impacto. +1 si la usan grupos de ransomware según CISA, +0,5 si es atacable por red sin credenciales. La ejecución de comandos arbitrarios cuenta como ejecución de código, también cuando es consecuencia de una inyección SQL.

5.4 Atención (Z)

Mide cuánto se habla de ella entre profesionales en las últimas 24 horas. Cuentan las menciones de investigación, código, prensa y redes sociales, cada una ponderada según la función de su fuente (tabla de la sección 3), y cada cuenta, medio o autor vale una sola vez, con el peso más alto de sus menciones, también cuando publica en varias redes sociales con el mismo nombre de usuario; los avisos oficiales, de fabricantes y de archivos de exploits ya intervienen en la gravedad y la explotación, y aquí no cuentan:

El logaritmo impide que mil publicaciones repetidas valgan mil veces más que una sola.

No cuentan las cuentas que republican las fichas de las vulnerabilidades en lugar de comentarlas: las que en los 7 días anteriores han escrito sobre al menos 20 vulnerabilidades distintas, salvo las cuentas de referencia de la sección 3. El mismo texto publicado por cuentas distintas con pocos minutos de diferencia, como hace un medio con varios perfiles, cuenta como una sola cuenta.

5.5 Puntuación combinada

Los pesos priorizan la gravedad y la explotación real; la atención pesa solo un 10 %, para no premiar el ruido. Son decisiones de método, declaradas aquí y verificadas a posteriori (sección 12). La puntuación sirve para elegir qué vulnerabilidades entran en el informe (7,0 para las principales, 5,8 para «a vigilar»); el nivel, en cambio, sigue las reglas explícitas de la sección 8.

6. Productos extendidos y atacados

Una vulnerabilidad cuenta más si afecta a un producto que usan muchas organizaciones y que históricamente está en el punto de mira de los atacantes. La clasificación combina una lista pública por tipo de producto con un dato objetivo de historial de ataques:

El historial de ataques procede del catálogo CISA Known Exploited Vulnerabilities: se cuentan las vulnerabilidades con explotación confirmada añadidas en los últimos 5 años. El recuento se rehace automáticamente el primer día de cada mes (UTC) y no cambia durante todo el mes; se conserva la foto de cada mes. Así, un producto que los atacantes ponen en el punto de mira entra en la clasificación aunque no estuviera en la lista, y un producto de la lista sin historial de ataques no se sobrevalora. El fabricante se reconoce sin la forma societaria, la escriba como la escriba la fuente: «PHP Group» es PHP, «SAP SE» es SAP, «IBM Corporation» es IBM.

La clase de la lista vale para los productos de quien fabrica la plataforma: Windows de Microsoft, Android de Google o de los fabricantes que lo instalan en sus teléfonos, los componentes del sistema (OpenSSL, glibc, sudo…) también de las distribuciones Linux que los incluyen. Un producto de terceros que cita su nombre no la hereda: una biblioteca de Python no es Python, una app para Android no es Android. Tampoco un proyecto cuyo nombre une el de la plataforma a otra palabra con un guion (node-openssl no es OpenSSL), que tampoco toma el historial de ataques de su fabricante, salvo si el producto lleva solo el nombre de la plataforma. Lo mismo vale para los componentes adicionales (plugins, extensiones, temas, complementos): un plugin para WordPress no es WordPress. Estos productos se clasifican por sí mismos, con su propio historial de ataques. El fabricante y el producto son los de la ficha CVE, salvo en dos casos en los que valen los del catálogo CISA KEV: la ficha cita más de tres productos (Microsoft cita cada versión de Windows), o indica un fabricante sin relación con el del catálogo, normalmente un producto que integra el componente afectado (Apache Struts, no el equipo de Huawei que lo contiene). Los nombres genéricos del catálogo («Multiple Products») no valen nunca.

Una vulnerabilidad que afecta a varios productos del mismo fabricante se evalúa con la clase de cada uno y vale el resultado más grave: un fallo de Bamboo que afecta también a Confluence y Jira cuenta como un fallo de un dispositivo perimetral. Los productos afectados son los que indican las fuentes oficiales (ficha CVE, NVD, catálogo CISA KEV, avisos de los fabricantes), salvo los que la ficha declara no afectados; los productos de otros fabricantes, como los sistemas que incluyen una biblioteca afectada, y los nombres genéricos del catálogo no cuentan.

En los fabricantes con un catálogo amplio (Cisco, Fortinet, Ivanti, Citrix, Palo Alto Networks, F5, Juniper, VMware, ConnectWise), el nombre del fabricante en la lista de dispositivos perimetrales solo vale para sus productos con un historial de ataques propio, al menos 2 vulnerabilidades explotadas en 5 años: un cortafuegos de Cisco sí, un switch de centro de datos o un servidor de licencias no. Sus demás productos cuentan como productos comunes.

Los switches y los puntos de acceso de la red interna no son dispositivos perimetrales, ni siquiera de los fabricantes cuyos productos cuentan como tales en lo demás: son productos comunes. Se reconocen por el nombre del producto o, en el caso de Zyxel, por la sigla del modelo.

Un fabricante que es la marca de un producto conocido (por ejemplo NetScaler, de Citrix) cuenta como ese producto de su propietario, con su historial. El kernel de Linux cuenta como tal aunque la ficha CVE lo llame solo «Linux».

7. La contención del alarmismo

Una vulnerabilidad no puede subir el nivel si se encuentra en uno de estos casos:

• No confirmada: se habla mucho de ella, pero ninguna fuente oficial ni ningún fabricante la ha confirmado. Si la prensa informa de una actualización de seguridad del fabricante, en cambio, pasa a las que conviene vigilar.
• Rechazada o impugnada en el registro CVE, salvo que esté en el catálogo KEV de CISA o tenga un aviso del fabricante: entonces se evalúa como las demás.
• Sensacionalista: lenguaje de titular («catastrófica», «miles de millones de dispositivos en riesgo»…), sin explotación ni exploit creíble, gravedad inferior a 7 o producto de nicho, cuando la atención no se explica por un aviso oficial o del fabricante de los últimos 3 días.
• Exploit falso o no verificado muy compartido, con gravedad inferior a 9, cuando la atención no se explica por un aviso oficial o del fabricante de los últimos 3 días.

Estos casos van a la sección «Muy comentadas, pero sin motivo de alarma hoy» del informe, con la explicación de por qué no son una emergencia. Es la excepción una vulnerabilidad de la que la prensa, o al menos dos cuentas distintas en redes sociales, notifican ataques: aunque no estén confirmados, va entre las vulnerabilidades a vigilar, nunca en esta sección. La redacción puede mover una entrada de esta sección a las vulnerabilidades a vigilar, nunca al revés; ningún nivel cambia.

Además, una vulnerabilidad antigua (publicada hace más de un año, o con un código CVE de dos años antes) no es noticia, salvo que CISA acabe de confirmar su explotación: en ese caso puede llegar como máximo al nivel 3.

8. El nivel de cada vulnerabilidad

Las condiciones se evalúan de arriba abajo; vale la primera que se cumple. Solo las vulnerabilidades confirmadas y no clasificadas como ruido pueden superar el nivel 5.

«Reciente» significa: incluida en el catálogo KEV hace como máximo 14 días, o publicada hace como máximo 30 días, o con un nuevo informe de explotación de una fuente oficial, un fabricante o la investigación en las últimas 72 horas. Una explotación conocida desde hace tiempo es un problema conocido, no una noticia.

Fuentes independientes (atención amplia del nivel 2 y medio punto de la atención): cada fuente cuenta una vez; las redes sociales juntas valen una sola fuente, porque cuánto se habla de ella ya lo mide la atención; el comunicado de CISA sobre la inclusión en el catálogo KEV es el catálogo KEV; el catálogo VulnCheck KEV no cuenta si las pruebas que cita proceden de una fuente ya presente. El mismo nombre de usuario en varias redes sociales es un solo autor.

El nivel 2 distingue el ataque a un producto de una amenaza de amplio impacto. Un dispositivo perimetral bajo ataque (un cortafuegos, una VPN, una pasarela de un fabricante concreto) es una emergencia para quien lo usa: quien lo tiene entre sus productos en My Defence, con «Solo mis productos», recibe la alerta al instante, y todos la encuentran en el informe del día; pero por sí solo no lleva el índice global a riesgo grave, que queda reservado a los componentes presentes en todas partes y a las campañas documentadas por varias fuentes.

De ello se deduce que una vulnerabilidad grave en un producto extendido nunca baja al nivel 5, y que una vulnerabilidad crítica con exploit público en un producto extendido está al menos en el nivel 3 incluso antes de que se observen ataques.

9. El nivel del día

9.1 El nivel en un momento dado

En cada momento, el nivel es el más grave de entre los de las vulnerabilidades del informe: las novedades y las que siguen en curso, estas un peldaño por debajo:

Vulnerabilidades principales son las confirmadas con una puntuación combinada de al menos 7,0 o con nivel 3 o más grave. También lo son, aun sin ataques conocidos, las vulnerabilidades críticas (gravedad ≥ 9) de un dispositivo perimetral, atacables por red sin credenciales y publicadas hace no más de 30 días: mantienen su nivel y llevan la indicación de actualizar esta semana. Las «a vigilar» aparecen en el informe pero no determinan el nivel. Una señal sin código CVE sobre un producto que ya tiene en el informe una vulnerabilidad con su código CVE es la misma noticia: no aparece ni como entrada propia ni entre las vulnerabilidades a vigilar. Las vulnerabilidades de productos clasificados como ruido nunca son principales, salvo que estén en el catálogo CISA KEV. Las vulnerabilidades del mismo producto citadas junto a una vulnerabilidad principal en el mismo aviso oficial, del fabricante o de investigación de los últimos 7 días, con como máximo 5 vulnerabilidades, entran en su entrada aunque por sí solas no se seleccionarían: son la misma cadena de ataque. El nivel del día no cambia.

La actualidad de una vulnerabilidad se mide desde el más reciente de estos momentos: publicación de la vulnerabilidad, inclusión en el catálogo KEV (+12 horas), última señal oficial, de un fabricante, de la investigación o de un exploit, y «ahora» si en las últimas 24 horas hay al menos 3 menciones. Una vulnerabilidad de la que se sigue hablando continúa, por tanto, siendo de actualidad; una de la que ya no se habla sale del cálculo. Un aviso que la misma fuente vuelve a publicar con el mismo título en 30 días no es una señal nueva; una actualización con un título distinto, sí. La fecha de cada señal es aquella en que la fuente la publicó; una entrada sin fecha legible cuenta como nueva solo la primera vez que aparece. Una señal sin fecha fiable (ilegible, anterior a 1999, de más de un día en el futuro, o idéntica al milisegundo en al menos tres avisos distintos de la misma fuente sobre vulnerabilidades distintas: es la hora en que la fuente actualizó su feed) vale por lo que dice, no por el cuándo: no hace de actualidad una vulnerabilidad ni confirma su explotación, que queda indicada y no confirmada hasta que la confirme una fuente con fecha.

Para seguir en el nivel 1 o 2, y en el nivel 3 por explotación activa, sin embargo, una vulnerabilidad necesita una señal fuerte en las últimas 24 horas: publicación, inclusión en el catálogo KEV (+12 horas) o una señal oficial, de un fabricante, de la investigación o de un exploit. Si es de actualidad solo porque se habla de ella, cuenta un peldaño por debajo, en el nivel del día y en el informe.

En el nivel 4 o 5, una vulnerabilidad de actualidad solo porque se habla de ella, sin señales fuertes desde hace más de 7 días, no es principal: aparece entre las que hay que vigilar y no determina el nivel.

Novedades de las últimas 24 horas. Entre las vulnerabilidades principales de actualidad en las últimas 24 horas, son novedades las que nunca figuraron entre las entradas de los informes de los 30 días anteriores, las que tienen una señal fuerte en las últimas 24 horas y las que tienen un nivel más grave que la última vez, salvo que solo lo hayan subido las conversaciones. Una vulnerabilidad ya señalada que vuelve a ser de actualidad solo porque se habla de ella, en las redes sociales o en la prensa, no es una novedad y no vuelve al informe; si las conversaciones han subido su nivel, aparece en una línea, como las que siguen todavía en curso, que lo dice. La misma regla vale para las vulnerabilidades a vigilar: una que ya apareció en los informes de los 30 días anteriores solo vuelve con una señal fuerte en las últimas 24 horas. Una vulnerabilidad nunca señalada de la que en las últimas 24 horas solo se ha hablado va entre las que hay que vigilar, salvo que esté en el nivel 1–3 (explotada, o crítica con un exploit público): entonces es una novedad, aunque ya estuviera entre las que hay que vigilar. Una vulnerabilidad de hace más de un año, en el catálogo CISA KEV desde hace más de 30 días, vuelve entre las vulnerabilidades a vigilar solo con una señal fuerte en los últimos 7 días o si en las últimas 24 horas han escrito sobre ella al menos dos cuentas.

Todavía en curso. Una vulnerabilidad explotada activamente de nivel 1–3, ya señalada y sin señales fuertes en las últimas 24 horas, se queda en el informe durante 72 horas desde su última señal fuerte, en una línea, aunque nadie hable de ella; el último día la línea lo dice. En el nivel cuenta un peldaño por debajo: quien aún no ha actualizado sigue expuesto. Una nueva señal fuerte la devuelve a las novedades. Si su producto tiene una novedad, aparece en la misma entrada. Las demás vulnerabilidades ya señaladas y sin novedades salen del informe.

Otras vulnerabilidades explotadas. El informe tiene como máximo 8 novedades, las más graves, y como máximo 8 líneas «todavía en curso». Las vulnerabilidades explotadas activamente (explotación confirmada o catálogo KEV) que quedan fuera aparecen en una sección aparte, una línea por vulnerabilidad, de la más grave a la menos grave, como máximo 60; las demás quedan fuera. El nivel del día ya las incluye. Cuentan como señaladas: como las demás, vuelven entre las novedades solo con una señal fuerte en las últimas 24 horas o con un nivel más grave.

Debajo del nivel, el informe dice cómo era en el informe anterior y qué vulnerabilidades lo determinan.

Cuando el informe señala un producto, recuerda también las demás vulnerabilidades del mismo producto explotadas en los últimos 60 días (catálogo KEV o primera explotación) que hoy no están en el informe: como máximo 6, las más recientes, con la fecha desde la que se explotan. Es solo un recordatorio: no cambia el nivel del producto en el informe ni el del día.

9.2 El nivel del día en el índice

El nivel de un día (día natural en UTC) es el fijado a las 04:00 UTC y comunicado a los suscriptores en el informe de las 05:00 de ese día. Después ya no cambia. Si a lo largo del día las recogidas detectan un nivel más grave, el índice lo muestra como pico del día, con la hora en UTC, sin cambiar el nivel del día.

El nivel actual mostrado en directo, en cambio, se recalcula en cada recogida: una emergencia que surge después del informe aparece de inmediato en el nivel actual, se comunica a los suscriptores con una alerta inmediata y aparece en el índice al día siguiente.

Las alertas se envían en DEFCON 1, 2 y 3: el DEFCON 1 a todos los suscriptores; el DEFCON 2 a quienes reciben todas las alertas y, a quienes eligieron «Solo mis productos» en My Defence, solo si afecta a sus productos; el DEFCON 3 solo a quienes eligieron «Solo mis productos», y solo si afecta a sus productos. En DEFCON 4 y 5 no se envía ninguna alerta: las vulnerabilidades están en el informe del día. Las alertas solo se envían con una señal fuerte de las últimas 24 horas. Si la vulnerabilidad ya estaba entre las entradas del informe y desde entonces no ha llegado ninguna señal fuerte nueva, un nivel más grave alcanzado después (por ejemplo, porque se habla más de ella) no envía una alerta en DEFCON 2 o 3: lo recoge el informe siguiente. El DEFCON 1 se envía siempre. Si solo el catálogo VulnCheck KEV confirma la explotación y las pruebas que cita son solo publicaciones en redes sociales, páginas de agregadores o bases de datos de vulnerabilidades (como la ficha CVE), que describen el fallo pero no prueban un ataque, la vulnerabilidad sigue en el informe con su nivel, pero la alerta espera una segunda fuente: el catálogo CISA KEV, un CERT, el fabricante o una investigación.

En las 24 horas siguientes a una alerta de DEFCON 1 o 2, la vulnerabilidad no baja del nivel que tenía en el momento de la alerta solo porque pasa el tiempo, por ejemplo porque las menciones salen de las 24 horas: ese nivel se recalcula con los datos actuales, y solo baja si ha cambiado un hecho, como una señal excluida tras la verificación, una CVE rechazada o un CVSS oficial más bajo. En el informe de esas 24 horas la alerta vale como una señal fuerte: la vulnerabilidad sigue entre las novedades, con el nivel de la alerta.

10. El papel de la inteligencia artificial

El nivel, la selección y el orden de las vulnerabilidades se calculan únicamente con la regla determinista descrita en esta página: con los mismos datos, el resultado es siempre el mismo, y la inteligencia artificial nunca los decide. La usamos para la redacción: antes del envío, un sistema de inteligencia artificial verifica cada informe y cada alerta con nuestros datos (productos, pruebas de explotación, fechas, requisitos) y redacta sus textos. Si encuentra un aviso atribuido a la vulnerabilidad equivocada, lo excluye, y el nivel se recalcula con la regla. Si los datos no confirman una alerta, la alerta no se envía. Informes y alertas solo se envían con la verificación completa: si no está lista, el envío espera.

11. El historial del índice

El nivel de cada día se calcula con las reglas descritas en esta página, usando solo los datos que las fuentes habían publicado hasta ese día: ninguna información posterior entra en el nivel de un día pasado.

12. La verificación de los resultados

Verificamos la metodología comparando sus niveles con el catálogo CISA KEV, la lista de vulnerabilidades cuya explotación real está confirmada. Medimos cuántas vulnerabilidades explotadas lleva la metodología al menos al nivel 3, con cuánta antelación o retraso respecto a la confirmación oficial, y cuántas de las llevadas al nivel 2 o 1 resultan realmente explotadas.

La verificación se hace de dos maneras, con el catálogo entre las fuentes, como trabaja el servicio, y sin él, como control independiente, y se repite con cada versión de la metodología.

13. Límites declarados

• Cobertura de las fuentes. El sistema solo ve lo que es público y está escrito en las fuentes que lee. Los ataques aún no divulgados, o divulgados solo en canales cerrados, no son visibles.
• Dependencia del código CVE. Las vulnerabilidades sin código CVE solo se reconocen si citan un producto conocido; pueden quedar infravaloradas. Los nombres de producto que también son palabras comunes (Teams, Outlook, Zoom, Entra) solo cuentan con el fabricante o una palabra que los califique, como «Microsoft Teams». Un exploit sin CVE no sube el nivel por sí solo: cuenta solo junto con otras señales sobre el mismo producto.
• Reconocimiento del lenguaje. La explotación activa se reconoce en los textos por expresiones explícitas en seis idiomas (inglés, italiano, francés, español, alemán, neerlandés); las formulaciones inusuales u otros idiomas pueden pasar desapercibidos.
• Pesos y umbrales. Son decisiones de método, no magnitudes físicas: están declarados, son estables en el tiempo y se verifican a posteriori, pero un método distinto daría niveles distintos.
• Historial de ataques. El catálogo CISA KEV refleja las prioridades del Gobierno de Estados Unidos y su capacidad de confirmar; los productos muy usados fuera de Estados Unidos pueden estar infrarrepresentados.
• Productos con nombres distintos. La comparación de nombres de fabricantes y productos entre fuentes es automática y puede equivocarse en los casos ambiguos.
• Niveles anteriores al 1 de octubre de 2026. Dependen de lo que las fuentes conservan de los días pasados: algunas fuentes no tienen un historial consultable y, para una comparación justa en el tiempo, las redes sociales solo cuentan con los hashtags de historial completo (#vulnerability, #zeroday), con un máximo de 30 menciones al día. Los niveles de ese periodo pueden, por tanto, subestimar el riesgo.

14. Versiones y cambios

La metodología tiene un número de versión. Cada cambio que pueda modificar un nivel se registra aquí con su fecha; los niveles ya publicados no se reescriben en silencio: si una nueva versión cambia niveles pasados, lo declara.

15. Uso y cita de los datos

Los niveles diarios son públicos y reutilizables con licencia Creative Commons Atribución 4.0 Internacional (CC BY 4.0), citando la fuente. El archivo CSV de los últimos 12 meses se descarga desde la página del DefenceLevel Index y contiene fecha, nivel, nombre del nivel y número de vulnerabilidades incluidas en el informe.

Cita sugerida: DefenceLevel Index (defencelevel.com), metodología v1.30, con la fecha del dato.

Los detalles de cada vulnerabilidad (nombres, productos, acciones recomendadas) están reservados a los suscriptores del informe.