CSAF: il Common Security Advisory Framework per advisory leggibili da una macchina

Che cos'è CSAF?

Il Common Security Advisory Framework (CSAF) è uno standard dell'OASIS CSAF Technical Committee per scrivere gli advisory di sicurezza in JSON strutturato e distribuirli in modo che possano essere trovati ed elaborati automaticamente. Un documento CSAF indica quali prodotti e versioni sono interessati da una vulnerabilità, quali non sono interessati, quali sono corretti e che cosa devono fare gli utenti.

La versione attuale è CSAF 2.0, approvata come OASIS Standard il 18 novembre 2022. CSAF 2.1 è in arrivo: la sua terza Committee Specification Draft è stata sottoposta a revisione pubblica a settembre 2026 e, a ottobre 2026, non è ancora uno standard approvato.

Gli advisory vengono scritti dai vendor, di solito dal loro product security incident response team (PSIRT), e da coordinatori come i CERT nazionali. Per capire in che cosa differiscono questi due tipi di team, veda PSIRT vs CSIRT.

Da CVRF a CSAF

CSAF deriva dal Common Vulnerability Reporting Framework (CVRF), un formato XML. ICASI ha pubblicato CVRF 1.1 a maggio 2012 e OASIS ha pubblicato CVRF 1.2 a settembre 2017. CSAF 2.0 lo ha sostituito con un formato JSON, uno schema JSON per la convalida, profili per diversi tipi di documento e regole su come distribuire e trovare gli advisory. La specifica definisce ancora come convertire i documenti CVRF in CSAF.

Struttura di un documento CSAF

Un documento CSAF ha tre parti di primo livello:

• document: i metadati. Cinque proprietà sono obbligatorie: la categoria (il profilo seguito dal documento), la versione CSAF, il publisher, il titolo e i dati di tracking. Il tracking contiene l'ID dell'advisory, il suo stato, la sua versione, le date di rilascio iniziale e corrente e una cronologia delle revisioni.
• product_tree: ogni prodotto citato nel documento, di solito sotto forma di rami dal vendor al nome del prodotto alla versione, con ID di prodotto a cui fa riferimento il resto del documento. I prodotti possono essere identificati anche tramite package URL (purl), CPE o hash.
• vulnerabilities: una voce per vulnerabilità, con il suo CVE o altri ID, note, punteggi e uno stato di prodotto che ordina gli ID di prodotto in elenchi: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended e under_investigation. Le remediation sono classificate come vendor_fix, workaround, mitigation, no_fix_planned o none_available.

I cinque profili CSAF

Pochi campi sono obbligatori in CSAF nel suo complesso. I profili stabiliscono quali deve avere un determinato tipo di documento, e il valore di /document/category indica quale profilo segue un documento:

Profilo	Valore della categoria	A che cosa serve
CSAF Base	csaf_base	Il minimo che ogni documento CSAF rispetta; il profilo generico per i documenti che non rientrano in nessun altro
Security incident response	csaf_security_incident_response	Rispondere a una violazione o a un incidente di sicurezza, anche presso un'altra organizzazione
Informational advisory	csaf_informational_advisory	Problemi che non sono vulnerabilità, come una configurazione errata pericolosa
Security advisory	csaf_security_advisory	Vulnerabilità e relative remediation; il classico advisory del vendor
VEX	csaf_vex	Dichiarare se, e perché, ciascun prodotto è o non è interessato da una vulnerabilità

Un security advisory deve avere un product tree, le vulnerabilità, note per ogni vulnerabilità e uno stato di prodotto. Il profilo VEX va oltre: ogni prodotto elencato come known_not_affected richiede una dichiarazione di impatto, come flag leggibile da una macchina o come testo, e ogni prodotto known_affected richiede una remediation che dica agli utenti che cosa fare.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) indica agli utenti quali vulnerabilità nei componenti di un prodotto interessano davvero il prodotto. CSAF VEX è uno dei tre formati VEX più diffusi, accanto a OpenVEX e CycloneDX VEX. I suoi flag usano le stesse cinque giustificazioni per i prodotti non interessati dei requisiti VEX di CISA, come component_not_present e vulnerable_code_not_in_execute_path. Trivy e Grype leggono entrambi CSAF VEX ed eliminano i rilevamenti che segna come non interessati. Red Hat, ad esempio, pubblica i propri documenti CSAF VEX in una directory separata accanto ai suoi advisory CSAF.

Come vengono distribuiti gli advisory CSAF

Un formato standard serve solo se gli strumenti riescono a trovare i documenti. La sezione 7 di CSAF 2.0 stabilisce come:

• provider-metadata.json descrive il publisher e dove si trovano i suoi advisory. Gli strumenti lo trovano attraverso almeno una di tre vie: un campo CSAF nel security.txt del dominio, l'URL well-known /.well-known/csaf/provider-metadata.json oppure il nome DNS csaf.data.security. davanti al dominio.
• Gli advisory sono elencati in cartelle per anno con un index.txt e un changes.csv, oppure in feed ROLIE, serviti tramite TLS senza redirect.
• Ogni file prende il nome dal proprio ID di tracking. Gli advisory TLP:WHITE devono essere liberamente accessibili, mentre quelli TLP:AMBER o TLP:RED devono trovarsi dietro un controllo degli accessi.
• Integrità: i trusted provider aggiungono un hash e una firma OpenPGP per ogni documento e pubblicano la propria chiave pubblica.

Lo standard definisce cinque ruoli che chi distribuisce può assumere:

Ruolo	Che cosa fa
CSAF publisher	Pubblica documenti CSAF validi, solo per conto proprio, tramite TLS
CSAF provider	Un publisher che offre anche provider-metadata.json, una via di individuazione e una directory o un feed ROLIE
CSAF trusted provider	Un provider che pubblica anche hash, firme OpenPGP e la propria chiave pubblica
CSAF lister	Mantiene un elenco di dove trovare i documenti CSAF di altri soggetti, senza copiarli
CSAF aggregator	Replica in un unico luogo i documenti di almeno due emittenti indipendenti, con hash e firme

Gli utilizzatori configurano una volta un downloader e poi scaricano i nuovi advisory da ogni provider da cui dipendono i loro prodotti, invece di tenere d'occhio decine di pagine web dei vendor.

Chi pubblica CSAF

CSAF è più diffuso tra i vendor industriali, enterprise e di infrastruttura e tra i CERT nazionali:

• Cisco espone un provider-metadata.json al proprio URL CSAF well-known.
• Siemens ProductCERT pubblica i propri advisory come feed CSAF ROLIE.
• Red Hat pubblica advisory CSAF e, separatamente, documenti CSAF VEX.
• CERT-Bund del BSI, il CERT nazionale tedesco, pubblica feed CSAF dei propri advisory.
• CISA ha annunciato a settembre 2023 che i suoi advisory ICS sono accompagnati da documenti CSAF, a partire dal 2017, e ha esortato i vendor ad adottare lo standard.

I fornitori industriali che lavorano secondo IEC 62443-4-1 hanno bisogno di un processo per informare gli utenti dei problemi di sicurezza nei loro prodotti, e gli advisory leggibili da una macchina sono un modo comune per soddisfare le aspettative dei clienti.

Strumenti per CSAF

• Secvisogram è l'editor web del BSI per i documenti CSAF, con un editor a moduli, un editor JSON, un'anteprima HTML e la convalida.
• Gli strumenti csaf di BSI e Intevation (gocsaf/csaf, spesso chiamati csaf_distribution) implementano un trusted provider, un checker, un aggregator e un downloader, con una versione CSAF 2.1 in sviluppo.
• Gli scanner come Trivy e Grype utilizzano i documenti CSAF VEX.

Scrivere un buon advisory di sicurezza

Con o senza CSAF, un advisory utile risponde alle stesse domande. Questo è il modello su cui converge la maggior parte dei PSIRT, con il campo CSAF che contiene ogni risposta:

Elemento dell'advisory	Che cosa scrivere	In CSAF
ID e titolo	Un ID stabile dell'advisory e un titolo che indichi il prodotto e il tipo di problema	tracking/id, title
Date e revisioni	Prima pubblicazione, ultimo aggiornamento e che cosa è cambiato in ogni revisione	date di tracking e revision_history
Prodotti interessati	Prodotti e intervalli di versioni esatti, non "versioni precedenti"	product_tree, known_affected
Non interessati e corretti	Quali prodotti e versioni non sono interessati e quali versioni contengono la correzione	known_not_affected, fixed, first_fixed
Vulnerabilità	ID CVE, una descrizione chiara, l'impatto e come viene sfruttata, senza una ricetta per gli attaccanti	cve, ids, notes
Gravità	Un punteggio CVSS con il suo vettore, così i lettori possono verificarlo	scores
Remediation	La versione corretta, oppure un workaround o una mitigazione, oppure una chiara dichiarazione che non è prevista alcuna correzione	remediations
Riconoscimenti e riferimenti	Chi l'ha segnalata, link agli advisory e alle correzioni correlati	acknowledgments, references
Contatto	Dove segnalare problemi e porre domande	publisher/contact_details

Alcune abitudini fanno la differenza tra un advisory su cui le persone agiscono e uno che ignorano:

• Sia preciso sulle versioni. L'intervallo interessato è ciò su cui agiscono i clienti. Indichi la prima versione interessata e la prima corretta per ogni linea di prodotto.
• Dica che cosa non è interessato. I clienti che usano prodotti che Lei ha escluso smettono di fare domande, e i loro scanner smettono di segnalarli se pubblica anche VEX.
• Aggiorni, non sostituisca. Tenga un solo advisory per problema e aggiunga revisioni man mano che vengono rilasciate le correzioni.
• Pubblichi alla data concordata. Gli advisory sono il punto di arrivo della divulgazione coordinata delle vulnerabilità, pubblicati quando la correzione è disponibile e il segnalatore è stato informato.

I passaggi che precedono l'advisory, dalla ricezione al triage fino alla correzione, sono trattati nel ciclo di vita della gestione delle vulnerabilità, e le persone che svolgono questo lavoro nel ruolo PSIRT.

La parte difficile è sapere che cosa è interessato

Ogni advisory, in CSAF o in qualsiasi altro formato, dipende da una risposta: quali prodotti e versioni contengono il componente vulnerabile. Per il software costruito con pacchetti open source, significa sapere esattamente quali versioni delle dipendenze sono entrate in ogni release, comprese quelle transitive.

CRACI esegue le build GitHub Actions sui propri runner e registra i pacchetti che ogni job ha effettivamente scaricato, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache e le dipendenze che nessun lockfile elenca. Quando viene pubblicata una nuova vulnerabilità, le SBOM monitorate vengono rivalutate e la cronologia delle build mostra quali build e release passate contenevano la dipendenza vulnerabile, direttamente o transitivamente, così Lei conosce il periodo di esposizione. La vista dell'inventario mostra quali versioni sono distribuite su quali prodotti e il triage inoltra ogni rilevamento al team responsabile della correzione. Le SBOM si esportano in CycloneDX o SPDX e CRACI supporta VEX. Veda il tracciamento delle vulnerabilità.

CSAF: domande frequenti

Che cosa significa CSAF?

In ambito sicurezza, CSAF sta per Common Security Advisory Framework, uno standard OASIS per scrivere gli advisory di sicurezza come documenti JSON leggibili da una macchina e distribuirli in modo che gli strumenti possano trovarli ed elaborarli automaticamente.

Qual è la versione attuale di CSAF?

CSAF 2.0, approvata come OASIS Standard il 18 novembre 2022. CSAF 2.1 è in lavorazione: la sua terza Committee Specification Draft ha concluso la revisione pubblica il 29 settembre 2026 e, a ottobre 2026, non è ancora un OASIS Standard approvato.

Qual è la differenza tra CSAF e CVE?

Un record CVE identifica una vulnerabilità e la descrive in termini generali. Un advisory CSAF è pubblicato da un vendor o da un coordinatore e spiega in che modo quella vulnerabilità, e spesso diverse altre, interessa prodotti e versioni specifici e che cosa fare. Gli advisory CSAF fanno riferimento agli ID CVE.

Che cos'è CSAF VEX?

CSAF VEX è il profilo csaf_vex di CSAF. Contiene dichiarazioni VEX: per ogni prodotto, se è interessato, non interessato, corretto o in fase di analisi, con una dichiarazione di impatto per i prodotti non interessati e una remediation per quelli interessati. Trivy e Grype possono leggerlo per sopprimere i rilevamenti.

Che cos'è un CSAF provider?

Un CSAF provider è un'organizzazione che pubblica i propri documenti CSAF in modo che gli strumenti possano individuarli: un file provider-metadata.json, reperibile tramite security.txt, un URL well-known o un nome DNS, e una directory o un feed ROLIE di advisory. Un trusted provider aggiunge hash, firme OpenPGP e una chiave pubblica pubblicata.

Che cosa ha sostituito CSAF?

Il Common Vulnerability Reporting Framework (CVRF), un formato XML. CVRF 1.1 è stato pubblicato da ICASI nel 2012 e CVRF 1.2 da OASIS nel 2017. CSAF 2.0 è passato a JSON e ha aggiunto profili, product tree e regole di distribuzione.

Come si scrive un advisory CSAF?

La maggior parte dei team inizia con un editor come Secvisogram, l'editor web del BSI per CSAF, oppure genera il JSON dal proprio tracciamento delle vulnerabilità. Scelga un profilo, di solito csaf_security_advisory, compili publisher, dati di tracking, product tree e vulnerabilità, lo convalidi rispetto allo schema e lo pubblichi tramite un provider.