Koordinoitu haavoittuvuuksien julkistaminen: näin pyörität julkistamisohjelmaa

Mitä koordinoitu haavoittuvuuksien julkistaminen on?

Koordinoitu haavoittuvuuksien julkistaminen (coordinated vulnerability disclosure, CVD) tarkoittaa, että vasta löydetty haavoittuvuus käsitellään luottamuksellisesti löytäjän ja toimittajan kesken, kunnes korjaus tai lievennys on saatavilla, ja julkaistaan vasta sitten. CERT Guide to Coordinated Vulnerability Disclosure kuvaa sen tietojen keräämiseksi haavoittuvuuksien löytäjiltä, tietojen jakamisen koordinoimiseksi asianosaisten kesken sekä haavoittuvuuden ja sen lievennysten julkistamiseksi, myös yleisölle.

Tuotetoimittajalle CVD:ssä on kaksi puolta. Ulospäin suuntautuva puoli, raporttien vastaanottaminen ja tietoturvatiedotteiden julkaiseminen, on tämän sivun aihe. Sisäänpäin suuntautuva puoli, varmistaminen, korjaaminen ja julkaisu, on haavoittuvuuksien hallinnan elinkaari. Molemmista vastaa yleensä PSIRT.

CVD vs. täysi julkistaminen vs. bug bounty

	Koordinoitu julkistaminen	Täysi julkistaminen	Bug bounty
Mitä se on	Luottamuksellinen raportti, korjaus ja julkaisu sovittuna ajankohtana	Löytäjä julkaisee yksityiskohdat heti, kertoi hän toimittajalle tai ei	Ohjelma, joka maksaa pätevistä löydöksistä
Kuka päättää aikataulusta	Toimittaja ja löytäjä yhdessä, joskus koordinaattorin kanssa	Löytäjä	Ohjelman ehdot, yleensä CVD:n mukaisesti
Riski käyttäjille	Pienin: yksityiskohdat julkaistaan, kun korjaus on olemassa tai määräaika umpeutuu	Suurin: hyökkääjät saavat tiedon samaan aikaan kuin puolustajat	Kuten CVD:ssä
Kustannus	Henkilöstön aika triageen ja vastaamiseen	Suunnittelematonta hätätyötä	Henkilöstön aika sekä palkkiot ja usein alustamaksut

Bug bounty ei ole vaihtoehto haavoittuvuuksien julkistamisohjelmalle (vulnerability disclosure program, VDP). Se on kannustin, joka rakennetaan sellaisen päälle. Jokainen toimittaja tarvitsee tavan, jolla kuka tahansa voi ilmoittaa haavoittuvuudesta; bounty ratkaisee vain, maksetaanko osasta raporteista.

Mitä haavoittuvuuksien julkistamiskäytäntöön kuuluu

Haavoittuvuuksien julkistamiskäytäntö on julkinen dokumentti, joka määrittää ohjelmasi ehdot. ISO/IEC 29147, haavoittuvuuksien julkistamisen kansainvälinen standardi, tekee yhdestä osasta pakollisen, ensisijaisen yhteydenottotavan, ja suosittelee useita muita. Kattava käytäntö sisältää:

• Miten ilmoittaa. Oma osoite tai verkkolomake sekä tapa lähettää arkaluonteiset tiedot turvallisesti, esimerkiksi julkaistu salausavain.
• Mitä raporttiin kuuluu. Kyseinen tuote ja versio, toistamisen vaiheet, vaikutus ja ilmoittajan yhteystiedot.
• Soveltamisala. Mitkä tuotteet, versiot ja palvelut kuuluvat piiriin ja mitkä testausmenetelmät ovat kiellettyjä, kuten palvelunestohyökkäykset tai muiden käyttäjien tietoihin pääseminen.
• Safe harbor. Sitoumus olla ryhtymättä oikeustoimiin hyvässä uskossa tehtyä, käytäntöä noudattavaa tutkimusta vastaan.
• Mitä ilmoittajat voivat odottaa. Milloin kuittaat raportin, miten pidät ilmoittajan ajan tasalla ja mikä on tavoiteaikasi korjaukselle.
• Julkistamisen aikataulu. Milloin yksityiskohdat julkaistaan ja mitä tapahtuu, jos korjaus vie pidempään.
• Julkaisu. Missä tietoturvatiedotteet julkaistaan ja annatko CVE-tunnisteita.
• Tunnustus. Mainitsetko ilmoittajat ja miten, sekä maksatko palkkioita.

