Olvídense del CVE: expertos en seguridad informática examinaron registros en la sombra de China y hallaron cientos de vulnerabilidades desconocidas para Occidente.

En seguridad informática hace tiempo es común clasificar las vulnerabilidades mediante CVE: la vulnerabilidad recibió un número, luego se añaden la puntuación CVSS, el tipo según CWE, la lista de productos afectados, y así se pueden establecer prioridades para los parches. Pero 2024 y 2025 mostraron lo frágil que puede ser esa cadena si uno de sus nodos clave empieza a fallar.

Al principio, en febrero de 2024, la Base Nacional de Vulnerabilidades de EE. UU. (NVD), gestionada por NIST, sufrió un retraso. Durante años la NVD realizó un trabajo rutinario pero crítico: tomaba las entradas de la lista CVE y las complementaba con lo necesario para defensores y escáneres —puntuaciones CVSS, vínculos con tipos de errores, listas de software afectado y otros campos. Tras la desaceleración, la NVD reconoció que le estaba creciendo una cola de registros sin procesar. Se cambió el enfoque hacia las vulnerabilidades más recientes, primero las posteriores a 2018, pero el propio atraso no desapareció.

Casi de inmediato hubo otra sacudida, de índole organizativa. Tras la conferencia VulnCon 2025, donde se discutió públicamente el futuro del programa CVE y la calidad de las publicaciones de las organizaciones autorizadas para emitir CVE (llamadas CNA), salió a la luz una historia sobre el contrato del Departamento de Seguridad Nacional de EE. UU. que financia el programa. No renovaron el contrato a tiempo, se desató el pánico, incluso se habló de fragmentar la catalogación de vulnerabilidades en varios listados independientes. Al final se resolvió la crisis, se consiguió financiación y el programa siguió funcionando sin interrupciones. Pero el hecho fue incómodo: la industria había asumido demasiado que MITRE y NIST siempre serían pilares de referencia, y quedó claro que también ellos tienen puntos débiles.

Y recientemente un investigador de Bitsight decidió mirar más ampliamente: qué ocurre en las bases gubernamentales de vulnerabilidades fuera de EE. UU., y especialmente en China. Porque China tiene dos de ellas, y funcionan con reglas diferentes.

En China funcionan en paralelo dos bases estatales de vulnerabilidades, CNNVD y CNVD. Ambas usan identificadores propios y mantienen registros por separado, aunque las dos pueden almacenar referencias a CVE si ese número ya existe. Casi no hay enlaces cruzados entre CNVD y CNNVD, así que la comparación de entradas suele hacerse a través de CVE y por coincidencia de descripciones.

CNNVD es gestionada por el Centro de Evaluación de Seguridad de la Información CNITSEC. Se atribuye la supervisión a una estructura vinculada al Ministerio de Seguridad del Estado. Por la forma en que se completa la CNNVD y por su calendario de publicaciones, la base parece orientada al flujo "externo": cuando una vulnerabilidad es revelada por fuentes internacionales, la entrada aparece rápidamente en la CNNVD. En la práctica, la CNNVD suele funcionar como espejo de CVE, pero dentro de las normas chinas de publicación.

CNVD está bajo el control del equipo chino de respuesta a incidentes informáticos CNCERT. CNVD se parece más a una base defensiva habitual: registrar nuevas vulnerabilidades, publicar avisos y ayudar a quienes cierran las brechas en productos e infraestructura.

Sobre ambas bases existe una capa regulatoria separada y muy estricta. Las normas chinas determinan no solo qué se puede escribir sobre una vulnerabilidad, sino también cuándo se puede escribirlo. El documento clave es el reglamento de gestión de vulnerabilidades en productos de red, conocido como RMSV, que entró en vigor en julio de 2021. El RMSV fija un procedimiento que difiere notablemente de la práctica occidental de divulgación coordinada.

El RMSV exige comunicar la información sobre una vulnerabilidad a las autoridades estatales, incluido el ministerio competente. El plazo para notificar es estricto: hasta 48 horas tras su descubrimiento. No se pueden divulgar detalles técnicos antes de que salga un parche. Las publicaciones no deben incluir pruebas de concepto ni, mucho menos, exploits listos para usar. También hay una prohibición expresa de inflar artificialmente la gravedad del problema. En lugar de acuerdos voluntarios entre investigador y proveedor, existe un procedimiento prescrito donde se prioriza la gobernanza y el control sobre el ritmo de la divulgación.

El acceso a los datos está diseñado de forma poco favorable para la automatización. Ambas bases requieren registro e inicio de sesión. Las exportaciones se pueden descargar, pero el acceso automatizado casi no existe: las solicitudes dependen de acciones en la interfaz y los archivos se generan en el servidor a petición. Las descargas llegan en XML y en esos XML se encuentran errores que hacen que los analizadores estándar fallen de vez en cuando, por lo que los datos deben extraerse con más cuidado.

