NIST analizó 199 de 3,370 CVE en marzo de 2024

En marzo de 2024, el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) analizó 199 de los 3,370 registros de Common Vulnerabilities and Exposures (CVE) que recibió. Ese año, 413 organizaciones reportaron más de 40,000 CVE. El sistema siguió nombrando fallas de seguridad mientras la base de datos federal creada para explicarlas se rezagaba.

Esas cifras describen trabajos distintos. Un identificador permite que un proveedor, investigador, agencia gubernamental y operador de software se refieran a la misma falla reportada. El análisis debe establecer suficiente información sobre los productos afectados, la gravedad y el contexto para ayudar a alguien a decidir qué hacer. Se puede asignar un nombre antes de que ese trabajo esté completo.

El nombre común escaló porque la identificación estaba distribuida

El sistema CVE comenzó en 1999 para resolver un problema de coordinación: distintas partes necesitaban una referencia común para una vulnerabilidad reportada. MITRE mantiene el programa, pero grandes proveedores y otras organizaciones participantes pueden asignar identificadores. Esa delegación ayudó a que el registro superara los 270,000 expedientes sin exigir que MITRE investigara cada falla antes de que alguien pudiera nombrarla.

La National Vulnerability Database de NIST se creó sobre la Lista CVE para ofrecer una referencia pública más completa. Su trabajo es distinto de emitir un ID. Un operador que intenta encontrar software afectado necesita contexto sobre el producto y la versión; uno que decide si debe interrumpir un despliegue necesita saber si la falla está siendo explotada y si el componente vulnerable está presente y es accesible. Una puntuación por sí sola no puede responder ninguna de las dos preguntas.

El rezago de NIST no apareció de la noche a la mañana. Para 2025, buscaba contratistas para atender un acumulado de más de 25,000 vulnerabilidades, cerca de diez veces el máximo previo reportado para 2017. NIST había atribuido la baja cifra de análisis de marzo de 2024 a un apoyo interinstitucional insuficiente; una interrupción de financiamiento más tarde ese año contribuyó al rezago que llevó a su posterior cambio de política. Añadir analistas puede ayudar, pero cada registro todavía requiere coordinación entre reportes, definiciones de productos, parches y correcciones. El identificador puede distribuirse con mayor facilidad que un juicio confiable sobre su significado operativo.

La neutralidad de MITRE depende de una vía de corrección funcional

El episodio de financiamiento de MITRE en 2025 puso a prueba la capa de identificadores sin romperla. MITRE dijo que su financiamiento había expirado; CISA extendió el apoyo y dijo que no habría interrupción en los servicios críticos de CVE. La extensión mantuvo el registro en funcionamiento e hizo visible su dependencia del apoyo continuo.

La continuidad por sí sola no resuelve la confianza. En 2019, VideoLAN cuestionó un problema reportado de VLC, al decir que estaba en una biblioteca de terceros corregida más de 16 meses antes, y alegó que MITRE no había verificado la afirmación subyacente. La disputa de VideoLAN muestra lo que un mantenedor afectado necesita cuando una clasificación pública es incorrecta o está desactualizada: una forma de rastrear la fuente, impugnar la descripción y hacer que una corrección llegue a quienes dependen de ella.

MITRE puede mantener el nombre común mientras NIST, CISA, proveedores y operadores emiten juicios distintos sobre la urgencia. Si una clasificación asistida por máquinas se convierte en un orden de parcheo, la institución que emite ese orden debe hacer comprensibles su evidencia y su vía de apelación; un identificador neutral no puede cargar con la responsabilidad de una decisión que tomó alguien más.

NIST hizo explícito el orden de análisis

En abril de 2026, NIST acotó el análisis detallado de la NVD a los CVE del Catálogo de Vulnerabilidades Explotadas Conocidas de CISA y a las fallas que afectan software crítico, sistemas federales o activos bajo explotación activa. NIST no anunció que los proveedores y otros participantes dejarían de asignar identificadores CVE. Cambió qué registros recibirían análisis detallado.

El catálogo de vulnerabilidades explotadas conocidas de CISA aporta una razón para priorizar: identifica fallas que los atacantes están usando, y CISA exige a las agencias federales corregir las vulnerabilidades listadas dentro de plazos establecidos. Más tarde, CISA redujo a tres días el plazo para las vulnerabilidades federales más críticas, citando el uso de IA por parte de hackers. Una señal de explotación da a un conjunto particular de operadores una fecha límite.

