Identificadores y contenido de seguridad

Cuando un escáner muestra CVE-2021-34527, el identificador parece contener una respuesta. En realidad abre varias preguntas: qué condición recibió ese nombre, quién publicó el registro, qué productos declaró afectados el proveedor, cómo reconoció el escáner el producto y qué prueba demuestra que la condición existe en este activo.

Los formatos de contenido de seguridad surgieron para que fabricantes, coordinadores, herramientas y operadores pudieran intercambiar esas piezas sin inventar un vocabulario por producto. Cada sistema describe una parte diferente. La precisión aparece al conservar sus fronteras.

El programa Common Vulnerabilities and Exposures (CVE) asigna identificadores con la forma CVE-AAAA-NNNN.... Una CVE Numbering Authority (CNA) reserva el identificador y publica el CVE Record. El programa actual es una federación internacional de CNAs. El proceso ya no debe explicarse como una única solicitud enviada siempre a MITRE.

Un CVE Record puede contener:

• descripción de la vulnerabilidad
• productos y versiones declarados afectados
• tipos de problema
• referencias
• fechas y estado del registro
• métricas aportadas por la CNA
• información adicional de participantes autorizados, denominados Authorized Data Publishers (ADP)

El identificador permite que varias fuentes hablen de la misma vulnerabilidad. No demuestra que un producto concreto esté instalado ni que una instancia sea explotable. Dos errores relacionados pueden recibir CVE distintos si requieren correcciones independientes. Una vulnerabilidad sin CVE sigue existiendo. También puede haber registros rechazados, reservados o modificados.

La fuente primaria para versiones afectadas y correcciones suele ser el aviso del fabricante. El CVE Record proporciona coordinación. La investigación debe conservar ambos y registrar si discrepan.

La National Vulnerability Database (NVD) de NIST consume registros CVE y añade análisis. Entre otros datos puede aportar:

• puntuaciones y vectores CVSS
• clasificación CWE
• configuraciones de aplicabilidad basadas en CPE
• referencias y etiquetas
• relación con el catálogo KEV de CISA

Por eso el CVE Record y la entrada NVD pueden publicarse o actualizarse en momentos distintos. Una ausencia temporal de análisis NVD no invalida el CVE. Una puntuación NVD tampoco reemplaza la valoración del proveedor o del entorno.

La API de vulnerabilidades de NVD permite recuperar un registro sin analizar HTML:

curl --silent --show-error \
  'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE_ID' |
  jq .

--silent oculta la barra de progreso, --show-error mantiene visibles los errores de transferencia y el parámetro cveId limita la respuesta al identificador indicado por CVE_ID. jq formatea el JSON. La API aplica límites de frecuencia y ofrece claves de API para consumidores recurrentes. El resultado debe conservar la marca temporal y la fuente porque el contenido puede cambiar.

Common Weakness Enumeration (CWE) organiza patrones que pueden producir vulnerabilidades: validación incorrecta de entrada, autorización ausente, uso de memoria después de liberarla o exposición de información, por ejemplo.

La relación no es uno a uno:

• una debilidad puede originar muchas vulnerabilidades
• una vulnerabilidad puede involucrar varias debilidades
• una asignación muy general puede describir la familia sin explicar la causa precisa

CWE-79 ayuda a agrupar vulnerabilidades de cross-site scripting. No identifica una instancia concreta, su versión ni su alcance. En un informe, CWE puede apoyar el análisis de causa raíz y la remediación transversal. CVE identifica la vulnerabilidad publicada cuando existe.

Common Platform Enumeration (CPE) ofrece nombres estructurados para hardware, sistemas operativos y aplicaciones. NVD utiliza CPE y lógica de rangos para expresar configuraciones potencialmente afectadas.

El problema difícil aparece antes de la comparación: determinar qué producto real representa un banner, paquete o fichero. Distribuciones Linux pueden aplicar backports de seguridad sin cambiar la versión upstream de la forma que espera una firma. Un proveedor puede reutilizar un componente y ocultar su versión. Un appliance puede mostrar la versión de su interfaz, no la del paquete vulnerable.

Una coincidencia CPE necesita al menos:

1. identidad fiable del producto y fabricante
2. edición, plataforma o variante cuando cambien la aplicabilidad
3. versión normalizada con el esquema del proveedor
4. interpretación correcta de límites incluidos y excluidos
5. confirmación de que el componente vulnerable está presente y activo

La cadena CPE es un artefacto de correlación. No debe presentarse como prueba del host.

El Open Vulnerability and Assessment Language (OVAL) describe objetos, estados, pruebas, variables y definiciones en un formato procesable. Puede representar preguntas como «¿está instalado este paquete por debajo de una versión?» o «¿tiene esta clave de configuración cierto valor?».

Las clases de definiciones suelen cubrir vulnerabilidad, cumplimiento, inventario y parche. Una evaluación OVAL compara el estado recogido con los criterios de la definición. El resultado depende de que:

• la definición represente correctamente el producto
• el recolector pueda acceder al objeto
• la versión o configuración se normalice como espera el contenido
• la definición esté actualizada
• los errores de recogida no se conviertan en false

Un resultado not evaluated, unknown o equivalente conserva incertidumbre. No es lo mismo que una comprobación negativa.

El Security Content Automation Protocol (SCAP) de NIST integra especificaciones para expresar, identificar, medir y evaluar configuración y vulnerabilidades. SCAP 1.4 es la revisión actual publicada por NIST en 2026. Entre sus componentes se encuentran OVAL, CPE, CVE, CWE, CVSS y formatos de checklist y resultados.

SCAP permite que contenido de seguridad y herramientas compartan estructuras. No garantiza por sí mismo que una política sea adecuada, que el contenido cubra la versión desplegada o que la recolección tenga privilegios suficientes.

Para investigar una detección conviene separar cinco capas:

Una conclusión fuerte enlaza las cinco. Si falta una, se registra la limitación. Por ejemplo:

El plugin asoció el banner a CVE_ID. El aviso del fabricante declara afectadas las versiones anteriores a FIXED_VERSION. El host autenticado informa PACKAGE_VERSION, pero la distribución aplica backports. Falta contrastar el changelog del paquete para confirmar si contiene el parche.

Ese texto es más útil que repetir la descripción del CVE. Explica qué se sabe, de dónde procede y qué observación resolvería la duda.

Un CVE puede recibir nuevas referencias. NVD puede recalcular una puntuación. El fabricante puede ampliar el rango afectado. KEV puede incorporar explotación conocida. Un informe necesita conservar la fecha de consulta y, cuando la decisión dependa del dato, una copia o hash del artefacto recuperado.

También conviene distinguir:

• publicado: existe un registro o aviso
• afectado: el producto y versión entran en las condiciones declaradas
• presente: el componente se ha observado en el activo
• alcanzable: la ruta necesaria está disponible desde la posición considerada
• explotable: se cumplen los prerrequisitos técnicos
• validado: la evaluación ha producido evidencia suficiente para la conclusión acordada

El salto directo de publicado a validado es una de las causas más frecuentes de falsos positivos.

• CVE Record User Guide
• CVE Program: Process
• NVD Vulnerability API
• MITRE: About CWE
• NIST: Security Content Automation Protocol
• NIST: SCAP 1.4