CSAF: Common Security Advisory Framework koneluettaville tietoturvatiedotteille

Mikä on CSAF?

Common Security Advisory Framework (CSAF) on OASIS CSAF Technical Committeen standardi, jolla tietoturvatiedotteet kirjoitetaan jäsenneltynä JSONina ja jaetaan niin, että ne voidaan löytää ja käsitellä automaattisesti. CSAF-dokumentti kertoo, mihin tuotteisiin ja versioihin haavoittuvuus vaikuttaa, mihin ei, mitkä on korjattu ja mitä käyttäjien pitäisi tehdä.

Nykyinen versio on CSAF 2.0, joka hyväksyttiin OASIS-standardiksi 18.11.2022. CSAF 2.1 on tulossa: sen neljäs Committee Specification Draft oli julkisesti kommentoitavana 23.10.–6.11.2026, eikä se ole vielä hyväksytty standardi.

Tiedotteita kirjoittavat toimittajat, yleensä niiden tuoteturvallisuuden poikkeamiin reagoiva tiimi (PSIRT), sekä koordinaattorit, kuten kansalliset CERT-yksiköt. Näiden kahden tiimityypin eroista kerrotaan sivulla PSIRT vs. CSIRT.

CVRF:stä CSAF:ään

CSAF kehittyi Common Vulnerability Reporting Frameworkista (CVRF), joka oli XML-muoto. ICASI julkaisi CVRF 1.1:n toukokuussa 2012, ja OASIS julkaisi CVRF 1.2:n syyskuussa 2017. CSAF 2.0 korvasi sen JSON-muodolla, JSON-skeemalla validointia varten, eri dokumenttityyppien profiileilla ja säännöillä siitä, miten tiedotteet jaetaan ja löydetään. Määrittely kuvaa edelleen, miten CVRF-dokumentit muunnetaan CSAF:ksi.

CSAF-dokumentin rakenne

CSAF-dokumentissa on kolme ylimmän tason osaa:

• document: metatiedot. Viisi ominaisuutta on pakollisia: kategoria (mitä profiilia dokumentti noudattaa), CSAF-versio, julkaisija, otsikko ja seurantatiedot. Seurantatiedot sisältävät tiedotteen tunnisteen, tilan, version, ensimmäisen ja nykyisen julkaisupäivän sekä muutoshistorian.
• product_tree: jokainen dokumentissa mainittu tuote, yleensä haaroina toimittajasta tuotenimeen ja versioon, ja tuotetunnisteet, joihin dokumentin muut osat viittaavat. Tuotteet voidaan tunnistaa myös paketti-URL:n (purl), CPE:n tai tiivisteiden avulla.
• vulnerabilities: yksi merkintä haavoittuvuutta kohden, CVE- tai muine tunnisteineen, huomautuksineen, pisteytyksineen ja tuotetilalla, joka lajittelee tuotetunnisteet listoihin: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended ja under_investigation. Korjaustoimet luokitellaan seuraavasti: vendor_fix, workaround, mitigation, no_fix_planned tai none_available.

CSAF:n viisi profiilia

CSAF:ssä kokonaisuutena on vain vähän pakollisia kenttiä. Profiilit määrittävät, mitkä kentät tietynlaisessa dokumentissa on oltava, ja /document/category-arvo kertoo, mitä profiilia dokumentti noudattaa:

Profiili	Kategorian arvo	Käyttötarkoitus
CSAF Base	csaf_base	Vähimmäistaso, jonka jokainen CSAF-dokumentti täyttää; yleisprofiili dokumenteille, jotka eivät sovi muihin
Security incident response	csaf_security_incident_response	Tietomurtoon tai tietoturvapoikkeamaan reagointi, myös toisessa organisaatiossa sattuneeseen
Informational advisory	csaf_informational_advisory	Ongelmat, jotka eivät ole haavoittuvuuksia, kuten vaarallinen virheellinen konfiguraatio
Security advisory	csaf_security_advisory	Haavoittuvuudet ja niiden korjaustoimet; perinteinen toimittajan tietoturvatiedote
VEX	csaf_vex	Ilmoitus siitä, vaikuttaako haavoittuvuus kuhunkin tuotteeseen vai ei, ja miksi