Priorizar la explotación conocida es una mejora frente a tratar cada etiqueta de alta gravedad como una orden de reparación igualmente urgente, pero deja brechas. Una falla no necesita aparecer en el catálogo para ser peligrosa, y una prioridad federal no necesariamente describe la exposición de un operador privado. NIST puede establecer un orden público de análisis; cada organización todavía debe determinar si ejecuta el software afectado, dónde está expuesto y qué puede desconectar de forma segura. Un operador no puede inferir seguridad de un registro de la NVD que no ha sido enriquecido.

La IA hace que un hallazgo sea más fácil de producir que de confiar

Los desarrolladores están agregando código a la cola de revisión más rápido. Una encuesta de Stack Overflow encontró que 84% de los desarrolladores usaba o planeaba usar herramientas de IA en sus flujos de trabajo, frente a 76% en 2024, mientras la confianza en la precisión de la IA cayó de 43% a 33%. Las empresas han tenido dificultades para revisar el volumen resultante de código generado. Los investigadores de seguridad pueden usar herramientas relacionadas para encontrar debilidades en ese código y en software anterior a él.

Anthropic reportó 5,500 vulnerabilidades verificadas encontradas de abril a octubre de 2026; sus socios de Glasswing reportaron más de 129,000 de abril a julio, incluidas más de 33,000 calificadas como críticas o de alta gravedad. Esos hallazgos reportados no deben tratarse como un número equivalente de nuevas entradas CVE o parches completados. Sí muestran por qué la verificación no puede dejarse como una ocurrencia posterior al descubrimiento.

La misma búsqueda barata puede enviar trabajo sin verificar a la bandeja de entrada de otra persona. Google suspendió los envíos de fallas de productos a su OSS Vulnerability Reward Program en medio de reportes inválidos impulsados por IA. Curl planeó terminar su programa de HackerOne después de que reportes de baja calidad generados por IA sobrecargaran a sus mantenedores. El problema de verificación de las recompensas por errores expone el costo que omite un conteo de hallazgos: alguien debe reproducir una afirmación, identificar la versión afectada, descartar duplicados y decidir quién es responsable de la corrección. Un investigador automatizado que solo aporta una descripción plausible transfiere ese trabajo al destinatario.

Los atacantes también enfrentan menos demoras. Un análisis del desarrollo de exploits asistido por IA citó un caso de 30 minutos entre un parche y un exploit, y sostuvo que las ventanas tradicionales de divulgación podrían volverse inviables para problemas críticos. Ese caso es un argumento sobre una posible velocidad, no un intervalo medido para todas las vulnerabilidades. Aun así, explica por qué el tiempo entre un hallazgo sólido y una respuesta autorizada importa junto con la precisión del propio hallazgo.

La prueba tiene que llegar al responsable del activo expuesto

En octubre de 2026, atacantes comprometieron controladores de refrigeración conectados a internet en cerca de 700 supermercados europeos, explotando vulnerabilidades críticas en tres modelos de controladores identificados por Claroty y CISA. Un identificador público podía nombrar cada falla. Los hallazgos de producto de Claroty y CISA podían ayudar a identificar los modelos afectados. Ningún paso, por sí solo, podía decirle a un operador de supermercado qué controladores estaban conectados ni quién podía aislar uno sin interrumpir la refrigeración.

Censys monitorea hosts de internet y su estado de seguridad. Startups que buscan la verificación formal de software, incluida &Truth, intentan producir evidencia más sólida sobre el comportamiento del software. Un operador debe conectar una afirmación creíble sobre una falla con el sistema que realmente ejecuta.

La transferencia requiere un hallazgo reproducible, un producto y una versión afectados, evidencia de accesibilidad o exposición, un responsable a cargo y una decisión de parchear, aislar o aceptar el riesgo. Cuando un modelo ayuda a hacer esa evaluación, conservar la evidencia permite que un revisor humano cuestione los datos de entrada e identifique quién aprobó la acción.

Un número CVE cabe en una etiqueta. La decisión vive junto a un controlador de refrigeración en funcionamiento, con un operador que debe decidir si aislarlo.