En la dinámica general ambas bases chinas en gran medida replican el crecimiento de CVE, lo cual es esperable: una parte significativa de los registros refleja vulnerabilidades internacionales. Esto se aprecia especialmente en CNNVD, donde a menudo aparece casi el conjunto completo de CVE. Al mismo tiempo surge el problema de la calidad de los datos. Aparecen errores tipográficos en los propios identificadores CVE: letras omitidas, símbolos incorrectos, guiones reemplazados por otros signos, errores en los años. Para el analista esos fallos se traducen en trabajo manual adicional, y para el responsable de seguridad se convierten en un problema real: las búsquedas por CVE empiezan a dar omisiones y la correlación automática con parches y reglas de detección se rompe en los lugares más inesperados.

CNVD y CNNVD, en cuanto al conjunto de campos, en algunos aspectos se parecen a los catálogos occidentales, pero las concordancias son parciales. En ambas bases hay una escala de severidad. En cuanto al sentido, la escala es similar a los niveles que habitualmente se obtienen de CVSS, aunque la distribución por niveles no reproduce la estadística internacional exactamente. En CNNVD existe un campo independiente para el tipo de vulnerabilidad que desempeña una función similar a CWE, pero no hay una correspondencia directa. CNVD guarda las fechas de recepción y de publicación. Según esas fechas, alrededor del 90% de las entradas aparecen en el plazo de una semana después de que la información ingresó a la base. Al mismo tiempo se encuentran casos extraños en los que la fecha de recepción es posterior a la fecha de divulgación oficial, lo que parece errores de formulario y obliga a tratar con cautela tales cronologías.

En CNVD hay otro parámetro que puede interpretarse fácilmente como una marca de relación con un incidente. En la práctica casi todas las fichas están etiquetadas como vulnerabilidades ordinarias de software y hardware. Destaca un grupo separado de 74 entradas en el verano de 2020 con la etiqueta de vulnerabilidades relacionadas con eventos. Por las descripciones, esas fichas se parecen más a historias sobre robos y ataques en ecosistemas cripto que a una indicación de que la vulnerabilidad se haya usado realmente en ataques.

También se puede analizar las fechas de publicación. Interesa la frecuencia de casos en que CNVD o CNNVD publican una ficha antes de que la entrada se haga pública en CVE o en la NVD.

Aquí hay un punto importante. CVE a menudo pasa por una etapa "semipública": ya se ha asignado o reservado un número, puede que ya exista un parche, las discusiones pueden estar en curso y, sin embargo, la ficha CVE aún no se considera publicada. Por eso es más práctico considerar que una vulnerabilidad es pública a partir de la fecha en que la entrada apareció en CVE o en la NVD. Y si una base china muestra la publicación con mucha antelación, conviene comprobar también la fecha de reserva del CVE para no confundir un adelanto real con un retraso en la publicación formal.

Incluso con esa regla, en las bases chinas aparecen fechas que no encajan con la lógica mínima. A veces la fecha de publicación no coincide con el mes y el año indicados en el identificador chino. A veces en lugar de una fecha normal figura el 1 de enero del año correspondiente, como si el sistema hubiera puesto un valor por defecto. A veces el año en el identificador coincide con el año del CVE y, sin embargo, la fecha de publicación en la base se desplaza por algún motivo varios años hacia adelante o hacia atrás. Esas situaciones parecen errores de entrada, por lo que hay que verificar la cronología y no basarse solo en las fechas.

Si se descartan tales anomalías, se obtiene un panorama sencillo. En la mayoría de los casos CNVD y CNNVD publican las entradas después de que aparezcan en CVE o el mismo día. Las publicaciones adelantadas son poco frecuentes: alrededor del 0,55% para CNNVD y 0,18% para CNVD. Calculado para todo el periodo desde 2011, son aproximadamente 1 400 entradas en las que una base china fue la primera.

Además, ese adelanto raro suele ser más que un par de días. La brecha media es de alrededor de tres meses. Para algunas vulnerabilidades la entrada china apareció muchas semanas antes de que el registro CVE se considere publicado. Las descripciones en esas fichas chinas a menudo casi coinciden con lo que después aparece en CVE. Es difícil verificar de dónde proceden las formulaciones y cuándo se añadió o editó exactamente el texto: las bases chinas no ofrecen un historial de cambios adecuado.

Las publicaciones adelantadas se dan más a menudo entre vulnerabilidades que en la evaluación china reciben una gravedad más baja. En CNNVD entre las fichas tempranas se observa una proporción de entradas sin gravedad indicada. Esa distribución recuerda a una situación en la que la puntuación de severidad se toma de fuentes occidentales. Mientras no exista una evaluación occidental, el campo permanece vacío o indeterminado.

Otra historia son las entradas de CNVD y CNNVD sin enlace a CVE. Aproximadamente desde 2021 el comportamiento de las bases cambia, y en el tiempo esto coincide con la entrada en vigor del RMSV. Tras el reglamento, CNVD se volvió notablemente más lenta en publicar esas fichas. CNNVD empezó a reducir esas publicaciones aproximadamente un año antes del reglamento y luego, en el último año, volvió a publicar más entradas sin CVE. Los propios datos permiten suponer varias razones. Las bases podrían haber mejorado la capacidad de asignar entradas a CVE y así dejar menos fichas sin número. Las nuevas normas podrían haber llevado parte de las vulnerabilidades fuera del acceso público. Además, parte de esas vulnerabilidades puede pertenecer a software y dispositivos locales que rara vez se ven fuera de China y por eso no entran en los catálogos internacionales. Lo más probable es que actuaran varias causas al mismo tiempo.