Security advisory -dokumentissa on oltava tuotepuu, haavoittuvuudet, huomautukset kustakin haavoittuvuudesta ja tuotetila. VEX-profiili menee pidemmälle: jokainen known_not_affected-tuote tarvitsee vaikutuslausunnon joko koneluettavana lippuna tai tekstinä, ja jokainen known_affected-tuote tarvitsee korjaustoimen, joka kertoo käyttäjille, mitä tehdä.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) kertoo käyttäjille, mitkä tuotteen komponenttien haavoittuvuudet todella vaikuttavat tuotteeseen. CSAF VEX on yksi kolmesta yleisestä VEX-muodosta OpenVEX:n ja CycloneDX VEX:n rinnalla. Sen liput käyttävät samoja viittä not-affected-perustelua kuin CISA:n VEX-vaatimukset, kuten component_not_present ja vulnerable_code_not_in_execute_path. Sekä Trivy että Grype lukevat CSAF VEX:iä ja pudottavat löydökset, jotka se merkitsee ei-haavoittuviksi. Esimerkiksi Red Hat julkaisee CSAF VEX -dokumenttinsa erillisessä hakemistossa CSAF-tiedotteidensa rinnalla.

Miten CSAF-tiedotteet jaetaan

Vakiomuoto auttaa vain, jos työkalut löytävät dokumentit. CSAF 2.0:n luku 7 kertoo, miten:

• provider-metadata.json kuvaa julkaisijan ja sen, missä sen tiedotteet ovat. Työkalut löytävät sen vähintään yhtä kolmesta reitistä: CSAF-kentästä verkkotunnuksen security.txt-tiedostossa, well-known-URL:stä /.well-known/csaf/provider-metadata.json tai DNS-nimestä csaf.data.security. verkkotunnuksen edessä.
• Tiedotteet listataan joko vuosikohtaisiin kansioihin, joissa on index.txt ja changes.csv, tai ROLIE-syötteisiin, jotka tarjoillaan TLS:n yli ilman uudelleenohjauksia.
• Jokainen tiedosto nimetään sen seurantatunnisteen mukaan. TLP:WHITE-tiedotteiden on oltava vapaasti saatavilla, ja TLP:AMBER- tai TLP:RED-tiedotteiden on oltava pääsynhallinnan takana.
• Eheys: trusted providerit lisäävät jokaiselle dokumentille tiivisteen ja OpenPGP-allekirjoituksen ja julkaisevat julkisen avaimensa.

Standardi määrittelee viisi roolia, joita jakeleva osapuoli voi ottaa:

Rooli	Mitä se tekee
CSAF publisher	Julkaisee kelvollisia CSAF-dokumentteja vain omissa nimissään TLS:n yli
CSAF provider	Publisher, joka tarjoaa lisäksi provider-metadata.json-tiedoston, löydettävyysreitin ja hakemiston tai ROLIE-syötteen
CSAF trusted provider	Provider, joka julkaisee lisäksi tiivisteet, OpenPGP-allekirjoitukset ja julkisen avaimensa
CSAF lister	Ylläpitää luetteloa siitä, mistä muiden osapuolten CSAF-dokumentit löytyvät, kopioimatta niitä
CSAF aggregator	Peilaa vähintään kahden toisistaan riippumattoman julkaisijan dokumentit yhteen paikkaan tiivisteineen ja allekirjoituksineen

Käyttäjät määrittävät latausohjelman kerran ja hakevat sen jälkeen uudet tiedotteet jokaiselta providerilta, josta heidän tuotteensa riippuvat, sen sijaan että seuraisivat kymmeniä toimittajien verkkosivuja.

Kuka julkaisee CSAF:ää

CSAF on yleisintä teollisuuden, yritysohjelmistojen ja infrastruktuurin toimittajilla sekä kansallisilla CERT-yksiköillä:

