VEX para cumplimiento CRA: guía de intercambio de explotabilidad de vulnerabilidades

No todas las vulnerabilidades en tu SBOM afectan a tu producto. VEX (Vulnerability Exploitability eXchange - Intercambio de Explotabilidad de Vulnerabilidades) te permite comunicar cuáles vulnerabilidades realmente aplican a tu producto y contexto específico. Para el cumplimiento del CRA, VEX ayuda a demostrar que has evaluado las vulnerabilidades y abordado las que importan.

Esta guía explica cómo usar VEX efectivamente.

¿Qué es VEX?

El problema que VEX resuelve

Cuando escaneas un SBOM, obtienes una lista de vulnerabilidades en componentes:

RESULTADOS DE ESCANEO SBOM (Tipico):

Componente: openssl 1.1.1k
  - CVE-2021-3711 (Crítico)
  - CVE-2021-3712 (Alto)
  - CVE-2022-0778 (Alto)

Componente: zlib 1.2.11
  - CVE-2018-25032 (Alto)

Componente: libxml2 2.9.10
  - CVE-2021-3517 (Alto)
  - CVE-2021-3518 (Alto)
  - CVE-2022-23308 (Medio)

TOTAL: 8 vulnerabilidades encontradas

PERO ESPERA...
- ¿Todas estas realmente afectan a tu producto?
- ¿Se usa la ruta de código vulnerable?
- ¿Ya has mitigado algunas?
- ¿Algunas no son explotables en tu contexto?

VEX responde estas preguntas.

Definicion de VEX

VEX (Vulnerability Exploitability eXchange) es un formato estandarizado para comunicar:

• Si una vulnerabilidad afecta a un producto específico
• Por qué o por que no
• qué acciones (si las hay) son necesarias
• Estado actual de la Evaluación

Tipos de Estado VEX

OPCIONES DE ESTADO VEX

NO AFECTADO:
"Esta vulnerabilidad no afecta a nuestro producto"
- Código vulnerable no presente
- función vulnerable no llamada
- Plataforma no aplicable
- Mitigado por Configuración

AFECTADO:
"Esta vulnerabilidad afecta a nuestro producto"
- Requiere accion
- Puede incluir mitigaciones recomendadas
- Indica severidad en contexto

CORREGIDO:
"Esta vulnerabilidad fue corregida"
- En version específica
- Detalles de la corrección proporcionados
- Recomendacion de actualización

BAJO INVESTIGACION:
"Todavia estamos evaluando esto"
- Estado aun no determinado
- Investigación en curso
- Estado temporal

VEX y Requisitos del CRA

Requisitos de Vulnerabilidad del CRA

El CRA requiere que los fabricantes:

1. Sin vulnerabilidades explotables conocidas (al comercializar)
2. Gestionar vulnerabilidades durante el período de soporte
3. Proporcionar actualizaciones de seguridad para corregir vulnerabilidades
4. Notificar vulnerabilidades activamente explotadas a ENISA (24h)
5. Notificar vulnerabilidades severas a ENISA (72h)

Cómo VEX Apoya al CRA

VEX PARA CUMPLIMIENTO CRA

REQUISITO: Sin vulnerabilidades explotables conocidas

ROL DE VEX:
- Documentar la evaluación de vulnerabilidades
- Mostrar cuales CVEs fueron evaluados
- Demostrar determinaciones de "no afectado"
- Evidencia para expediente técnico

REQUISITO: Gestionar vulnerabilidades

ROL DE VEX:
- Rastrear cambios de estado de vulnerabilidades
- Documentar progresion "afectado" → "corregido"
- Comunicar con clientes
- Mantener pista de auditoria

REQUISITO: Actualizaciones de seguridad

ROL DE VEX:
- Documentar qué se corrigio en cada actualización
- Proporcionar información "corregido en version X"
- Herramienta de comunicación con clientes

REQUISITO: Notificación a ENISA

ROL DE VEX:
- La pre-Evaluación ayuda a determinar si hay obligación de notificar
- "Afectado" + "activamente explotado" = notificar
- documentación para precisión de la notificación

Formatos VEX

CycloneDX VEX

CycloneDX incluye capacidad VEX como parte del formato SBOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2021-3711",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_present",
        "detail": "Nuestro producto usa OpenSSL pero no usa la funcionalidad SM2 donde existe esta vulnerabilidad. SM2 no esta compilado en nuestra build."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ]
    },
    {
      "id": "CVE-2022-0778",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "exploitable",
        "detail": "El producto esta afectado al procesar certificados no confiables. Corregido en version 2.1.0."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ],
      "recommendation": "Actualizar a la version 2.1.0 o posterior del producto"
    }
  ]
}

CSAF VEX

CSAF (Common Security Advisory Framework) proporciona un formato de documento VEX independiente:

{
  "document": {
    "category": "csaf_vex",
    "title": "Evaluación de Seguridad del Producto para CVE-2021-3711",
    "publisher": {
      "category": "vendor",
      "name": "Empresa Ejemplo"
    },
    "tracking": {
      "id": "EX-2024-001",
      "status": "final",
      "version": "1.0.0",
      "current_release_date": "2024-01-15T10:00:00Z"
    }
  },
  "product_tree": {
    "branches": [
      {
        "category": "product_name",
        "name": "Smart Sensor Pro",
        "product": {
          "product_id": "SSP-2.0",
          "name": "Smart Sensor Pro 2.0"
        }
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2021-3711",
      "product_status": {
        "known_not_affected": ["SSP-2.0"]
      },
      "flags": [
        {
          "label": "vulnerable_code_not_present",
          "product_ids": ["SSP-2.0"]
        }
      ],
      "notes": [
        {
          "category": "description",
          "text": "La funcionalidad SM2 no esta incluida en nuestra build de OpenSSL."
        }
      ]
    }
  ]
}

OpenVEX

OpenVEX es un formato VEX más simple y enfocado:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://ejemplo.com/vex/2024-001",
  "author": "Equipo de Seguridad Empresa Ejemplo",
  "timestamp": "2024-01-15T10:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "CVE-2021-3711"
      },
      "products": [
        {
          "@id": "pkg:generic/smart-sensor-pro@2.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "La funcionalidad criptografica SM2 no esta compilada en la build de OpenSSL de nuestro producto."
    }
  ]
}

Creando declaraciones VEX

Proceso de Evaluación

FLUJO DE TRABAJO DE evaluación VEX

PASO 1: IDENTIFICAR VULNERABILIDAD
- De resultados de escaneo SBOM
- De aviso de seguridad
- De notificación del cliente
- De Notificación ENISA

PASO 2: ANALIZAR APLICABILIDAD
Preguntas a responder:
- ¿Esta el componente vulnerable en nuestro producto?
- ¿Esta presente la version vulnerable?
- ¿Se usa la ruta de código vulnerable?
- ¿Es la vulnerabilidad explotable en nuestro contexto?
- ¿Ya existen mitigaciones?

PASO 3: DETERMINAR ESTADO
Basado en el analisis:
- NOT_AFFECTED: La vulnerabilidad no aplica
- AFFECTED: La vulnerabilidad aplica, se necesita accion
- FIXED: Estaba afectado, ahora remediado
- UNDER_INVESTIGATION: Todavia evaluando

PASO 4: DOCUMENTAR JUSTIFICACION
Para NOT_AFFECTED, especificar por que:
- vulnerable_code_not_present
- vulnerable_code_cannot_be_controlled_by_adversary
- vulnerable_code_not_in_execute_path
- inline_mitigations_already_exist

PASO 5: CREAR DOCUMENTO VEX
- Usar el formato elegido
- Incluir todos los campos requeridos
- Versionar y fechar el documento
- Firmar si es posible

Tipos de Justificacion

JUSTIFICACIONES NOT_AFFECTED

VULNERABLE_CODE_NOT_PRESENT:
"El código vulnerable no esta incluido en nuestra build"
Ejemplo: OpenSSL compilado sin soporte SM2

VULNERABLE_CODE_CANNOT_BE_CONTROLLED_BY_ADVERSARY:
"Un atacante no puede alcanzar el código vulnerable"
Ejemplo: función solo llamada con datos internos confiables

VULNERABLE_CODE_NOT_IN_EXECUTE_PATH:
"La función vulnerable nunca se llama"
Ejemplo: Libreria incluida pero función específica no usada

INLINE_MITIGATIONS_ALREADY_EXIST:
"Otros controles previenen la explotación"
Ejemplo: WAF bloquea el vector de ataque, sandboxing limita impacto

Ejemplos de Evaluación

EJEMPLO 1: No Afectado (Código No Presente)

Vulnerabilidad: CVE-2021-3711 (desbordamiento de buffer SM2 de OpenSSL)
Componente: openssl 1.1.1k
Evaluación: Nuestro producto usa OpenSSL solo para TLS.
            SM2 es un estandar criptografico chino qué no usamos.
            Nuestra build explicitamente deshabilita SM2: ./config no-sm2
Estado: NOT_AFFECTED
Justificacion: vulnerable_code_not_present

EJEMPLO 2: No Afectado (No en Ruta de Ejecucion)

Vulnerabilidad: CVE-2022-23308 (use-after-free de libxml2)
Componente: libxml2 2.9.10
Evaluación: Vulnerabilidad en evaluación XPath con namespaces.
            Nuestro producto solo usa libxml2 para parsing XML simple.
            Nunca usamos funcionalidad XPath.
Estado: NOT_AFFECTED
Justificacion: vulnerable_code_not_in_execute_path

