CSAF: el Common Security Advisory Framework para avisos legibles por máquina

¿Qué es CSAF?

El Common Security Advisory Framework (CSAF) es un estándar del Comité Técnico de CSAF de OASIS para redactar avisos de seguridad como JSON estructurado y distribuirlos de forma que puedan encontrarse y procesarse automáticamente. Un documento CSAF indica a qué productos y versiones afecta una vulnerabilidad, cuáles no están afectados, cuáles están corregidos y qué deben hacer los usuarios.

La versión actual es CSAF 2.0, aprobada como estándar OASIS el 18 de noviembre de 2022. CSAF 2.1 está en camino: su tercer Committee Specification Draft pasó por revisión pública en septiembre de 2026 y, a octubre de 2026, todavía no es un estándar aprobado.

Los avisos los redactan los proveedores, normalmente su equipo de respuesta a incidentes de seguridad de producto (PSIRT), y coordinadores como los CERT nacionales. Para saber en qué se diferencian estos dos tipos de equipo, consulte PSIRT vs CSIRT.

De CVRF a CSAF

CSAF surgió del Common Vulnerability Reporting Framework (CVRF), un formato XML. ICASI publicó CVRF 1.1 en mayo de 2012 y OASIS publicó CVRF 1.2 en septiembre de 2017. CSAF 2.0 lo sustituyó por un formato JSON, un esquema JSON para la validación, perfiles para distintos tipos de documentos y reglas sobre cómo se distribuyen y se encuentran los avisos. La especificación sigue definiendo cómo convertir documentos CVRF a CSAF.

Estructura de un documento CSAF

Un documento CSAF tiene tres partes de nivel superior:

• document: los metadatos. Cinco propiedades son obligatorias: la categoría (qué perfil sigue el documento), la versión de CSAF, el emisor del aviso, el título y los datos de seguimiento. El seguimiento contiene el ID del aviso, su estado, su versión, las fechas de publicación inicial y actual y un historial de revisiones.
• product_tree: todos los productos que menciona el documento, normalmente como ramas que van del proveedor al nombre del producto y a la versión, con ID de producto a los que hace referencia el resto del documento. Los productos también pueden identificarse mediante package URL (purl), CPE o hashes.
• vulnerabilities: una entrada por vulnerabilidad, con su CVE u otros ID, notas, puntuaciones y un estado de producto que clasifica los ID de producto en listas: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended y under_investigation. Las remediaciones se clasifican como vendor_fix, workaround, mitigation, no_fix_planned o none_available.

Los cinco perfiles de CSAF

En CSAF en su conjunto son pocos los campos obligatorios. Los perfiles indican cuáles debe tener un tipo concreto de documento, y el valor de /document/category indica qué perfil sigue un documento:

Perfil	Valor de categoría	Para qué se usa
CSAF Base	csaf_base	El mínimo que cumple todo documento CSAF; el cajón de sastre para documentos que no encajan en ningún otro perfil
Respuesta a incidentes de seguridad	csaf_security_incident_response	Responder a una brecha o un incidente de seguridad, incluso en otra organización
Aviso informativo	csaf_informational_advisory	Problemas que no son vulnerabilidades, como una configuración peligrosa
Aviso de seguridad	csaf_security_advisory	Vulnerabilidades y sus remediaciones; el aviso clásico de un proveedor
VEX	csaf_vex	Indicar si cada producto está afectado o no por una vulnerabilidad, y por qué

Un aviso de seguridad debe tener un árbol de productos, las vulnerabilidades, notas para cada vulnerabilidad y un estado de producto. El perfil VEX va más allá: cada producto marcado como known_not_affected necesita una declaración de impacto, ya sea como indicador legible por máquina o como texto, y cada producto known_affected necesita una remediación que indique a los usuarios qué hacer.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) indica a los usuarios qué vulnerabilidades de los componentes de un producto afectan realmente al producto. CSAF VEX es uno de los tres formatos VEX habituales, junto con OpenVEX y CycloneDX VEX. Sus indicadores utilizan las mismas cinco justificaciones de no afectación que los requisitos de VEX de CISA, como component_not_present y vulnerable_code_not_in_execute_path. Tanto Trivy como Grype leen CSAF VEX y descartan los hallazgos que marca como no afectados. Red Hat, por ejemplo, publica sus documentos CSAF VEX en un directorio separado junto a sus avisos CSAF.

Cómo se distribuyen los avisos CSAF