• Cisco tarjoaa provider-metadata.json-tiedoston CSAF:n well-known-URL:ssään.
• Siemens ProductCERT julkaisee tiedotteensa CSAF ROLIE -syötteenä.
• Red Hat julkaisee CSAF-tiedotteita ja erikseen CSAF VEX -dokumentteja.
• BSI:n CERT-Bund, Saksan kansallinen CERT, julkaisee tiedotteistaan CSAF-syötteitä.
• CISA ilmoitti syyskuussa 2023, että sen ICS-tiedotteiden mukana tulee CSAF-dokumentit vuoteen 2017 asti taaksepäin, ja kehotti toimittajia ottamaan standardin käyttöön.

IEC 62443-4-1 -standardin mukaan toimivat teollisuuden toimittajat tarvitsevat prosessin, jolla ne kertovat käyttäjille tuotteidensa tietoturvaongelmista, ja koneluettavat tiedotteet ovat yleinen tapa vastata asiakkaiden odotuksiin.

CSAF-työkalut

• Secvisogram on BSI:n verkkoeditori CSAF-dokumenteille: siinä on lomake-editori, JSON-editori, HTML-esikatselu ja validointi.
• BSI:n ja Intevationin csaf-työkalut (gocsaf/csaf, usein nimeltään csaf_distribution) toteuttavat trusted providerin, tarkistimen, aggregaattorin ja latausohjelman, ja CSAF 2.1 -versio on kehitteillä.
• Skannerit, kuten Trivy ja Grype, lukevat CSAF VEX -dokumentteja.

Siirtyminen verkkosivuista ja RSS-syötteistä CSAF:ään

Useimmat toimittajat siirtyvät CSAF:ään viidessä vaiheessa: tuote- ja versioluettelo kuntoon, tarvittavan CSAF-roolin valinta, löydettävyystiedostojen ja syötteen julkaisu, tiedotteiden generointi käsin kirjoittamisen sijaan sekä VEX ja arkisto viimeisenä. CSAF:ään siirtymisessä ei ole kyse lähinnä JSONista. Kyse on tuoteluettelosta, johon tiedotteesi voivat viitata, ja polusta, jota koneet voivat seurata löytääkseen ne.

Mistä useimmat toimittajat aloittavat

Tavallinen ratkaisu on HTML-sivu tiedotetta kohden, joskus PDF, RSS- tai Atom-syöte ja postituslista. Ihmiset voivat lukea sitä. Asiakkaan puolen työkalu ei voi tehdä sillä paljoa: ei ole pysyviä tuotetunnisteita, ei versiokohtaista haavoittuva/ei haavoittuva -tilaa, ei tapaa löytää kaikkia toimittajan tiedotteita eikä eheystarkistusta. BSI kuvaa saman ongelman: joko on RSS-syöte, jonka voi tilata, tai uudet tiedotteet ilmestyvät vain verkkosivustolle, jolla jonkun on käytävä. Vanhan ratkaisun jokaisella osalla on CSAF-vastine:

Vanha osa	CSAF-vastine
Tiedotteen verkkosivu	CSAF-dokumentti profiililla csaf_security_advisory
"Haavoittuvat versiot" proosana	product_tree ja product_status
RSS-syöte	ROLIE-syöte tai hakemisto, jossa on index.txt ja changes.csv
"Tilaa"-sivu	provider-metadata.json ja löydettävyysreitti
PDF-allekirjoitus tai ei mitään	Tiivisteet ja OpenPGP-allekirjoitukset (trusted provider)
"Päivitetty viimeksi" -teksti	tracking ja revision_history

RSS-syöte on jakelukanava; CSAF on muoto. FIRST PSIRT Services Framework luettelee tiedotteen jakelutavoiksi "verkkodokumentin, RSS-syötteen tai tilauksen" ja ehdottaa erikseen tiedotteiden julkaisemista "koneluettavassa muodossa, kuten Common Security Advisory Frameworkissa (CSAF)", jotta asiakkaat voivat käsitellä niitä automaattisesti. Voit pitää syötteen.

