Resumen

  • El informe de MITRE de 2002 sitúa la presentación pública en septiembre de 1999 con 321 entradas y define la lista como puente lógico entre productos y bases existentes.
  • En el trabajo original de diseño de 1999, los autores calculaban que conectar N bases entre sí exigía del orden de N² correspondencias; un índice compartido requería N. Dejaron fuera del nombre la gravedad, el contexto local y el desempeño de cada herramienta.

La confusión empezaba antes del arreglo

Cada herramienta de seguridad guardaba su propio catálogo de vulnerabilidades. Dos resultados podían describir el mismo defecto con palabras distintas, y un aviso podía no tener un puente claro hacia la alerta de un escáner. El artículo de MITRE partió de ese problema cotidiano: para comparar bases primero hay que saber cuándo hablan del mismo objeto.

La solución no fue construir el escáner definitivo. Una entrada CVE debía contener un nombre único y una descripción suficiente para diferenciar un problema de otro. Cada base podía mantener su investigación, clasificación y producto, pero añadir una correspondencia hacia el identificador compartido. Sin índice, los enlaces entre pares crecen aproximadamente con el cuadrado del número de fuentes; con él, cada fuente mantiene un enlace hacia el centro. N² frente a N era una economía de integración, no una fórmula sobre cuántos fallos existían.

El equipo rechazó una taxonomía universal de vulnerabilidades para el catálogo común. El texto de 1999 llamaba a CVE concordancia o índice. Los detalles de categoría, exposición y prioridad podían seguir en los sistemas que tenían datos para decidirlos. La estrechez del registro facilitaba que varias empresas lo usaran sin entregar a una sola de ellas el diseño de todas las bases.

El prefijo no hacía un diagnóstico

Un nombre CVE podía parecer un dictamen técnico completo. Los autores explicaron que la cifra no codificaba gravedad ni el orden real de descubrimiento. El identificador tampoco decía si un equipo concreto tenía el componente vulnerable o si una herramienta detectaba correctamente el caso. La misma propuesta enumeró esos límites: política y configuración local, postura de riesgo y eficacia de cada producto quedaban fuera de la lista.

Dar nombre exigía, aun así, decisiones difíciles. El proceso de 1999 distinguía los candidatos CAN de las entradas aceptadas CVE. El comité editorial podía rechazar duplicados, pedir cambios, fusionar informes o dividir una descripción demasiado amplia. Un registro común no surge al pegar etiquetas en todo lo que llega; alguien tiene que determinar cuándo dos avisos son el mismo caso y cuándo no.

El balance posterior de MITRE cuenta que la primera lista pública salió con 321 entradas en septiembre de 1999. Su función era ser un puente lógico, no sustituir a los fabricantes de herramientas o a quienes escribían los parches. Un escáner podía señalar un identificador, un aviso del proveedor citarlo y una página de actualización vincular una solución. El operador todavía debía comprobar la versión instalada, aplicar el cambio correcto y probar el servicio.

Los 321 nombres eran coordenadas compartidas, no un censo de todos los defectos ni 321 reparaciones realizadas. CVE hizo posible que tres mesas de trabajo señalaran la misma grieta. La llave inglesa seguía estando fuera del índice.