Pidä käytäntö lyhyenä ja täsmällisenä. Ilmoittajat lukevat sen päättääkseen, onko sinulle ilmoittaminen turvallista ja vaivan arvoista.

Käytäntöpohja, jonka voit kopioida

Alla oleva pohja noudattaa Yhdysvaltain kyberturvallisuus- ja infrastruktuurivirasto CISA:n (Cybersecurity and Infrastructure Security Agency) julkaiseman vulnerability disclosure policy -pohjan rakennetta, omin sanoin. Korvaa hakasulkeissa olevat kohdat ja anna lakitiimisi tarkistaa valtuutusta koskeva osio ennen julkaisemista.

Haavoittuvuuksien julkistamiskäytäntö, [Yritys]
Päivitetty viimeksi: [päivämäärä]

Otamme mielellämme vastaan ilmoituksia tuotteidemme ja palveluidemme
tietoturvahaavoittuvuuksista. Tämä käytäntö kertoo, miten voit
ilmoittaa haavoittuvuudesta ja mitä voit odottaa meiltä.

Valtuutus
Jos pyrit hyvässä uskossa noudattamaan tätä käytäntöä, katsomme
tutkimuksesi valtuutetuksi. Emme ryhdy emmekä suosittele ryhtymään
oikeustoimiin sinua vastaan sen vuoksi. Jos kolmas osapuoli ryhtyy
oikeustoimiin sinua vastaan tätä käytäntöä noudattaneen tutkimuksen
vuoksi, kerromme julkisesti, että tutkimuksesi oli valtuutettua.

Ohjeet
- Kerro meille mahdollisimman pian, kun löydät mahdollisen haavoittuvuuden.
- Vältä yksityisyyden loukkauksia, tuotantojärjestelmien häiritsemistä
  sekä tietojen tuhoamista tai muokkaamista.
- Käytä hyökkäyskoodia vain siinä määrin kuin haavoittuvuuden
  vahvistaminen vaatii. Älä käytä sitä tietojen käyttämiseen tai
  ulos viemiseen, pysyvän pääsyn ylläpitämiseen tai muihin
  järjestelmiin siirtymiseen.
- Anna meille kohtuullisesti aikaa korjata ongelma ennen kuin julkistat sen.

Soveltamisala
Piiriin kuuluvat: [tuotteet, versiot ja verkkotunnukset].
Piiriin eivät kuulu: palvelunestohyökkäykset, social engineering,
fyysiset hyökkäykset ja [muut poikkeukset].

Miten ilmoittaa
Lähetä ilmoituksesi osoitteeseen [[email protected]] tai [verkkolomake].
Salaa arkaluonteiset tiedot avaimella [linkki julkiseen avaimeen].
Kerro kyseinen tuote ja versio, toistamisen vaiheet ja vaikutus.

Mitä voit odottaa meiltä
- Kuittaamme ilmoituksesi [3] arkipäivän kuluessa.
- Vahvistamme, onko haavoittuvuus olemassa, ja pidämme sinut ajan
  tasalla korjaukseen asti, myös kaikesta, mikä viivästyttää korjausta.
- Julkaisemme tietoturvatiedotteen [90 päivän kuluessa] ja mainitsemme
  sinut, jos haluat.

security.txt: tee yhteystiedoistasi helppoja löytää