Vaihe 1: tuoteluettelo kuntoon ensin

product_tree on kohta, johon siirtymät kaatuvat. Ennen ensimmäistä CSAF-dokumenttia tarvitset kanonisen tuote- ja versioluettelon, joka vastaa sitä, mitä asiakkaat näkevät laitteissaan ja laiteinventaarioissaan, mieluiten CPE:n tai paketti-URL:n kera kullekin. Se on sama luettelo, jonka PSIRT tarvitsee tietääkseen, mihin versioihin CVE vaikuttaa, ja siksi PSIRT-toiminnan skaalaaminen alkaa versiokohtaisesta inventaariosta. Haara kulkee toimittajasta tuoteperheeseen, tuotteeseen ja versioon:

"product_tree": {
  "branches": [{
    "category": "vendor",
    "name": "Example Networks",
    "branches": [{
      "category": "product_family",
      "name": "EX Series",
      "branches": [{
        "category": "product_name",
        "name": "EX-200",
        "branches": [{
          "category": "product_version",
          "name": "4.2.1",
          "product": {
            "product_id": "EX200-4.2.1",
            "name": "Example Networks EX-200 4.2.1",
            "product_identification_helper": {
              "cpe": "cpe:2.3:o:example:ex-200_firmware:4.2.1:*:*:*:*:*:*:*"
            }
          }
        }]
      }]
    }]
  }]
}

Kun tuote sisältää avoimen lähdekoodin komponentteja, tiedote nimeää sinun tuoteversiosi. Päätöksen taustalla oleva komponentti-inventaario, eli se, mitkä versiot sisältävät haavoittuvan kirjaston, on SBOM (mikä on SBOM?).

Vaihe 2: valitse roolisi

Viisi roolia on kuvattu edellä. Toimittajalle valinta tiivistyy kolmeen:

Rooli	Valitse, kun	Mitä se lisää
CSAF publisher	Tarvitset aluksi vain kelvolliset CSAF-dokumentit sivustollesi	Kelvolliset dokumentit TLS:n yli; työkalut eivät löydä niitä itse
CSAF provider	Asiakkaiden pitäisi hakea tiedotteesi automaattisesti: realistinen vähimmäistaso	provider-metadata.json, löydettävyysreitti ja hakemisto tai ROLIE-syöte
CSAF trusted provider	Asiakkaat tai viranomaiset odottavat allekirjoitettuja tiedotteita	Tiivisteet, OpenPGP-allekirjoitukset ja julkaistu julkinen avain

Lister ja aggregator ovat koordinaattoreille, eivät toimittajille. gocsaf/csaf-työkaluihin kuuluvat csaf_provider, joka toteuttaa trusted providerin, ja csaf_checker, joka testaa provider-asennuksen standardin luvun 7 mukaisesti. Aja tarkistin ennen kuin julkistat syötteen.

Vaihe 3: löydettävyys ja syöte

• Julkaise provider-metadata.json polussa /.well-known/csaf/ verkkotunnuksessasi.
• Viittaa siihen security.txt:stä. RFC 9116 määrittelee tiedoston, ja CSAF 2.0:n vaatimus 8 lisää CSAF:-kentän, jonka URL:n on alettava https://.

Contact: mailto:[email protected]
Expires: 2027-11-11T00:00:00.000Z
# Our security advisories
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

• Korvaa RSS-syöte ROLIE-syötteellä tai pidä molemmat. ROLIE (Resource-Oriented Lightweight Information Exchange, RFC 8322) perustuu Atomiin, joten se on luonteva seuraaja jo julkaisemallesi syötteelle. Myös hakemisto, jossa on index.txt ja changes.csv, toimii.
• Merkitse jokainen syöte TLP-tasolla. CSAF 2.0 käyttää TLP 1.0:n merkintöjä WHITE, GREEN, AMBER ja RED. FIRSTin TLP 2.0, joka on ollut virallinen elokuusta 2022, käyttää merkintöjä CLEAR, GREEN, AMBER ja RED sekä AMBER+STRICT-merkintää AMBERin laajennuksena, ja CSAF 2.1:n luonnokset ottavat nämä merkinnät käyttöön. Julkiset tiedotteet ovat CSAF 2.0:ssa TLP:WHITE-tasoa.

Vaihe 4: generoi, älä kirjoita käsin

Generoi uudet tiedotteet kirjauksesta, jota jo pidät kustakin haavoittuvuudesta, eli seurantajärjestelmäsi tapauksesta tai haavoittuvuustietokannastasi, ja validoi jokainen skeemaa ja standardin testejä vasten ennen julkaisua. Secvisogram sopii pieniin määriin ja muokkaamiseen. Muodosta ihmisille luettava sivu samasta JSON-dokumentista, jotta verkkosivu ja CSAF-tiedosto eivät koskaan ole ristiriidassa. Revisio päivittää tracking/version- ja revision_history-kentät samassa dokumentissa; uutta dokumenttia ei julkaista.

Vaihe 5: VEX ja arkisto

Julkaise not-affected-lausunnot CSAF VEX -muodossa niistä CVE:istä, joista asiakkaat kysyvät eniten, koska jokainen niistä lopettaa toistuvan kysymyksen. Täydennä vanhemmat tiedotteet viimeisenä, alkaen tuotteista, joilla on yhä tuki. Jos vanhat tiedotteesi ovat CVRF-muodossa, määrittelyn muunnossäännöt kattavat ne.

CSAF 2.0 vai 2.1?

Julkaise 2.0 nyt. Se on hyväksytty OASIS-standardi, ja se on julkaistu myös kansainvälisenä standardina ISO/IEC 20153:2025. CSAF 2.1 on yhä Committee Specification Draft: neljäs luonnos hyväksyttiin 21.10.2026, ja sen julkinen kommentointi päättyi 6.11.2026. Työkalut valmistautuvat: Secvisogram muokkaa jo 2.1-dokumentteja, ja 2.1-tuki on kehitteillä gocsaf/csaf-työkalujen seuraavaan pääversioon.

Mitä CRA ja BSI odottavat

• EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) ei nimeä CSAF:ää. Sen 14 artiklan 8 kohta edellyttää, että valmistaja, joka saa tietää aktiivisesti hyödynnetystä haavoittuvuudesta tai vakavasta poikkeamasta, ilmoittaa siitä asianomaisille käyttäjille ja tarvittaessa kaikille käyttäjille, "tarvittaessa jäsennellyssä, koneluettavassa muodossa, joka on helposti automaattisesti käsiteltävissä". Liitteen I osa II edellyttää, että valmistajat julkistavat tiedot korjatuista haavoittuvuuksista, kun tietoturvapäivitys on saatavilla, ja että niillä on koordinoidun haavoittuvuuksien julkistamisen toimintaperiaatteet. CSAF on yksi tapa täyttää koneluettavuutta koskeva osa.
• BSI julkaisee omat CERT-Bund-tiedotteensa CSAF-muodossa. Sen tekninen ohje TR-03183-3 (Vulnerability Reports and Notifications, v1.0.0, elokuu 2025) nimeää julkaisun valmistajan verkkosivustolla CSAF:ää käyttäen suositelluksi tavaksi jakaa tiedotteet (kohta 3.1.5). Se edellyttää security.txt-tiedostoa (kohta 4.2) ja sanoo, että valmistajan pitäisi listata siinä provider-metadata.json-tiedostonsa CSAF:-kentällä (kohta 4.2.8). Tekninen ohje on ohjeistusta, ei lakia.
• ENISAn keskitetty raportointialusta (Single Reporting Platform) on tarkoitettu CRA:n mukaisiin ilmoituksiin viranomaisille, ei tiedotteisiin käyttäjille. CSAF-tiedotteen julkaiseminen ei korvaa ilmoitusta, eikä ilmoitus tiedota käyttäjiäsi.