Un formato estándar solo ayuda si las herramientas pueden encontrar los documentos. La sección 7 de CSAF 2.0 establece cómo:

• provider-metadata.json describe al emisor y dónde están sus avisos. Las herramientas lo encuentran por al menos una de tres vías: un campo CSAF en el security.txt del dominio, la URL well-known /.well-known/csaf/provider-metadata.json o el nombre DNS csaf.data.security. delante del dominio.
• Los avisos se enumeran en carpetas por año con un index.txt y un changes.csv, o en feeds ROLIE, servidos por TLS sin redirecciones.
• Cada archivo se nombra según su ID de seguimiento. Los avisos TLP:WHITE deben ser de libre acceso, y los TLP:AMBER o TLP:RED deben estar tras un control de acceso.
• Integridad: los trusted providers añaden un hash y una firma OpenPGP a cada documento y publican su clave pública.

El estándar define cinco roles que puede asumir quien distribuye avisos:

Rol	Qué hace
CSAF publisher	Publica documentos CSAF válidos, solo en nombre propio, por TLS
CSAF provider	Un publisher que además ofrece provider-metadata.json, una vía de descubrimiento y un directorio o feed ROLIE
CSAF trusted provider	Un provider que además publica hashes, firmas OpenPGP y su clave pública
CSAF lister	Mantiene una lista de dónde encontrar los documentos CSAF de terceros, sin copiarlos
CSAF aggregator	Replica en un solo lugar los documentos de al menos dos emisores independientes, con hashes y firmas

Los consumidores configuran un descargador una vez y después obtienen los nuevos avisos de cada provider del que dependen sus productos, en lugar de vigilar decenas de páginas web de proveedores.

Quién publica CSAF

CSAF es más habitual entre proveedores industriales, empresariales y de infraestructura, y entre los CERT nacionales:

• Cisco ofrece un provider-metadata.json en su URL well-known de CSAF.
• Siemens ProductCERT publica sus avisos como un feed ROLIE de CSAF.
• Red Hat publica avisos CSAF y, por separado, documentos CSAF VEX.
• CERT-Bund del BSI, el CERT nacional de Alemania, publica feeds CSAF de sus avisos.
• CISA anunció en septiembre de 2023 que sus avisos ICS incluyen documentos CSAF, con carácter retroactivo hasta 2017, e instó a los proveedores a adoptar el estándar.

Los proveedores industriales que trabajan conforme a IEC 62443-4-1 necesitan un proceso para informar a los usuarios de los problemas de seguridad de sus productos, y los avisos legibles por máquina son una forma habitual de cumplir las expectativas de sus clientes.

Herramientas de CSAF

• Secvisogram es el editor web de documentos CSAF del BSI, con un editor de formularios, un editor JSON, una vista previa HTML y validación.
• Las herramientas csaf del BSI e Intevation (gocsaf/csaf, a menudo llamadas csaf_distribution) implementan un trusted provider, un verificador, un aggregator y un descargador, con una versión para CSAF 2.1 en desarrollo.
• Escáneres como Trivy y Grype consumen documentos CSAF VEX.

Cómo redactar un buen aviso de seguridad

Con CSAF o sin él, un aviso útil responde a las mismas preguntas. Esta es la plantilla a la que llegan la mayoría de los PSIRT, con el campo de CSAF que contiene cada respuesta:

Elemento del aviso	Qué escribir	En CSAF
ID y título	Un ID de aviso estable y un título que nombre el producto y el tipo de problema	tracking/id, title
Fechas y revisiones	Primera publicación, última actualización y qué cambió en cada revisión	Fechas de tracking y revision_history
Productos afectados	Productos y rangos de versiones exactos, no «versiones anteriores»	product_tree, known_affected
No afectados y corregidos	Qué productos y versiones no están afectados, y qué versiones contienen la corrección	known_not_affected, fixed, first_fixed
Vulnerabilidad	ID de CVE, una descripción clara, el impacto y cómo se explota, sin dar una receta a los atacantes	cve, ids, notes
Gravedad	Una puntuación CVSS con su vector, para que los lectores puedan comprobarla	scores
Remediación	La versión corregida, o una solución alternativa o mitigación, o una indicación clara de que no se prevé ninguna corrección	remediations
Créditos y referencias	Quién lo notificó, enlaces a avisos y correcciones relacionados	acknowledgments, references
Contacto	Dónde notificar problemas y hacer preguntas	publisher/contact_details

