CSAF : le Common Security Advisory Framework pour des avis lisibles par machine

Qu'est-ce que CSAF ?

Le Common Security Advisory Framework (CSAF) est une norme de l'OASIS CSAF Technical Committee qui permet de rédiger des avis de sécurité en JSON structuré et de les diffuser pour qu'ils puissent être trouvés et traités automatiquement. Un document CSAF indique quels produits et versions une vulnérabilité touche, lesquels ne sont pas touchés, lesquels sont corrigés et ce que les utilisateurs doivent faire.

La version actuelle est CSAF 2.0, approuvée comme OASIS Standard le 18 novembre 2022. CSAF 2.1 est en préparation : son troisième Committee Specification Draft a fait l'objet d'une revue publique en septembre 2026 et, en octobre 2026, ce n'est pas encore une norme approuvée.

Les avis sont rédigés par les éditeurs, généralement par leur équipe de réponse aux incidents de sécurité produit (PSIRT), et par des coordinateurs tels que les CERT nationaux. Pour la différence entre ces deux types d'équipes, consultez PSIRT vs CSIRT.

De CVRF à CSAF

CSAF est issu du Common Vulnerability Reporting Framework (CVRF), un format XML. L'ICASI a publié CVRF 1.1 en mai 2012, et OASIS a publié CVRF 1.2 en septembre 2017. CSAF 2.0 l'a remplacé par un format JSON, un schéma JSON de validation, des profils pour différents types de documents et des règles sur la façon dont les avis sont diffusés et trouvés. La spécification définit toujours la conversion des documents CVRF vers CSAF.

Structure d'un document CSAF

Un document CSAF comporte trois parties de premier niveau :

• document : les métadonnées. Cinq propriétés sont obligatoires : la catégorie (le profil suivi par le document), la version de CSAF, l'éditeur de l'avis, le titre et les données de suivi. Le suivi contient l'identifiant de l'avis, son statut, sa version, les dates de publication initiale et actuelle et un historique des révisions.
• product_tree : tous les produits mentionnés dans le document, généralement sous forme de branches allant de l'éditeur au nom du produit puis à la version, avec des identifiants de produit auxquels renvoie le reste du document. Les produits peuvent aussi être identifiés par package URL (purl), CPE ou hachages.
• vulnerabilities : une entrée par vulnérabilité, avec son identifiant CVE ou d'autres identifiants, des notes, des scores et un statut de produit qui répartit les identifiants de produit en listes : known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended et under_investigation. Les remédiations sont classées en vendor_fix, workaround, mitigation, no_fix_planned ou none_available.

Les cinq profils CSAF

Peu de champs sont obligatoires dans CSAF pris dans son ensemble. Les profils indiquent ceux qu'un type de document donné doit comporter, et la valeur de /document/category indique le profil suivi par un document :

Profil	Valeur de catégorie	Usage
CSAF Base	csaf_base	Le minimum que respecte tout document CSAF ; la catégorie fourre-tout pour les documents qui n'entrent dans aucun autre profil
Security incident response	csaf_security_incident_response	Répondre à une violation ou à un incident de sécurité, y compris dans une autre organisation
Informational advisory	csaf_informational_advisory	Les problèmes qui ne sont pas des vulnérabilités, comme une erreur de configuration dangereuse
Security advisory	csaf_security_advisory	Les vulnérabilités et leurs remédiations ; l'avis d'éditeur classique
VEX	csaf_vex	Indiquer si chaque produit est touché ou non par une vulnérabilité, et pourquoi

Un avis de sécurité doit comporter une arborescence de produits, les vulnérabilités, des notes pour chaque vulnérabilité et un statut de produit. Le profil VEX va plus loin : chaque produit listé comme known_not_affected exige une déclaration d'impact, sous forme d'indicateur lisible par machine ou de texte, et chaque produit known_affected exige une remédiation qui indique aux utilisateurs ce qu'ils doivent faire.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) indique aux utilisateurs quelles vulnérabilités des composants d'un produit touchent réellement ce produit. CSAF VEX est l'un des trois formats VEX courants, avec OpenVEX et CycloneDX VEX. Ses indicateurs reprennent les cinq mêmes justifications de non-impact que les exigences VEX de la CISA, comme component_not_present et vulnerable_code_not_in_execute_path. Trivy et Grype lisent tous deux CSAF VEX et écartent les résultats qu'il marque comme non touchés. Red Hat, par exemple, publie ses documents CSAF VEX dans un répertoire distinct, à côté de ses avis CSAF.

Comment les avis CSAF sont diffusés

Un format standard n'est utile que si les outils peuvent trouver les documents. La section 7 de CSAF 2.0 précise comment :