Käytäntö toimii vain, jos tutkijat löytävät sen. Huhtikuussa 2022 julkaistu RFC 9116 määrittelee security.txt-tiedoston, pienen tekstitiedoston, joka tarjoillaan osoitteessa /.well-known/security.txt HTTPS:n yli.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Pakolliset: Contact ja Expires. RFC 9116 suosittelee alle vuoden päähän asetettua vanhenemisaikaa, jotta tiedosto ei vanhene huomaamatta.
• Valinnaiset: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical ja Hiring.
• Allekirjoitus: RFC suosittelee OpenPGP-selväkieliallekirjoitusta, kun Canonical on asetettu.

Merkitse kalenteriin muistutus ennen Expires-päivämäärää. Vanhentunut tiedosto kertoo tutkijoille, ettei kukaan lue ilmoituksia.

Embargot ja julkistamisen aikataulut

Embargo on raportin ja julkaisun välinen aika. Useimmin viitattu käytäntö on Google Project Zeron käytäntö: toimittajilla on 90 päivää aikaa julkaista korjaus, ja yksityiskohdat julkaistaan 30 päivää korjauksen julkaisun jälkeen. Toimittaja, joka tarvitsee hieman lisäaikaa, voi pyytää armonaikaa, enintään 104 päivään asti yhteensä. Kun haavoittuvuutta jo hyödynnetään aktiivisesti, määräaika lyhenee 7 päivään.

Oma käytäntösi voi asettaa erilaiset ehdot, ja monet ilmoittajat hyväksyvät ne. Olennaista on, että aikataulu on kirjattu, että pidät ilmoittajat ajan tasalla ja että pyydät jatkoaikaa ennen määräaikaa etkä sen jälkeen. Aikataulussa julkaistu tietoturvatiedote lievennyksineen on parempi kuin hiljaisuus.

CVE-tunnisteet ja CNA:t

Useimmissa tietoturvatiedotteissa on CVE-tunniste, jotta asiakkaat ja työkalut voivat yhdistää ne. Tunnisteet antavat CVE Numbering Authorityt (CNA:t), organisaatiot, joilla on valtuudet antaa tunnisteita sovitulla vastuualueella. Monet ohjelmistotoimittajat ovat CNA:ita omille tuotteilleen, joten ne voivat antaa tunnisteen ja julkaista tietueen omassa aikataulussaan. Jos et ole CNA, tunnisteen antaa CNA, jonka vastuualueeseen tuotteesi kuuluu, tai CNA of Last Resort.

Usean osapuolen koordinointi

Jotkin haavoittuvuudet koskevat montaa toimittajaa kerralla: vika laajasti käytetyssä kirjastossa, protokollassa tai sirussa. Silloin koordinaattori auttaa tavoittamaan jokaisen asianomaisen toimittajan ja sopimaan yhden julkaisupäivän.

• CERT/CC Carnegie Mellon Universityn Software Engineering Institutessa koordinoi usean toimittajan tapauksia ja julkaisee CERT:n CVD-oppaan.
• EU:n kansalliset CSIRT-yksiköt. NIS2-direktiivin mukaan kukin jäsenvaltio nimeää CSIRT-yksikön CVD-koordinaattorikseen. Se toimii luotettuna välittäjänä ilmoittajien ja toimittajien välillä, neuvottelee julkistamisen aikatauluista, käsittelee useaa toimijaa koskevia haavoittuvuuksia ja ottaa vastaan nimettömiä ilmoituksia.
• ENISAn eurooppalainen haavoittuvuustietokanta (EUVD), joka perustettiin NIS2-direktiivin nojalla, on ollut toiminnassa toukokuusta 2025 ja julkaisee tietoja julkisesti tunnetuista haavoittuvuuksista, myös EU:ssa koordinoiduista.

ISO/IEC 29147 kattaa myös tilanteen, jossa olet molempia: toimittaja, jonka tuotteessa on toisen toimittajan haavoittuva komponentti ja jonka on ilmoitettava siitä eteenpäin alkulähteelle ja tiedotettava omia asiakkaitaan.

Kun raportti saapuu

1. Kuittaa raportti käytäntösi lupaamassa ajassa ja anna ilmoittajalle seurantatunnus.
2. Varmista raportti ja arvioi sen vakavuus.
3. Selvitä, mihin se vaikuttaa: jokainen tuote, julkaisu ja tuettu haara, jossa haavoittuva koodi tai komponentti on.
4. Korjaa ja julkaise jokaiselle haavoittuvalle haaralle ja pidä ilmoittaja ajan tasalla.
5. Julkaise tietoturvatiedote CVE-tunnisteen, haavoittuvien versioiden, korjausohjeiden ja ilmoittajan mainitsemisen kera. Koneluettavat tietoturvatiedotteet käyttävät CSAF-muotoa, ja VEX kertoo asiakkaille, mihin tuotteisiin haavoittuvuus ei vaikuta.

Koko prosessi rooleineen, aikatauluineen ja mittareineen on kuvattu sivulla haavoittuvuuksien hallinnan elinkaari.

Sääntely tekee CVD-käytännöistä pakollisia

EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) edellyttää, että valmistajat ottavat käyttöön koordinoitua haavoittuvuuksien julkistamista koskevan käytännön ja panevat sen täytäntöön sekä antavat yhteysosoitteen haavoittuvuuksista ilmoittamista varten, myös kolmansien osapuolten komponenttien haavoittuvuuksista (liite I, osa II). Näitä velvollisuuksia sovelletaan 11.12.2027 alkaen; katso mitä CRA vaatii. NIS2-direktiivin 21 artiklan 2 kohdan e alakohta luettelee haavoittuvuuksien käsittelyn ja julkistamisen turvallisuustoimenpiteiden joukossa, jotka keskeisten ja tärkeiden toimijoiden on toteutettava. Yhdysvalloissa Executive Order 14028 edellytti ohjeistusta ohjelmistotoimitusketjulle, ja siihen sisältyy osallistuminen haavoittuvuuksien julkistamisohjelmaan.

Viranomaisille raportointi on erillinen velvollisuus, ja se on jo voimassa: 11.9.2026 alkaen valmistajan, joka saa tietää tuotteessaan aktiivisesti hyödynnetystä haavoittuvuudesta, on lähetettävä ennakkovaroitus 24 tunnin kuluessa CRA:n keskitetyn raportointialustan kautta. Koko aikataulu on sivulla mitä CRA vaatii.

Raportti on vain niin hyödyllinen kuin kirjauksesi siitä, mitä toimitit

Jokainen raportti herättää saman ensimmäisen kysymyksen: missä julkaisuissamme tämä on? CRACI ajaa GitHub Actions -buildisi omilla runnereillaan ja tallentaa paketit, jotka kukin jobi oikeasti haki, myös transitiiviset riippuvuudet, CI-välimuisteista palautetut paketit ja riippuvuudet, joita mikään lukitustiedosto ei listaa. Buildihistoria näyttää, missä aiemmissa buildeissa oli haavoittuva riippuvuus, joten tiedät, minkä ajanjakson olit altistuneena, ja inventaarionäkymä näyttää, mitkä ohjelmistoversiot on otettu käyttöön missäkin tuotteessa.

CRACI kokoaa SBOM:t buildien ja repojen yli ja arvioi seurattuja SBOM:eja jatkuvasti uudelleen, joten kun avoimen lähdekoodin komponentin haavoittuvuus julkaistaan, näet kaikki paikat, joissa se esiintyy. Tietoturvatiimit tekevät löydöksille triagen ja lähettävät ne korjauksesta vastaaville tiimeille, CRACI tukee VEX:iä, ja käytäntöportit voivat estää buildit, joissa on tietty CVE, kun se on korjattu. Katso haavoittuvuuksien seuranta.

Koordinoitu haavoittuvuuksien julkistaminen: usein kysytyt kysymykset

Mitä koordinoitu haavoittuvuuksien julkistaminen on?

Koordinoitu haavoittuvuuksien julkistaminen (CVD) on prosessi, jossa haavoittuvuuden löytäjä ilmoittaa siitä luottamuksellisesti toimittajalle, toimittaja korjaa sen ja yksityiskohdat julkaistaan, kun käyttäjät voivat suojautua, yleensä osapuolten sopimana päivänä. Koordinaattorit, kuten CERT/CC tai kansallinen CSIRT-yksikkö, tulevat mukaan, kun toimittajaa ei tavoiteta tai kun haavoittuvuus koskee useaa toimittajaa.

Mitä eroa on VDP:llä ja bug bountylla?

Haavoittuvuuksien julkistamisohjelma (VDP) kertoo kenelle tahansa, miten haavoittuvuudesta ilmoitetaan ja mitä voi odottaa, maksamatta löydöksistä. Bug bounty maksaa tutkijoille pätevistä löydöksistä, yleensä määritellyllä alueella ja usein bounty-alustan kautta. Useimmat organisaatiot aloittavat VDP:llä; bounty on valinnainen lisä sen päälle, ei sen korvaaja.

Mitä haavoittuvuuksien julkistamiskäytännön pitäisi sisältää?

Vähintään sen, miten ilmoitetaan: yhteysosoitteen tai lomakkeen. ISO/IEC 29147 suosittelee myös kertomaan, mitä raportin pitäisi sisältää, miten viestitään turvallisesti, mitä ilmoittajat voivat odottaa ja milloin, mikä kuuluu soveltamisalaan, miten tietoturvatiedotteet julkaistaan ja miten ilmoittajat mainitaan. Useimpiin käytäntöihin lisätään safe harbor -lauseke ja julkistamisen aikataulu.

Mikä security.txt on?

security.txt on RFC 9116:ssa määritelty tekstitiedosto, joka tarjoillaan osoitteessa /.well-known/security.txt. Se kertoo tutkijoille, minne haavoittuvuuksista ilmoitetaan. Siinä on oltava Contact- ja Expires-kenttä, ja se voi linkittää käytäntöösi, salausavaimeesi ja kiitossivuusi.

Kuinka pitkä tyypillinen julkistamisen määräaika on?

90 päivää on laajimmin viitattu käytäntö. Google Project Zero antaa toimittajille 90 päivää aikaa julkaista korjaus ja julkaisee yksityiskohdat 30 päivää korjauksen jälkeen, ja määräaika on 7 päivää, kun haavoittuvuutta jo hyödynnetään aktiivisesti. Oma käytäntösi voi asettaa erilaiset ehdot, ja koordinaattorit neuvottelevat tapauskohtaisesti.

Onko koordinoidun haavoittuvuuksien julkistamisen käytäntö pakollinen?

Yhä useammin kyllä. EU:n kyberkestävyyssäädös edellyttää, että digitaalisia elementtejä sisältävien tuotteiden valmistajat ottavat käyttöön CVD-käytännön ja panevat sen täytäntöön sekä antavat yhteysosoitteen ilmoituksille, ja NIS2-direktiivi luettelee haavoittuvuuksien käsittelyn ja julkistamisen pakollisten turvallisuustoimenpiteiden joukossa. Muualla asiakkaat ja hankintasäännöt edellyttävät sitä usein.

Pitääkö minun olla CNA saadakseni CVE-tunnisteen?

Ei. CVE Numbering Authority (CNA) antaa CVE-tunnisteita omalla vastuualueellaan, ja monet toimittajat ryhtyvät CNA:ksi omille tuotteilleen. Jos et ole CNA, tunnisteen voi antaa CNA, jonka vastuualueeseen tuotteesi kuuluu, tai CNA of Last Resort.