Algunos hábitos marcan la diferencia entre un aviso que se atiende y uno que se ignora:

• Sea exacto con las versiones. El rango afectado es lo que hace actuar a los clientes. Indique la primera versión afectada y la primera corregida de cada línea de producto.
• Diga qué no está afectado. Los clientes que utilizan productos que usted ha descartado dejan de preguntar, y sus escáneres dejan de señalarlos si además publica VEX.
• Actualice, no sustituya. Mantenga un aviso por problema y añada revisiones a medida que se distribuyan las correcciones.
• Publique en la fecha acordada. Los avisos son el punto final de la divulgación coordinada de vulnerabilidades, y se publican cuando la corrección está disponible y se ha informado a quien la notificó.

Los pasos anteriores al aviso, desde la recepción y el triaje hasta la corrección, se tratan en el ciclo de vida de la gestión de vulnerabilidades, y las personas que hacen este trabajo, en el rol de PSIRT.

Lo difícil es saber qué está afectado

Todo aviso, en CSAF o en cualquier otro formato, depende de una respuesta: qué productos y versiones contienen el componente vulnerable. Para el software construido a partir de paquetes de código abierto, eso significa saber exactamente qué versiones de dependencias entraron en cada versión, incluidas las transitivas.

CRACI ejecuta builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés y las dependencias que ningún lockfile recoge. Cuando se publica una nueva vulnerabilidad, las SBOM monitorizadas se reevalúan, y el historial de builds muestra qué builds y versiones anteriores contenían la dependencia vulnerable, de forma directa o transitiva, para que sepa durante qué periodo estuvo afectado. La vista de inventario muestra qué versiones están desplegadas en qué productos, y el triaje dirige cada hallazgo al equipo responsable de la corrección. Las SBOM se exportan en CycloneDX o SPDX, y CRACI es compatible con VEX. Consulte el seguimiento de vulnerabilidades.

CSAF: preguntas frecuentes

¿Qué significa CSAF?

En seguridad, CSAF son las siglas de Common Security Advisory Framework, un estándar de OASIS para redactar avisos de seguridad como documentos JSON legibles por máquina y distribuirlos de forma que las herramientas puedan encontrarlos y procesarlos automáticamente.

¿Cuál es la versión actual de CSAF?

CSAF 2.0, aprobada como estándar OASIS el 18 de noviembre de 2022. CSAF 2.1 está en curso: su tercer Committee Specification Draft terminó la revisión pública el 29 de septiembre de 2026 y, a octubre de 2026, todavía no es un estándar OASIS aprobado.

¿Cuál es la diferencia entre CSAF y CVE?

Un registro CVE identifica una vulnerabilidad y la describe en términos generales. Un aviso CSAF lo publica un proveedor o un coordinador e indica cómo esa vulnerabilidad, y a menudo varias más, afecta a productos y versiones concretos, y qué hacer al respecto. Los avisos CSAF hacen referencia a los ID de CVE.

¿Qué es CSAF VEX?

CSAF VEX es el perfil csaf_vex de CSAF. Contiene declaraciones VEX: para cada producto, si está afectado, no afectado, corregido o en investigación, con una declaración de impacto para los productos no afectados y una remediación para los afectados. Trivy y Grype pueden leerlo para suprimir hallazgos.

¿Qué es un CSAF provider?

Un CSAF provider es una organización que publica sus propios documentos CSAF de forma que las herramientas puedan descubrirlos: un archivo provider-metadata.json, localizable mediante security.txt, una URL well-known o un nombre DNS, y un directorio o feed ROLIE de avisos. Un trusted provider añade hashes, firmas OpenPGP y una clave pública publicada.

¿A qué sustituyó CSAF?

El Common Vulnerability Reporting Framework (CVRF), un formato XML. ICASI publicó CVRF 1.1 en 2012 y OASIS publicó CVRF 1.2 en 2017. CSAF 2.0 pasó a JSON y añadió perfiles, árboles de productos y reglas de distribución.

¿Cómo se redacta un aviso CSAF?

La mayoría de los equipos empiezan con un editor como Secvisogram, el editor web de CSAF del BSI, o generan el JSON a partir de su propio seguimiento de vulnerabilidades. Elija un perfil, normalmente csaf_security_advisory, complete el emisor del aviso, los datos de seguimiento, el árbol de productos y las vulnerabilidades, valídelo con el esquema y publíquelo a través de un provider.