• provider-metadata.json décrit l'éditeur de l'avis et l'emplacement de ses avis. Les outils le trouvent par au moins l'une de ces trois voies : un champ CSAF dans le security.txt du domaine, l'URL well-known /.well-known/csaf/provider-metadata.json, ou le nom DNS csaf.data.security. placé devant le domaine.
• Les avis sont listés soit dans des dossiers annuels avec un index.txt et un changes.csv, soit dans des flux ROLIE, servis via TLS sans redirection.
• Chaque fichier porte le nom de son identifiant de suivi. Les avis TLP:WHITE doivent être librement accessibles, et les avis TLP:AMBER ou TLP:RED doivent être protégés par un contrôle d'accès.
• Intégrité : les fournisseurs de confiance ajoutent un hachage et une signature OpenPGP à chaque document et publient leur clé publique.

La norme définit cinq rôles qu'une partie qui diffuse des avis peut revendiquer :

Rôle	Ce qu'il fait
CSAF publisher	Publie des documents CSAF valides, uniquement en son propre nom, via TLS
CSAF provider	Un publisher qui propose aussi un provider-metadata.json, une voie de découverte et un répertoire ou un flux ROLIE
CSAF trusted provider	Un provider qui publie aussi des hachages, des signatures OpenPGP et sa clé publique
CSAF lister	Tient une liste des emplacements des documents CSAF d'autres parties, sans les copier
CSAF aggregator	Réplique en un seul endroit les documents d'au moins deux émetteurs indépendants, avec hachages et signatures

Les consommateurs d'avis configurent une seule fois un outil de téléchargement, puis récupèrent les nouveaux avis de chaque fournisseur dont dépendent leurs produits, au lieu de surveiller des dizaines de pages web d'éditeurs.

Qui publie du CSAF

CSAF est surtout répandu chez les éditeurs industriels, d'entreprise et d'infrastructure, ainsi que chez les CERT nationaux :

• Cisco sert un provider-metadata.json à son URL CSAF well-known.
• Siemens ProductCERT publie ses avis sous forme de flux CSAF ROLIE.
• Red Hat publie des avis CSAF et, séparément, des documents CSAF VEX.
• Le CERT-Bund du BSI, le CERT national allemand, publie des flux CSAF de ses avis.
• La CISA a annoncé en septembre 2023 que ses avis ICS sont accompagnés de documents CSAF, en remontant jusqu'à 2017, et a exhorté les éditeurs à adopter la norme.

Les fournisseurs industriels qui appliquent IEC 62443-4-1 ont besoin d'un processus pour informer les utilisateurs des problèmes de sécurité de leurs produits, et les avis lisibles par machine sont un moyen courant de répondre aux attentes de leurs clients.

Outils CSAF

• Secvisogram est l'éditeur web du BSI pour les documents CSAF, avec un éditeur de formulaires, un éditeur JSON, un aperçu HTML et une validation.
• Les outils csaf du BSI et d'Intevation (gocsaf/csaf, souvent appelés csaf_distribution) implémentent un trusted provider, un vérificateur, un agrégateur et un outil de téléchargement, avec une version CSAF 2.1 en développement.
• Des scanners tels que Trivy et Grype consomment des documents CSAF VEX.

Rédiger un bon avis de sécurité

Avec ou sans CSAF, un avis utile répond aux mêmes questions. Voici le modèle vers lequel convergent la plupart des PSIRT, avec le champ CSAF qui contient chaque réponse :

Élément de l'avis	Ce qu'il faut écrire	Dans CSAF
Identifiant et titre	Un identifiant d'avis stable et un titre qui nomme le produit et le type de problème	tracking/id, title
Dates et révisions	Première publication, dernière mise à jour et modifications de chaque révision	dates de tracking et revision_history
Produits touchés	Produits et plages de versions exacts, pas « anciennes versions »	product_tree, known_affected
Non touchés et corrigés	Quels produits et versions ne sont pas touchés, et quelles versions contiennent la correction	known_not_affected, fixed, first_fixed
Vulnérabilité	Identifiants CVE, description claire, impact et mode d'exploitation, sans mode d'emploi pour les attaquants	cve, ids, notes
Gravité	Un score CVSS avec son vecteur, pour que les lecteurs puissent le vérifier	scores
Remédiation	La version corrigée, ou un contournement ou une atténuation, ou une mention claire qu'aucune correction n'est prévue	remediations
Crédits et références	Qui l'a signalé, liens vers les avis et correctifs associés	acknowledgments, references
Contact	Où signaler des problèmes et poser des questions	publisher/contact_details

Quelques habitudes font la différence entre un avis suivi d'effet et un avis ignoré :

• Soyez précis sur les versions. C'est sur la plage de versions touchées que les clients agissent. Indiquez la première version touchée et la première version corrigée de chaque gamme de produits.
• Dites ce qui n'est pas touché. Les clients qui utilisent des produits que vous avez écartés cessent de poser des questions, et leurs scanners cessent de les signaler si vous publiez aussi du VEX.
• Mettez à jour, ne remplacez pas. Conservez un seul avis par problème et ajoutez des révisions à mesure que les corrections sont livrées.
• Publiez à la date convenue. Les avis sont le point d'aboutissement de la divulgation coordonnée des vulnérabilités, publiés lorsque la correction est disponible et que l'auteur du signalement a été prévenu.

Les étapes qui précèdent l'avis, de la réception et du tri à la correction, sont traitées dans le cycle de vie de la gestion des vulnérabilités, et les personnes qui font ce travail dans le rôle PSIRT.

Le plus difficile : savoir ce qui est touché

Tout avis, en CSAF ou dans un autre format, dépend d'une seule réponse : quels produits et versions contiennent le composant vulnérable. Pour un logiciel construit à partir de paquets open source, il faut savoir exactement quelles versions de dépendances sont entrées dans chaque release, transitives comprises.

CRACI exécute les builds GitHub Actions sur ses propres runners et enregistre les paquets réellement récupérés par chaque job, y compris les dépendances transitives, les paquets restaurés depuis les caches et les dépendances qu'aucun lockfile ne liste. Lorsqu'une nouvelle vulnérabilité est publiée, les SBOM surveillées sont réévaluées, et l'historique des builds indique quels builds et releases passés contenaient la dépendance vulnérable, directement ou transitivement : vous connaissez ainsi la période pendant laquelle vous étiez touché. La vue d'inventaire montre quelles versions sont déployées sur quels produits, et le tri transmet chaque résultat à l'équipe responsable de la correction. Les SBOM s'exportent en CycloneDX ou SPDX, et CRACI prend en charge VEX. Consultez le suivi des vulnérabilités.

CSAF : questions fréquentes

Que signifie CSAF ?

En sécurité, CSAF désigne le Common Security Advisory Framework, une norme OASIS qui permet de rédiger des avis de sécurité sous forme de documents JSON lisibles par machine et de les diffuser pour que des outils puissent les trouver et les traiter automatiquement.

Quelle est la version actuelle de CSAF ?

CSAF 2.0, approuvée comme OASIS Standard le 18 novembre 2022. CSAF 2.1 est en cours d'élaboration : la revue publique de son troisième Committee Specification Draft s'est achevée le 29 septembre 2026 et, en octobre 2026, ce n'est pas encore un OASIS Standard approuvé.

Quelle est la différence entre CSAF et CVE ?

Un enregistrement CVE identifie une vulnérabilité et la décrit en termes généraux. Un avis CSAF est publié par un éditeur ou un coordinateur et indique comment cette vulnérabilité, et souvent plusieurs autres, touche des produits et versions précis, et ce qu'il faut faire. Les avis CSAF renvoient aux identifiants CVE.

Qu'est-ce que CSAF VEX ?

CSAF VEX est le profil csaf_vex de CSAF. Il contient des déclarations VEX : pour chaque produit, s'il est touché, non touché, corrigé ou en cours d'analyse, avec une déclaration d'impact pour les produits non touchés et une remédiation pour les produits touchés. Trivy et Grype peuvent le lire pour supprimer des résultats.

Qu'est-ce qu'un fournisseur CSAF ?

Un fournisseur CSAF (CSAF provider) est une organisation qui publie ses propres documents CSAF de façon à ce que les outils puissent les découvrir : un fichier provider-metadata.json, repérable via security.txt, une URL well-known ou un nom DNS, et un répertoire ou un flux ROLIE d'avis. Un fournisseur de confiance y ajoute des hachages, des signatures OpenPGP et une clé publique publiée.

Qu'est-ce que CSAF a remplacé ?

Le Common Vulnerability Reporting Framework (CVRF), un format XML. CVRF 1.1 a été publié par l'ICASI en 2012, et CVRF 1.2 par OASIS en 2017. CSAF 2.0 est passé au JSON et a ajouté des profils, des arborescences de produits et des règles de distribution.

Comment rédiger un avis CSAF ?

La plupart des équipes commencent dans un éditeur comme Secvisogram, l'éditeur web du BSI pour CSAF, ou génèrent le JSON à partir de leur propre suivi des vulnérabilités. Choisissez un profil, généralement csaf_security_advisory, renseignez l'éditeur de l'avis, les données de suivi, l'arborescence des produits et les vulnérabilités, validez le document par rapport au schéma, puis publiez-le via un fournisseur.