CSAF-ratkaisun vähimmäistaso

• Tuote- ja versioluettelo CPE- tai paketti-URL-tunnisteineen, kun niitä on
• Julkaisijan metatiedot: nimi, kategoria, nimiavaruus ja yhteystiedot
• Ensimmäinen tiedote csaf_security_advisory-profiililla
• Validointi skeemaa ja standardin testejä vasten
• provider-metadata.json polussa /.well-known/csaf/
• CSAF:-rivi security.txt-tiedostossa
• ROLIE-syöte tai hakemisto, jossa on index.txt ja changes.csv
• TLS jokaisessa URL:ssä ilman uudelleenohjauksia
• Ihmisille luettava sivu JSONista muodostettuna
• Julkaistu allekirjoitusavain, kun siirryt trusted provideriksi

Hyvän tietoturvatiedotteen kirjoittaminen

CSAF:n kanssa tai ilman hyödyllinen tiedote vastaa samoihin kysymyksiin. Tämä on pohja, johon useimmat PSIRT-tiimit päätyvät, ja kunkin vastauksen CSAF-kenttä:

Tiedotteen osa	Mitä kirjoittaa	CSAF:ssä
Tunniste ja otsikko	Pysyvä tiedotetunniste ja otsikko, joka nimeää tuotteen ja ongelman tyypin	tracking/id, title
Päivämäärät ja revisiot	Ensimmäinen julkaisu, viimeisin päivitys ja mitä kussakin revisiossa muuttui	tracking-päivämäärät ja revision_history
Haavoittuvat tuotteet	Tarkat tuotteet ja versiovälit, ei "vanhemmat versiot"	product_tree, known_affected
Ei haavoittuvat ja korjatut	Mihin tuotteisiin ja versioihin haavoittuvuus ei vaikuta ja mitkä versiot sisältävät korjauksen	known_not_affected, fixed, first_fixed
Haavoittuvuus	CVE-tunnisteet, selkeä kuvaus, vaikutus ja hyödyntämistapa ilman ohjetta hyökkääjille	cve, ids, notes
Vakavuus	CVSS-pisteet vektoreineen, jotta lukijat voivat tarkistaa ne	scores
Korjaustoimet	Korjattu versio, kiertotie tai lievennys tai selkeä ilmoitus siitä, ettei korjausta suunnitella	remediations
Kiitokset ja viitteet	Kuka sen ilmoitti, linkit liittyviin tiedotteisiin ja korjauksiin	acknowledgments, references
Yhteystiedot	Minne ilmoittaa ongelmista ja esittää kysymyksiä	publisher/contact_details

Muutama tapa ratkaisee, toimivatko ihmiset tiedotteen perusteella vai sivuuttavatko he sen:

• Ole tarkka versioista. Asiakkaat toimivat haavoittuvan versiovälin perusteella. Nimeä kunkin tuotelinjan ensimmäinen haavoittuva ja ensimmäinen korjattu versio.
• Kerro, mihin haavoittuvuus ei vaikuta. Asiakkaat, joiden tuotteet olet sulkenut pois, lakkaavat kysymästä, ja heidän skannerinsa lakkaavat merkitsemästä niitä, jos julkaiset myös VEX-tiedot.
• Päivitä, älä korvaa. Pidä yksi tiedote ongelmaa kohden ja lisää revisioita korjausten valmistuessa.
• Julkaise sovittuna päivänä. Tiedotteet ovat koordinoidun haavoittuvuuksien julkistamisen päätepiste, ja ne julkaistaan, kun korjaus on saatavilla ja ilmoittajalle on kerrottu.

Tiedotetta edeltävät vaiheet vastaanotosta ja triagesta korjaukseen käsitellään sivulla haavoittuvuuksien hallinnan elinkaari, ja tätä työtä tekevät ihmiset sivulla PSIRT-rooli.

Vaikein osa on tietää, mihin haavoittuvuus vaikuttaa

Jokainen tiedote, CSAF-muodossa tai missä tahansa muussa, riippuu yhdestä vastauksesta: mitkä tuotteet ja versiot sisältävät haavoittuvan komponentin. Avoimen lähdekoodin paketeista rakennetuissa ohjelmistoissa tämä tarkoittaa, että tiedät tarkalleen, mitkä riippuvuusversiot päätyivät kuhunkin julkaisuun, transitiiviset mukaan lukien.

CRACI ei kirjoita eikä julkaise tiedotteita. Se tuottaa kirjauksen, jonka pohjalta tiedotteen tuotetila rakennetaan. CRACI ajaa GitHub Actions -buildit omilla runnereillaan ja tallentaa paketit, jotka kukin jobi todella haki, mukaan lukien transitiiviset riippuvuudet, välimuisteista palautetut paketit ja riippuvuudet, joita mikään lukitustiedosto ei listaa. Kun uusi haavoittuvuus julkaistaan, valvotut SBOM:t arvioidaan uudelleen, ja buildihistoria näyttää, mitkä aiemmat buildit ja julkaisut sisälsivät haavoittuvan riippuvuuden suoraan tai transitiivisesti ja mistä lähtien. Inventaarionäkymä näyttää, mitkä versiot ovat käytössä missäkin tuotteessa, ja triage ohjaa kunkin löydöksen korjauksesta vastaavalle tiimille. SBOM:t viedään CycloneDX- tai SPDX-muodossa, ja CRACI tukee VEX:iä. Katso haavoittuvuuksien seuranta.

CSAF: usein kysytyt kysymykset

Mitä CSAF tarkoittaa?

Tietoturvassa CSAF tarkoittaa Common Security Advisory Frameworkia, OASIS-standardia, jolla tietoturvatiedotteet kirjoitetaan koneluettaviksi JSON-dokumenteiksi ja jaetaan niin, että työkalut voivat löytää ja käsitellä ne automaattisesti.

Mikä on CSAF:n nykyinen versio?

CSAF 2.0, joka hyväksyttiin OASIS-standardiksi 18.11.2022 ja julkaistiin myös standardina ISO/IEC 20153:2025. CSAF 2.1 on työn alla: sen neljäs Committee Specification Draft hyväksyttiin 21.10.2026, ja sen julkinen kommentointi päättyi 6.11.2026. Se ei ole vielä hyväksytty OASIS-standardi.

Mikä ero on CSAF:llä ja CVE:llä?

CVE-tietue yksilöi yhden haavoittuvuuden ja kuvaa sen yleisellä tasolla. CSAF-tiedotteen julkaisee toimittaja tai koordinaattori, ja se kertoo, miten kyseinen haavoittuvuus ja usein useat muutkin vaikuttavat tiettyihin tuotteisiin ja versioihin ja mitä asialle pitää tehdä. CSAF-tiedotteet viittaavat CVE-tunnisteisiin.

Mikä on CSAF VEX?

CSAF VEX on CSAF:n csaf_vex-profiili. Se sisältää VEX-lausuntoja: kunkin tuotteen osalta, onko se haavoittuva, ei haavoittuva, korjattu vai selvityksen alla, vaikutuslausunnon tuotteille, joihin haavoittuvuus ei vaikuta, ja korjaustoimen tuotteille, joihin se vaikuttaa. Trivy ja Grype voivat lukea sitä ja piilottaa löydöksiä.

Mikä on CSAF provider?

CSAF provider on organisaatio, joka julkaisee omat CSAF-dokumenttinsa niin, että työkalut löytävät ne: provider-metadata.json-tiedosto, joka löytyy security.txt:n, well-known-URL:n tai DNS-nimen kautta, sekä tiedotteiden hakemisto tai ROLIE-syöte. Trusted provider lisää tiivisteet, OpenPGP-allekirjoitukset ja julkaistun julkisen avaimen.

Minkä CSAF korvasi?