EJEMPLO 3: Afectado

Vulnerabilidad: CVE-2022-0778 (bucle infinito OpenSSL)
Componente: openssl 1.1.1k
Evaluación: Nuestro producto procesa certificados TLS de
            fuentes potencialmente no confiables. La vulnerabilidad
            permite DoS via certificado malicioso.
Estado: AFFECTED
Recomendacion: Actualizar a version 2.1.0 del producto (OpenSSL 1.1.1n)

EJEMPLO 4: Corregido

Vulnerabilidad: CVE-2022-0778 (bucle infinito OpenSSL)
Componente: openssl (era 1.1.1k, ahora 1.1.1n)
Evaluación: Corregido en version 2.1.0 del producto
Estado: FIXED
Version Corregida: 2.1.0

Flujo de Trabajo VEX para CRA

Evaluación continua

PROCESO VEX CONTINUO

DIARIO/SEMANAL:
1. Escanear SBOM por nuevas vulnerabilidades
2. Priorizar por severidad
3. Comenzar evaluación de criticas/altas

PARA CADA VULNERABILIDAD:
1. Analisis técnico
2. Determinar estado
3. Crear/actualizar Declaración VEX
4. Si AFFECTED: planificar remediación

CUANDO SE CORRIGE:
1. Actualizar estado VEX a FIXED
2. Referenciar version de corrección
3. Notificar a clientes
4. Actualizar expediente técnico

PARA NOTIFICACIÓN A ENISA:
1. AFFECTED + activamente explotado → Notificar 24h
2. AFFECTED + severo → Notificar 72h
3. Incluir VEX en contexto de la notificación

Integración con SBOM

Integración SBOM + VEX

OPCION 1: VEX Embebido (CycloneDX)
- Datos VEX dentro del documento SBOM
- Un solo archivo para componentes + vulnerabilidades
- Actualizar SBOM cuando cambia VEX

OPCION 2: VEX Vinculado
- Documento VEX separado
- Referencias componentes del SBOM
- Se puede actualizar independientemente

OPCION 3: Avisos CSAF
- Avisos de seguridad independientes
- Publicados en página de seguridad
- Legibles por maquina para automatización

RECOMENDACION PARA CRA:
- Usar VEX embebido para expediente técnico (registro completo)
- Publicar avisos CSAF para comunicación con clientes
- Mantener ambos, sincronizados

Comunicación con Clientes

VEX PARA COMUNICACION CON CLIENTES

ESCENARIO: Cliente pregunta "¿CVE-XXXX afecta a su producto?"

CON VEX:
1. Consultar base de datos VEX por la vulnerabilidad
2. Proporcionar estado inmediatamente
3. Si NOT_AFFECTED: compartir justificacion
4. Si AFFECTED: proporcionar orientación de remediación
5. Si UNDER_INVESTIGATION: proporcionar cronograma

BENEFICIOS:
- Respuestas consistentes en el equipo de soporte
- Justificaciones pre-preparadas
- Tiempo de respuesta mas rápido
- Debida diligencia demostrable

VEX en el expediente técnico

Enfoque de Documentación

sección VEX DEL EXPEDIENTE TECNICO

sección: evaluación de Vulnerabilidades (VEX)

CONTENIDOS:
1. Descripción de metodologia VEX
2. Documento VEX actual (todos los productos)
3. Actualizaciones VEX historicas (pista de auditoria)
4. Evidencia de justificacion no-afectado

EJEMPLO DE ENTRADA:
"A fecha de [fecha], las siguientes vulnerabilidades han sido
evaluadas para [Nombre del Producto] version [X.Y.Z]:

Total de CVEs en dependencias de componentes: 47
- No Afectados: 41
- Corregidos: 4
- Bajo Investigación: 2
- Afectados (con mitigacion): 0

Documento VEX: [enlace/adjunto]
Última actualización: [fecha]"

Evidencia de "sin vulnerabilidades explotables conocidas"

EVIDENCIA DE CUMPLIMIENTO CRA

AFIRMACION: El producto no tiene vulnerabilidades explotables conocidas

EVIDENCIA (basada en VEX):
1. Resultados de escaneo SBOM (fechados)
2. evaluación VEX cubriendo todos los hallazgos
3. Para cada "No Afectado": justificacion
4. Para cada "Corregido": información de version
5. Para "Bajo Investigación": cronograma/estado

PISTA DE AUDITORIA:
- ¿Cuando fue evaluado cada CVE?
- ¿Quién realizo la Evaluación?
- ¿Cual fue la justificacion?
- ¿Cuando se actualizo el estado?

Herramientas y Automatización

Herramientas de Generación VEX

OPCIONES DE HERRAMIENTAS VEX

