VEX y CSAF: evidencias auditables de vulnerabilidades

El aviso de las 07:40 que convierte un SBOM en un problema para el consejo de administración

A las 07:40 de un martes por la mañana a comienzos de 2026, Anya, CISO de una plataforma fintech en rápido crecimiento, recibe en formato CSAF un aviso crítico de un proveedor. Se ha identificado una vulnerabilidad de ejecución remota de código en una biblioteca de código abierto ampliamente utilizada. Su SBOM confirma que la biblioteca está integrada en la aplicación principal de procesamiento de pagos, en dos servicios internos y en un componente de analítica externalizado.

A las 08:10, su teléfono no deja de sonar. Ingeniería quiere saber si la función vulnerable es alcanzable. Cumplimiento quiere saber si esto afecta a ISO/IEC 27001:2022, NIS2 o DORA. Asesoría jurídica pregunta si el Cyber Resilience Act podría exigir comunicación a clientes o autoridades. Un miembro del consejo de administración, recién formado en la responsabilidad proactiva de la dirección bajo NIS2, formula la pregunta que todos tienen en mente:

¿Estamos afectados?

La primera respuesta de ingeniería es técnicamente honesta: el paquete existe, pero puede que la función vulnerable no se invoque en producción. En 2026, esa respuesta no basta.

El consejo de administración quiere evidencias. Los clientes quieren una respuesta clara. Compras quiere saber si el proveedor cumplió sus obligaciones contractuales de divulgación. El delegado de protección de datos (DPO) quiere saber si podrían quedar expuestos datos personales. Un auditor de ISO 27001 no aceptará “lo dijo el desarrollador” como evidencia conservada. Un auditor de DORA esperará que la vulnerabilidad esté vinculada a activos TIC, funciones críticas y dependencias de terceros.

Aquí es donde VEX y CSAF dejan de ser formatos técnicos y pasan a formar parte de la infraestructura de gobernanza.

CSAF, el Common Security Advisory Framework, estructura los avisos de vulnerabilidades para que personas y máquinas puedan procesar productos afectados, versiones, directrices de remediación, referencias e información de estado. VEX, Vulnerability Exploitability eXchange, aporta la capa de decisión. Indica a las partes interesadas si una vulnerabilidad conocida es realmente explotable en un producto, servicio o entorno específico.

Los resultados prácticos de estado VEX son simples: afectado, no afectado, corregido y en investigación. La gobernanza que los sustenta no lo es. Cada estado necesita evidencias, un propietario, una justificación, aprobación y un desencadenante de revisión.

La brecha de cumplimiento ya no es la ausencia de SBOM. Muchas organizaciones ya tienen SBOM. La brecha está en demostrar cómo se trió cada aviso de vulnerabilidad, quién aprobó la decisión de estado, qué evidencias respaldaron una conclusión de “no afectado”, cómo se priorizó la remediación cuando el producto estaba “afectado” y cómo conservó la organización esa pista para auditores, reguladores, clientes y dirección.

Clarysec trata VEX y CSAF como parte del modelo operativo del SGSI. En Zenith Blueprint: una hoja de ruta de 30 pasos para auditores, esto pertenece a las fases de gestión de riesgos, seguridad de proveedores, controles tecnológicos y evidencias. En Zenith Controls: la guía de cumplimiento cruzado, el mismo tema conecta los controles de ISO/IEC 27001:2022 con la seguridad de la cadena de suministro TIC, la gestión de vulnerabilidades, el manejo de evidencias, NIS2, DORA, GDPR y las expectativas de NIST.

Por qué los SBOM generan señales, pero VEX genera evidencias

Un SBOM es una lista de materiales de software. Indica qué contiene un producto o servicio. Cuando aparece un CVE en uno de esos componentes, el SBOM indica que podrías estar afectado.

Esa señal es valiosa, pero no es una conclusión.

Un entorno de software maduro puede generar miles de coincidencias de vulnerabilidades en SBOM. Muchas son riesgos reales. Muchas no son explotables porque el código vulnerable no se distribuye, no se importa, no es alcanzable, no está configurado, no está expuesto a entradas no confiables o está mitigado por controles compensatorios. Sin un proceso formal para registrar la investigación, los equipos suelen caer en uno de dos patrones deficientes.

El primero es el agotamiento del triaje. Los ingenieros persiguen cada coincidencia de vulnerabilidad con la misma urgencia, incluso cuando el componente es una dependencia de compilación, una ruta de código inactiva o una funcionalidad solo interna protegida por controles en capas.

El segundo es la aceptación del riesgo no documentada. Los equipos cierran tickets con comentarios breves como “no aplicable” o “falso positivo”. Puede parecer eficiente, pero para un auditor es una decisión no controlada. Para un regulador, puede parecer una vulnerabilidad no gestionada.

VEX y CSAF resuelven esto al convertir el ruido de vulnerabilidades en evidencias de vulnerabilidades estructuradas y auditables.

Un proceso defendible de gobernanza de VEX y CSAF responde a cinco preguntas:

1. ¿Recibimos o identificamos el aviso?
2. ¿Lo mapeamos con productos, activos, proveedores, clientes y flujos de datos personales?
3. ¿Determinamos el estado de la vulnerabilidad mediante criterios definidos?
4. ¿Documentamos la decisión, las evidencias, el propietario, la aprobación y el desencadenante de revisión?
5. ¿Remediamos, divulgamos, supervisamos o conservamos evidencias en función del riesgo?

La diferencia entre “no afectado” e “ignorado” son las evidencias.

Un estado VEX de “no afectado” debe estar respaldado por una justificación, por ejemplo, que el componente vulnerable no está presente, que la versión vulnerable no está desplegada, que la ruta de código vulnerable no se ejecuta, que la configuración vulnerable está deshabilitada o que un control compensatorio impide la explotación. “En investigación” debe tener un seguimiento con plazo definido, no convertirse en un cementerio del backlog. “Corregido” debe apuntar a un parche, mitigación, actualización de versión, resultado de prueba y registro de despliegue. “Afectado” debe entrar en tratamiento de riesgos, planificación de remediación, notificación al proveedor, comunicación al cliente y, cuando proceda, flujos de trabajo de evaluación de incidentes o brechas.

El modelo de gobernanza de Clarysec para las decisiones de estado VEX

Cada aviso CSAF y cada declaración VEX deben tratarse como un registro controlado dentro del SGSI, no como un artefacto aislado de ingeniería. El flujo de trabajo puede residir en una plataforma GRC, una herramienta de gestión de vulnerabilidades, un sistema de tickets, un flujo de trabajo de control de código fuente o un libro de evidencias de Clarysec. Lo importante es que el estado, las evidencias, la aprobación y el tratamiento de riesgos permanezcan vinculados.

Esta tabla parece simple, pero cambia el entorno de control. Una declaración de “no afectado” se convierte en una mini decisión de riesgo para un producto y entorno concretos. Un estado “corregido” vincula la gestión de vulnerabilidades con la gestión de cambios y las pruebas. Un estado “afectado” desencadena tratamiento, escalado y posible divulgación. Un estado “en investigación” ofrece a la dirección un riesgo visible y con plazo definido.

Zenith Blueprint refuerza esta mentalidad en el paso 13 sobre planificación del tratamiento de riesgos y la Declaración de Aplicabilidad. Explica que las decisiones de control deben justificarse por el tratamiento de riesgos, los requisitos legales o contractuales, la relevancia del alcance y el contexto organizativo:

“En la hoja de la SoA, marque cada control como ‘Sí’ (aplicable) o ‘No’ (no aplicable). Proporcione una justificación/notas.”

Para VEX, “no afectado” sigue la misma disciplina. No es un cierre informal de ticket. Es una decisión justificada que debe resistir una revisión.

El paso 19 de Zenith Blueprint aborda la gestión de vulnerabilidades técnicas:

“Manténgase informado sobre nuevos fallos de seguridad (mediante alertas de proveedores, feeds CVE, etc.) para su software y hardware. Evalúe cuáles son relevantes (¿utilizamos este software?, ¿qué criticidad tiene el fallo?) y aplique correcciones o mitigaciones con prontitud.”

CSAF ayuda a recibir avisos estructurados. Los SBOM ayudan a determinar la presencia de componentes. VEX ayuda a documentar la explotabilidad y el estado. El SGSI gobierna la decisión.

Evidencias de políticas antes de que llegue el aviso crítico

Un programa VEX fracasa cuando el primer aviso crítico llega antes de que existan roles, criterios y requisitos de evidencias. Las políticas ya deben definir la recepción de vulnerabilidades, el escalado, el registro, las obligaciones de proveedores, la gestión de excepciones y la conservación de evidencias.

Para pymes, la Política de gestión de vulnerabilidades y parches - pyme establece la obligación de supervisión:

“Supervisa los sistemas en busca de vulnerabilidades y parches disponibles mediante alertas de proveedores, avisos de inteligencia de amenazas y notificaciones del sistema operativo”

Esta cláusula, de roles y responsabilidades, cláusula de política 4.2.1, se aplica directamente a la recepción de CSAF. Los avisos CSAF son avisos de vulnerabilidades de proveedores o del ecosistema que deben supervisarse, correlacionarse y triarse.

La misma política para pymes establece expectativas de preparación para auditorías:

“Mantener registros precisos de los parches aplicados, los problemas pendientes y las excepciones para garantizar la preparación para auditorías”

Desde objetivos, cláusula de política 3.4, aquí es donde VEX se convierte en algo más que un archivo técnico. Si un equipo no aplica un parche porque un producto “no está afectado”, esa excepción necesita evidencias, aprobación y trazabilidad.

Para entornos empresariales, la Política de gestión de vulnerabilidades y parches es explícita:

“Supervisar los avisos de amenazas (por ejemplo, CVE, CISA KEV, boletines de proveedores) y escalar las vulnerabilidades críticas.”

Desde roles y responsabilidades, cláusula de política 4.5.1, esta cláusula respalda un canal estructurado de recepción para CSAF, CVE, boletines de proveedores e inteligencia de exploits. También exige escalado cuando un estado VEX es “afectado” o “en investigación” para un producto crítico.

La política empresarial también establece:

“Todas las vulnerabilidades críticas y de alto riesgo deben registrarse en el Registro de Riesgos del SGSI y supervisarse hasta su remediación o hasta quedar cubiertas por una excepción aprobada.”

Esta cláusula, de requisitos de gobernanza, cláusula de política 5.3, es el ancla de cumplimiento. Una declaración VEX de “no afectado” para un CVE crítico solo es defendible cuando se trata como una excepción aprobada con evidencias. Una declaración VEX de “corregido” solo cierra el ciclo cuando la remediación se verifica.

La calificación del riesgo también necesita contexto. La misma política se refiere a:

“Evaluación de riesgos (basada en CVSS, criticidad del activo, inteligencia de amenazas)”

Desde tratamiento de riesgos y excepciones, cláusula de política 7.2.2, esto respalda un modelo de triaje combinado. CVSS por sí solo no basta. Una vulnerabilidad de severidad media explotada activamente en un componente crítico de identidad puede ser más urgente que un problema CVSS crítico en código no alcanzable.

Las políticas de aplicaciones y desarrollo seguro extienden la misma disciplina a ingeniería y proveedores. La Política de requisitos de seguridad de las aplicaciones - pyme exige a los equipos realizar seguimiento de:

“vulnerabilidades conocidas y estado de remediación.”

Desde requisitos de implementación de la política, cláusula de política 6.4.2.3, esto se mapea de forma directa con los estados VEX. La misma política exige que los acuerdos:

“especifiquen obligaciones de divulgación de vulnerabilidades, tiempos de respuesta y aplicación de parches.”

Desde requisitos de gobernanza, cláusula de política 5.3.2, esto se convierte en una cláusula práctica para proveedores: proporcionar avisos oportunos, identificar versiones afectadas, emitir el estado VEX cuando sea posible, definir plazos de remediación y apoyar la divulgación al cliente.

Para el desarrollo seguro empresarial, la Política de Desarrollo Seguro espera:

“Escaneo de vulnerabilidades conocidas (CVE, OSS Index, etc.)”

Desde requisitos de gobernanza, cláusula de política 5.4.3, esto proporciona a ingeniería un mecanismo definido para correlacionar avisos con componentes y activar el análisis VEX.

Cuando una vulnerabilidad se convierte en un incidente o en un posible asunto legal, la disciplina de evidencias pasa a ser esencial. La Política de recopilación de evidencias y análisis forense - pyme establece:

“Debe mantenerse un registro sencillo de cadena de custodia (por ejemplo, archivo Excel o documento de plantilla) para cada incidente.”

Desde requisitos de gobernanza, cláusula de política 5.3.1, esta es la frontera entre el triaje VEX rutinario y el manejo de evidencias con nivel de incidente. Si se sospecha explotación, los registros, los registros de avisos, las notas de análisis, las comunicaciones y los artefactos forenses necesitan trazabilidad.

Mapeo de VEX y CSAF con ISO 27001, NIS2, DORA, GDPR y CRA

Los programas VEX más sólidos no son proyectos independientes de ingeniería de seguridad. Se mapean con el sistema de controles que la organización ya utiliza.

Bajo ISO/IEC 27001:2022, el SGSI debe tener en cuenta las partes interesadas, las obligaciones legales y contractuales, las interfaces y las dependencias con otras organizaciones. Esa lógica de alcance es esencial para VEX porque los avisos de proveedores, los compromisos con clientes, los componentes de código abierto y los servicios externalizados afectan a las decisiones sobre vulnerabilidades.

Los controles más relevantes del Anexo A incluyen 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información dentro de los acuerdos con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro TIC, 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores, 5.28 Recopilación de evidencias y 8.8 Gestión de vulnerabilidades técnicas. Los controles de desarrollo seguro 8.25 a 8.29 también son relevantes cuando la organización crea software o productos digitales.

NIS2 aumenta la presión de gobernanza. Article 21 exige medidas técnicas, operativas y organizativas adecuadas, incluido el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la adquisición, el desarrollo y el mantenimiento seguros, la gestión y divulgación de vulnerabilidades, la eficacia del control, la higiene cibernética, la criptografía, la seguridad de RR. HH., el control de acceso, la gestión de activos y la autenticación. Article 20 exige que los órganos de dirección aprueben y supervisen las medidas de gestión de riesgos de ciberseguridad. Esto hace que las métricas VEX sean adecuadas para informar al consejo de administración.

DORA se aplica desde el 17 de enero de 2025 a las entidades financieras incluidas en su ámbito. Exige un marco de gestión del riesgo de las TIC, identificación y clasificación de activos TIC, vulnerabilidades, dependencias y servicios TIC de terceros, gestión de incidentes, pruebas de resiliencia, gestión de riesgos de terceros y supervisión por la dirección. Para las entidades financieras, los registros VEX son especialmente útiles cuando un aviso de proveedor debe vincularse a funciones críticas o importantes, obligaciones contractuales y clasificación de incidentes.

GDPR entra en juego cuando la explotación podría afectar a datos personales. Una interfaz de programación de aplicaciones, biblioteca o servicio vulnerable que pudiera exponer registros de clientes requiere una evaluación frente a criterios de confidencialidad, integridad, disponibilidad y notificación de brechas. Una conclusión VEX de “no afectado” puede respaldar una decisión de no notificar, pero solo si la organización puede demostrar por qué no se produjo una brecha de datos personales.

El Cyber Resilience Act añade gobernanza de producto. A medida que entren en vigor las obligaciones del CRA, los fabricantes y otros operadores económicos necesitarán procesos repetibles de gestión de vulnerabilidades, actualizaciones de seguridad, divulgación coordinada y evidencias. CSAF puede estructurar los avisos. VEX puede aclarar qué productos y versiones están afectados, corregidos o no afectados.

Qué aporta la guía de cumplimiento cruzado de Clarysec

Zenith Controls es valioso porque mapea el trabajo técnico con las expectativas de auditoría y los marcos superpuestos. Para VEX y CSAF, tres áreas importan especialmente: seguridad de la cadena de suministro TIC, gestión de vulnerabilidades técnicas y recopilación de evidencias.

Para la seguridad de la cadena de suministro TIC, Zenith Controls identifica el control 5.21 de ISO/IEC 27002:2022 como “Gestión de la seguridad de la información en la cadena de suministro TIC”. Explica que 5.21 amplía los controles de relación con proveedores 5.19 y 5.20 hacia riesgos específicos de TIC, incluidos componentes de software inseguros y bibliotecas de terceros o de código abierto. Lo conecta con ingeniería segura, programación segura, pruebas de seguridad, control de acceso, recopilación de evidencias, ciclo de vida de desarrollo seguro y desarrollo externalizado.

Aquí es exactamente donde operan CSAF y VEX. Un aviso de proveedor no es solo un mensaje de un fabricante. Es evidencia de la práctica de ciberseguridad del proveedor. Una declaración VEX de proveedor no es solo una comodidad. Puede respaldar compras, diligencia debida, supervisión y decisiones de riesgo de clientes.

Para la gestión de vulnerabilidades técnicas, Zenith Controls identifica el control 8.8 como “Gestión de vulnerabilidades técnicas”. Clasifica el control como preventivo, de apoyo a la confidencialidad, integridad y disponibilidad, y vinculado a la gestión de amenazas y vulnerabilidades. También señala que la gestión de vulnerabilidades se conecta con la protección contra el software malicioso, la gestión de configuraciones, la gestión de cambios, la inteligencia de amenazas y la supervisión.

Un pasaje especialmente útil de Zenith Controls para la gobernanza VEX es:

“Una Gestión de vulnerabilidades eficaz prioriza en función de amenazas reales. La Inteligencia de amenazas informa qué vulnerabilidades se están explotando activamente y orienta la priorización de parches.”

Esa es la diferencia entre una correlación SBOM sin procesar y un triaje VEX basado en riesgos. La presencia por sí sola no basta. La explotabilidad, la criticidad del activo, la exposición y la actividad de amenazas deben determinar la decisión.

Para las evidencias, Zenith Controls identifica el control 5.28, “Recopilación de evidencias”, como correctivo y vinculado a detectar y responder. Conecta 5.28 con respuesta a incidentes, registro de eventos, supervisión y notificación de eventos. También mapea el manejo de evidencias con ISO/IEC 27037:2012 para identificación, recopilación, adquisición y preservación de evidencias digitales.

Cuando una vulnerabilidad es meramente teórica, los registros VEX rutinarios pueden ser suficientes. Cuando se sospecha explotación, la organización debe pasar al manejo de evidencias de incidentes. Los registros, las comunicaciones con proveedores, los avisos a clientes, los registros de parches y los artefactos forenses necesitan integridad, preservación y trazabilidad.

Un paquete práctico de evidencias VEX desde la alerta hasta el cierre

Volvamos a la plataforma fintech de Anya. Llega un aviso CSAF para una vulnerabilidad crítica en lib-common-utils, que aparece en el SBOM de la pasarela de pagos. Una respuesta disciplinada crearía un único paquete de evidencias, no mensajes de Slack y capturas de pantalla dispersas.

Paso 1: Crear el registro de recepción del aviso

Abra un caso de vulnerabilidad en el gestor de evidencias del SGSI. Adjunte el aviso CSAF, la referencia CVE, el boletín del proveedor, la coincidencia de SBOM y la lista de activos afectados. Asigne un propietario de la vulnerabilidad y un propietario del sistema de negocio. Vincule el servicio de pagos con el impacto en clientes, datos personales, procesamiento financiero y criticidad operativa.

Base de política: la Política de gestión de vulnerabilidades y parches exige supervisar avisos y escalar vulnerabilidades críticas. Base ISO: control 8.8 del Anexo A. Base NIS2: gestión de vulnerabilidades y mantenimiento seguro. Base DORA: identificación de vulnerabilidades TIC y preparación para incidentes.

Paso 2: Establecer el estado preliminar en investigación

El estado inicial debe ser a menudo “en investigación”, especialmente para avisos críticos. Establezca un plazo de decisión, por ejemplo, 24 horas para servicios expuestos externamente o críticos. Registre controles provisionales, como supervisión reforzada, restricciones temporales de funcionalidades o reglas WAF. Esto impide que un aviso crítico desaparezca en un backlog no gestionado.

Paso 3: Realizar el análisis de explotabilidad

Ingeniería debe responder preguntas prácticas:

• ¿Está presente la versión vulnerable en producción?
• ¿La función vulnerable se importa, se invoca o es alcanzable?
• ¿Está habilitada la configuración vulnerable?
• ¿El componente está expuesto a entradas no confiables?
• ¿Se requiere autenticación antes de alcanzar la ruta vulnerable?
• ¿Son eficaces los controles compensatorios?
• ¿Existe explotación activa o inteligencia de amenazas creíble?
• ¿Podría la explotación afectar a datos personales, transacciones financieras o la disponibilidad del servicio?

En el caso de Anya, el análisis estático confirma que el componente está presente, pero la función vulnerable no se invoca desde la pasarela de pagos. No existe ruta de ejecución en producción. El equipo prepara una declaración VEX de “no afectado” con evidencias de soporte.

Si el análisis hubiera demostrado que una tarea administrativa autenticada podía alcanzar la función vulnerable, el estado correcto sería “afectado”, no “no afectado”. Entonces el equipo crearía un plan de tratamiento de riesgos, abriría un ticket de cambio, aplicaría un parche o una mitigación y actualizaría el estado a “corregido” solo después de la verificación.

Paso 4: Vincular el caso al registro de riesgos y al registro de proveedores

Los casos críticos y de alto riesgo deben introducirse en el registro de riesgos del SGSI salvo que se cierren mediante una excepción aprobada y evidenciada. Los avisos de proveedores también deben vincularse al registro de proveedores, a las obligaciones contractuales y a los registros de supervisión.

Esto respalda el paso 23 de Zenith Blueprint, que instruye a las organizaciones a compilar proveedores, clasificarlos por acceso y control operativo, incorporar expectativas de seguridad en los contratos y definir procedimientos de supervisión para cambios de proveedores.

Paso 5: Validar la corrección o aprobar la excepción

Para “corregido”, adjunte la versión del parche, el registro de cambio, el resultado de la canalización de CI/CD, el escaneo de dependencias, el digest de la imagen de contenedor, la evidencia de despliegue y la prueba de regresión. Para “no afectado”, adjunte el análisis de ruta de código, la evidencia de configuración, la evidencia de versión, la evidencia del control compensatorio y la aprobación.

Si los clientes utilizan versiones autoalojadas o la vulnerabilidad podría afectar a usuarios externos, coordine la comunicación. La Política de divulgación coordinada de vulnerabilidades proporciona el modelo:

“Cuando una vulnerabilidad confirmada pueda afectar a clientes o usuarios del servicio, el equipo de Comunicaciones, bajo la dirección del VRT, deberá preparar un aviso de seguridad. El aviso incluirá una visión general del problema, sin divulgar detalles de explotación, los productos o versiones afectados, directrices de mitigación o instrucciones de descarga de parches, e información de contacto de soporte.”

Desde requisitos de implementación, cláusula de política 6.8, esto se mapea directamente con la disciplina de publicación CSAF.

Paso 6: Preservar evidencias si se sospecha explotación

Si los registros muestran intentos de explotación, pase de la gestión de vulnerabilidades a la respuesta a incidentes y la recopilación de evidencias. Inicie un registro de cadena de custodia, preserve los registros, registre las consultas SIEM, exporte los eventos relevantes, tome instantáneas de los sistemas afectados si es necesario y documente quién manejó cada artefacto. Vincule el caso de incidente con el registro VEX.

Qué pedirán auditores y reguladores

No todos los auditores prueban la gobernanza de VEX y CSAF del mismo modo. Un único paquete de evidencias debe satisfacer múltiples perspectivas.

Zenith Controls incluye directrices de metodología de auditoría que encajan con esta tabla. Para la seguridad de la cadena de suministro TIC, los auditores que utilicen ISO/IEC 19011 e ISO/IEC 27007 examinarán políticas de adquisición, plantillas de RFP y procesos de gestión de proveedores para verificar requisitos de seguridad específicos de TIC. Muestrearán contratos para comprobar cláusulas de desarrollo seguro, divulgación de vulnerabilidades y autenticidad del software.

Para la gestión de vulnerabilidades técnicas, los auditores revisan la política de gestión de vulnerabilidades, la frecuencia de escaneos, la cobertura de activos, la priorización basada en el riesgo, los plazos de remediación y las responsabilidades. Para la recopilación de evidencias, prueban si la cadena de custodia, el almacenamiento seguro y la preservación se siguieron en incidentes reales.

Por eso la gobernanza VEX nunca debe terminar en la etiqueta de estado. La etiqueta es el resumen. La pista de evidencias es el control.

Métricas de dirección que preparan VEX para el consejo de administración

ISO/IEC 27001:2022 exige evaluación del desempeño, auditoría interna y revisión por la dirección. NIS2 exige supervisión por la dirección. DORA exige gobernanza del riesgo TIC. VEX y CSAF crean métricas que traducen el trabajo de ingeniería en visibilidad ejecutiva del riesgo.

Las métricas útiles para la revisión por la dirección incluyen:

• Número de avisos CSAF críticos recibidos este trimestre
• Porcentaje correlacionado con componentes SBOM
• Número y antigüedad de estados VEX por afectado, no afectado, corregido y en investigación
• Casos “en investigación” vencidos
• Avisos de proveedores sin datos suficientes de versiones afectadas
• Vulnerabilidades críticas aceptadas como excepciones aprobadas
• Tiempo desde la recepción del aviso hasta la decisión VEX
• Tiempo desde la decisión de afectado hasta la remediación
• Número de casos con impacto potencial en datos personales
• Número de avisos a clientes emitidos

Estas métricas ayudan a la dirección a formular mejores preguntas. ¿Qué proveedores no aportan datos de vulnerabilidades accionables? ¿Qué productos tienen los tiempos de remediación más largos? ¿Qué equipos dejan investigaciones abiertas? ¿Qué vulnerabilidades pueden afectar a datos personales o funciones críticas?

Patrones habituales de fallo que deben eliminarse

El primer fallo es tratar la coincidencia SBOM como análisis de explotabilidad. Una coincidencia de componente es una señal, no una conclusión.

El segundo fallo es usar “no afectado” sin justificación. Los auditores preguntarán por qué. ¿La ruta de código era inalcanzable? ¿La funcionalidad vulnerable estaba deshabilitada? ¿La versión era diferente? ¿El componente solo se usaba en tiempo de compilación? ¿La conclusión fue aprobada por seguridad de producto?

El tercer fallo es dejar “en investigación” abierto. Este estado solo es útil con propietario, plazo y controles provisionales.

El cuarto fallo es separar la gobernanza de proveedores de la gobernanza de vulnerabilidades. Los contratos con proveedores deben exigir divulgación oportuna de vulnerabilidades, tiempos de respuesta, obligaciones de aplicación de parches, contenido de avisos y soporte de evidencias.

El quinto fallo es ignorar los datos personales y la comunicación con clientes. Una vulnerabilidad que podría exponer datos personales necesita una evaluación GDPR. Una vulnerabilidad confirmada de producto que podría afectar a clientes necesita disciplina de divulgación coordinada. Una dependencia de servicios financieros puede requerir análisis de incidentes DORA.

El sexto fallo es una preservación débil de evidencias. Zenith Blueprint advierte en el paso 23, control 5.28, que las evidencias suelen pasarse por alto:

“lo que puedes demostrar importa tanto como lo que ocurrió realmente”

Esa frase resume la realidad de 2026. Los equipos de seguridad no solo corrigen vulnerabilidades. Demuestran que las decisiones fueron oportunas, basadas en riesgos y controladas.

Próximos pasos para evidencias auditables de vulnerabilidades

Si tu organización ya tiene SBOM, el siguiente paso de madurez no es otra hoja de cálculo de inventario. Es la gobernanza sobre el estado de las vulnerabilidades, los avisos de proveedores y las evidencias de divulgación.

Empieza con cuatro acciones:

1. Añade la recepción de CSAF y VEX a tu procedimiento de gestión de vulnerabilidades.
2. Define criterios de aprobación para afectado, no afectado, corregido y en investigación.
3. Vincula los registros VEX con tu registro de riesgos del SGSI, registro de proveedores, inventario de activos, repositorio SBOM y proceso de incidentes.
4. Prueba el proceso con un aviso crítico reciente y produce un paquete de evidencias preparado para auditoría.

Clarysec puede ayudarte a implementarlo rápidamente con Zenith Blueprint, Zenith Controls y el conjunto de políticas correspondiente, incluida la Política de gestión de vulnerabilidades y parches, la Política de gestión de vulnerabilidades y parches - pyme, la Política de requisitos de seguridad de las aplicaciones - pyme, la Política de Desarrollo Seguro, la Política de recopilación de evidencias y análisis forense - pyme y la Política de divulgación coordinada de vulnerabilidades.

La pregunta ganadora en 2026 no es “¿Tenemos un SBOM?”. Es “¿Podemos demostrar, para cada aviso grave, exactamente cómo determinamos el estado de la vulnerabilidad, tratamos el riesgo y comunicamos el resultado?”.

Reserva una evaluación de Clarysec o solicita el toolkit de políticas correspondiente para convertir VEX y CSAF en evidencias de vulnerabilidades preparadas para auditoría antes de que el próximo aviso crítico llegue a tu consejo de administración.