Common Vulnerability Reporting Frameworkin (CVRF), XML-muodon. ICASI julkaisi CVRF 1.1:n vuonna 2012 ja OASIS CVRF 1.2:n vuonna 2017. CSAF 2.0 siirtyi JSONiin ja lisäsi profiilit, tuotepuut ja jakelusäännöt.

Miten kirjoitan CSAF-tiedotteen?

Useimmat tiimit aloittavat editorilla, kuten Secvisogramilla, joka on BSI:n verkkoeditori CSAF:lle, tai generoivat JSONin omasta haavoittuvuuksien seurannastaan. Valitse profiili, yleensä csaf_security_advisory, täytä julkaisija, seurantatiedot, tuotepuu ja haavoittuvuudet, validoi dokumentti skeemaa vasten ja julkaise se providerin kautta.

Miten siirrämme tietoturvatiedotteemme verkkosivulta CSAF:ään?

Aloita kanonisesta tuote- ja versioluettelosta ja ryhdy sitten CSAF provideriksi: julkaise provider-metadata.json, viittaa siihen security.txt:stä ja listaa tiedotteet ROLIE-syötteeseen tai hakemistoon. Generoi uudet tiedotteet haavoittuvuuskirjauksistasi, muodosta verkkosivu samasta JSONista ja täydennä vanhat tiedotteet viimeisenä.

Voimmeko pitää RSS-syötteemme, kun julkaisemme CSAF:ää?

Kyllä. RSS-syöte on jakelukanava ja CSAF on muoto, joten ne voivat elää rinnakkain. Jos haluat yhden syötteen sekä ihmisille että koneille, ROLIE-syöte perustuu Atomiin ja voi korvata RSS-syötteen. Generoi molemmat samasta tiedotedatasta, jotta ne eivät koskaan ole ristiriidassa.

Mikä CSAF-rooli tarvitsemme: publisher, provider vai trusted provider?

Useimpien toimittajien on oltava CSAF provider: kelvolliset dokumentit, provider-metadata.json, löydettävyysreitti ja hakemisto tai ROLIE-syöte, jotta asiakkaat voivat hakea tiedotteet automaattisesti. Pelkkä publisher on lähtökohta, jota työkalut eivät löydä. Ryhdy trusted provideriksi, jossa on tiivisteet, OpenPGP-allekirjoitukset ja julkinen avain, kun asiakkaat tai viranomaiset odottavat allekirjoitettuja tiedotteita.

Vaatiiko kyberkestävyyssäädös CSAF:ää?

Ei. CRA ei nimeä mitään muotoa. Sen 14 artiklan 8 kohta edellyttää, että valmistajat ilmoittavat asianomaisille käyttäjille aktiivisesti hyödynnetystä haavoittuvuudesta tai vakavasta poikkeamasta, tarvittaessa jäsennellyssä, koneluettavassa muodossa, joka on helposti automaattisesti käsiteltävissä. CSAF on yksi tapa täyttää tämä, ja BSI suosittelee sitä.

Mitä BSI odottaa valmistajilta CSAF:n suhteen?

BSI TR-03183-3, joka on tekninen ohje eikä laki, nimeää julkaisun valmistajan verkkosivustolla CSAF:ää käyttäen suositelluksi tavaksi jakaa tiedotteet. Se edellyttää security.txt-tiedostoa ja sanoo, että valmistajien pitäisi listata siinä provider-metadata.json-tiedostonsa CSAF:-kentällä. BSI julkaisee omat CERT-Bund-tiedotteensa CSAF-muodossa.

Pitäisikö julkaista CSAF 2.0 vai odottaa 2.1:tä?

Julkaise 2.0 nyt. Se on hyväksytty OASIS-standardi ja ISO/IEC 20153:2025, ja työkalut tukevat sitä. CSAF 2.1 on yhä Committee Specification Draft, ja sen neljäs luonnos oli kommentoitavana loka- ja marraskuussa 2026. Siirtyminen 2.1:een myöhemmin tarkoittaa työkalujen päivittämistä, eikä se ole syy odottaa.