SBOM + COINCIDENCIA DE VULNERABILIDADES:
- Grype (Anchore) - genera VEX
- Trivy - escaneo de vulnerabilidades con salida VEX
- OWASP Dependency-Track - soporte VEX

AUTORIA VEX:
- CycloneDX CLI - crear/validar VEX
- herramientas CSAF - crear documentos CSAF VEX
- herramientas OpenVEX - creacion VEX simple

AUTOMATIZACION:
- Integración CI/CD para escaneo
- Estado automatico "bajo investigación"
- Revision manual para estado final

Estrategia de Automatización

ENFOQUE DE AUTOMATIZACION VEX

AUTOMATIZADO:
- Escaneo SBOM por nuevos CVEs
- Estado inicial "bajo investigación"
- Notificación al equipo de seguridad
- Verificaciones basicas de aplicabilidad

SEMI-AUTOMATIZADO:
- Sugerencias de analisis de ruta de código
- Coincidencia de patrones historicos
- Busqueda de estado de productos similares

MANUAL (Requerido):
- Determinacion final de estado
- Escritura de justificacion
- Comunicaciones orientadas al cliente
- Decisiones de notificación a ENISA

Desafíos comunes

Desafío: volumen de CVEs

Problema: Los escaneos SBOM devuelven cientos de CVEs.

Soluciones:

• Priorizar por severidad (Crítico/Alto primero)
• Usar automatización para triaje inicial
• Construir plantillas de justificación para patrones comunes
• Enfocarse en componentes que controlas

Desafío: dificultad del análisis técnico

Problema: Difícil determinar si se usa el código vulnerable.

Soluciones:

• Trabajar con el equipo de desarrollo
• Usar herramientas de análisis estático
• Documentar incertidumbre apropiadamente
• Enfoque conservador: en caso de duda, tratar como afectado

Desafío: mantener VEX actualizado

Problema: El estado de vulnerabilidades cambia con el tiempo.

Soluciones:

• Automatizar re-escaneo de SBOM
• Revisiones VEX programadas
• Actualizaciones basadas en disparadores (nuevo CVE, nueva versión)
• Versionar tus documentos VEX

Lista de Verificación VEX

LISTA DE verificación DE IMPLEMENTACION VEX

Configuración:
[ ] Formato VEX elegido (CycloneDX VEX recomendado)
[ ] Proceso de evaluación definido
[ ] Responsabilidad asignada
[ ] Herramientas configuradas

Evaluación INICIAL:
[ ] SBOM escaneado por vulnerabilidades
[ ] Priorizado por severidad
[ ] Cada vulnerabilidad evaluada
[ ] Justificaciones documentadas

PROCESO CONTINUO:
[ ] Cronograma de re-escaneo SBOM regular
[ ] Monitorización de nuevos CVEs
[ ] SLA de evaluación (p.ej., Crítico: 24h)
[ ] Actualizaciones de documento VEX

Documentación:
[ ] VEX incluido en expediente técnico
[ ] Historial de versiones mantenido
[ ] Justificaciones detalladas
[ ] Publicación orientada al cliente

Integración:
[ ] Vinculado al SBOM
[ ] Proceso de comunicación con clientes
[ ] Flujo de trabajo de notificación a ENISA
[ ] Notas de version de actualizaciones

Recursos clave

RECURSOS VEX

ESTANDARES:
CycloneDX VEX: https://cyclonedx.org/capabilities/vex/
CSAF: https://docs.oasis-open.org/csaf/
OpenVEX: https://openvex.dev

ORIENTACION:
CISA VEX Status Justifications
NTIA VEX Minimum Elements

HERRAMIENTAS:
Grype: https://github.com/anchore/grype
Trivy: https://aquasecurity.github.io/trivy/
CycloneDX CLI: https://github.com/CycloneDX/cyclonedx-cli

Cómo ayuda CRA Evidence

CRA Evidence proporciona soporte VEX integral:

• VEX integrado: Gestiona VEX junto con SBOM
• Flujo de Evaluación: Análisis estructurado de vulnerabilidades
• Seguimiento de estado: Rastrea cambios a lo largo del tiempo
• Plantillas de justificación: Patrones comunes pre-construidos
• Integración de expediente técnico: VEX en documentación de cumplimiento
• Portal de clientes: Comparte estado VEX con clientes

Comienza tu cumplimiento CRA en craevidence.com.

Artículos relacionados

• SBOM para Cumplimiento CRA: guía Completa de Software Bill of Materials -- VEX complementa al SBOM -- aprende a construir la base primero.
• Notificación de Vulnerabilidades CRA a ENISA: Qué Activa el Reloj de 24 Horas -- Comprende las obligaciones de notificación 24h/72h para vulnerabilidades que clasifiques como "Afectado".
• Generación de SBOM CRA: guía de Herramientas y Automatización -- Automatiza la generación de SBOM y VEX en tu pipeline CI/CD.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados.