VEX ja CSAF: auditointikelpoinen haavoittuvuusnäyttö

Kello 07.40 saapuva tiedote, joka muuttaa SBOMin hallituksen asiaksi

Tiistaiaamuna alkuvuonna 2026 kello 07.40 nopeasti kasvavan FinTech-alustan tietoturvajohtaja Anya näkee kriittisen toimittajatiedotteen saapuvan CSAF-muodossa. Laajasti käytetystä avoimen lähdekoodin kirjastosta on löydetty etäkoodin suorittamisen haavoittuvuus. Hänen Software Bill of Materials -luettelonsa vahvistaa, että kirjasto sisältyy yhtiön lippulaivatuotteeseen, maksujenkäsittelysovellukseen, kahteen sisäiseen palveluun ja ulkoistettuun analytiikkakomponenttiin.

Kello 08.10 hänen puhelimensa soi taukoamatta. Tuotekehitys haluaa tietää, onko haavoittuva toiminto saavutettavissa. Vaatimustenmukaisuustiimi kysyy, liittyykö asia ISO/IEC 27001:2022:een, NIS2:een tai DORA:an. Lakitoiminto kysyy, voiko Cyber Resilience Act edellyttää viestintää asiakkaille tai viranomaisille. Hallituksen jäsen, joka on juuri koulutettu NIS2:n mukaiseen johdon vastuuvelvollisuuteen, esittää kysymyksen, jota kaikki ajattelevat:

Koskeeko tämä meitä?

Tuotekehityksen ensimmäinen vastaus on teknisesti rehellinen: paketti on olemassa, mutta haavoittuvaa toimintoa ei ehkä kutsuta tuotannossa. Vuonna 2026 tämä vastaus ei riitä.

Hallitus haluaa näyttöä. Asiakkaat haluavat selkeän vastauksen. Hankinta haluaa tietää, täyttikö toimittaja sopimusperusteiset julkistamisvelvoitteensa. Tietosuojavastaava haluaa tietää, voisivatko henkilötiedot altistua. ISO 27001 -auditoija ei hyväksy säilytettäväksi näytöksi lausetta ”kehittäjä sanoi niin”. DORA-auditoija odottaa, että haavoittuvuus liitetään ICT-omaisuuseriin, kriittisiin toimintoihin ja kolmansien osapuolten riippuvuuksiin.

Tässä kohtaa VEX ja CSAF lakkaavat olemasta pelkkiä teknisiä formaatteja ja muuttuvat hallintainfrastruktuuriksi.

CSAF, Common Security Advisory Framework, jäsentää haavoittuvuustiedotteet niin, että ihmiset ja koneet voivat käsitellä affected-tuotteita, versioita, korjausohjeita, viitteitä ja tilatietoja. VEX, Vulnerability Exploitability eXchange, tarjoaa päätöskerroksen. Se kertoo sidosryhmille, onko tunnettu haavoittuvuus tosiasiassa hyödynnettävissä tietyssä tuotteessa, palvelussa tai ympäristössä.

Käytännön VEX-tilat ovat yksinkertaisia: affected, not affected, fixed ja under investigation. Niiden taustalla oleva hallinta ei ole yksinkertaista. Jokainen tila tarvitsee näytön, omistajan, perustelun, hyväksynnän ja katselmoinnin käynnistävän tekijän.

Vaatimustenmukaisuuden aukko ei enää ole SBOMien puuttuminen. Monilla organisaatioilla on jo SBOMit. Aukko syntyy siitä, miten organisaatio pystyy osoittamaan, miten kukin haavoittuvuustiedote luokiteltiin, kuka hyväksyi tilapäätöksen, mikä näyttö tuki not affected -päätelmää, miten korjaavat toimenpiteet priorisoitiin, kun tuote oli affected, ja miten organisaatio säilytti tämän jäljen auditoijia, viranomaisia, asiakkaita ja johtoa varten.

Clarysec käsittelee VEXiä ja CSAF:ää osana ISMS:n toimintamallia. Zenith Blueprint: auditoijan 30 askeleen tiekartta sijoittaa tämän riskienhallinnan, toimittajaturvallisuuden, teknisten hallintakeinojen ja näyttövaiheiden alueelle. Zenith Controls: vaatimustenmukaisuuksien välinen opas yhdistää saman aiheen ISO/IEC 27001:2022 -hallintakeinoihin, ICT-toimitusketjun turvallisuuteen, haavoittuvuuksien hallintaan, näytön käsittelyyn sekä NIS2-, DORA-, GDPR- ja NIST-odotuksiin.

Miksi SBOMit tuottavat signaaleja, mutta VEX tuottaa näyttöä

SBOM on ainesosaluettelo. Se kertoo, mitä tuote tai palvelu sisältää. Kun CVE ilmestyy johonkin näistä ainesosista, SBOM kertoo, että asia saattaa koskea sinua.

Tämä signaali on arvokas, mutta se ei ole päätelmä.

Kypsä ohjelmistoympäristö voi tuottaa tuhansia SBOM-haavoittuvuusosumia. Monet niistä ovat todellisia riskejä. Monet eivät ole hyödynnettävissä, koska haavoittuvaa koodia ei toimiteta, sitä ei ladata, se ei ole saavutettavissa, sitä ei ole konfiguroitu, se ei altistu epäluotetulle syötteelle tai riskiä pienennetään korvaavilla kontrolleilla. Ilman muodollista prosessia tutkinnan kirjaamiseksi tiimit ajautuvat yleensä kahteen huonoon toimintamalliin.

Ensimmäinen on luokitteluväsymys. Kehittäjät ja tietoturvatiimit käsittelevät jokaista haavoittuvuusosumaa samalla kiireellisyydellä, vaikka komponentti olisi build-aikainen riippuvuus, passiivinen koodipolku tai vain sisäiseen käyttöön tarkoitettu ominaisuus, jota suojaavat kerrokselliset kontrollit.

Toinen on dokumentoimaton riskin hyväksyminen. Tiimit sulkevat tikettejä lyhyillä kommenteilla, kuten ”ei sovellu” tai ”väärä positiivinen havainto”. Tämä voi tuntua tehokkaalta, mutta auditoijan näkökulmasta kyse on kontrolloimattomasta päätöksestä. Viranomaisen näkökulmasta se voi näyttää hallitsemattomalta haavoittuvuudelta.

VEX ja CSAF ratkaisevat tämän muuttamalla haavoittuvuuskohinan rakenteiseksi, auditointikelpoiseksi haavoittuvuusnäytöksi.

Puolustettavissa oleva VEX- ja CSAF-hallintaprosessi vastaa viiteen kysymykseen:

1. Vastaanotimmeko tai tunnistimmeko tiedotteen?
2. Kartoitimmeko sen tuotteisiin, omaisuuseriin, toimittajiin, asiakkaisiin ja henkilötietovirtoihin?
3. Määritimmekö haavoittuvuuden tilan määriteltyjen kriteerien perusteella?
4. Dokumentoimmeko päätöksen, näytön, omistajan, hyväksynnän ja katselmoinnin käynnistävän tekijän?
5. Toteutimmeko korjaavat toimenpiteet, julkistimmeko tiedon, seurasimmeko tilannetta tai säilytimmekö näytön riskiperusteisesti?

Ero not affected -tilan ja ”ohitettu”-tilan välillä on näyttö.

VEXin not affected -tilan tulee perustua perusteluun, kuten siihen, ettei haavoittuvaa komponenttia ole läsnä, haavoittuva versio ei ole tuotannossa, haavoittuvaa koodipolkua ei suoriteta, haavoittuva konfiguraatio on poistettu käytöstä tai korvaava kontrolli estää hyväksikäytön. Under investigation tarvitsee aikarajoitetun jatkotoimenpiteen eikä saa muuttua backlog-hautausmaaksi. Fixed tulee liittää korjauspäivitykseen, lieventämiseen, versiopäivitykseen, testitulokseen ja käyttöönoton tallenteeseen. Affected tulee ohjata riskien käsittelyyn, korjaussuunnitteluun, toimittajailmoitukseen, asiakasviestintään sekä tarvittaessa poikkeaman tai henkilötietojen tietoturvaloukkauksen arvioinnin työnkulkuihin.

Clarysecin hallintamalli VEX-tilapäätöksille

Jokaista CSAF-tiedotetta ja VEX-lausumaa tulee käsitellä ISMS:n sisäisenä kontrolloituna tallenteena, ei erillisenä tuotekehityksen artefaktina. Työnkulku voi sijaita GRC-alustassa, haavoittuvuuksien hallintatyökalussa, tikettijärjestelmässä, lähdekoodin hallinnan työnkulussa tai Clarysecin näyttötyökirjassa. Olennaista on, että tila, näyttö, hyväksyntä ja riskien käsittely pysyvät linkitettyinä toisiinsa.

Taulukko näyttää yksinkertaiselta, mutta se muuttaa kontrolliympäristöä. Not affected -lausumasta tulee pienimuotoinen riskipäätös tietylle tuotteelle ja ympäristölle. Fixed-tila yhdistää haavoittuvuuksien hallinnan muutoksenhallintaan ja testaukseen. Affected-tila käynnistää käsittelyn, eskaloinnin ja mahdollisen julkistamisen. Under investigation antaa johdolle näkyvän ja aikarajoitetun riskin.

Zenith Blueprint vahvistaa tätä ajattelua vaiheessa 13, joka käsittelee riskienkäsittelysuunnitelmaa ja soveltuvuuslausuntoa. Se selittää, että kontrollipäätökset tulee perustella riskien käsittelyllä, lakisääteisillä tai sopimusperusteisilla vaatimuksilla, soveltamisalan relevanssilla ja organisaation toimintaympäristöllä:

”Merkitse SoA-taulukossa jokainen kontrolli arvolla ‘Kyllä’ (soveltuu) tai ‘Ei’ (ei sovellu). Anna perustelu/muistiinpanot.”

VEXissä not affected noudattaa samaa kurinalaisuutta. Se ei ole satunnainen tiketin sulkeminen. Se on perusteltu päätös, jonka on kestettävä katselmointi.

Zenith Blueprintin vaihe 19 käsittelee teknisten haavoittuvuuksien hallintaa:

”Pysy ajan tasalla uusista tietoturvavirheistä (esim. toimittajahälytykset, CVE-syötteet jne.) ohjelmistojen ja laitteistojen osalta. Arvioi, mitkä ovat relevantteja (käytämmekö tätä ohjelmistoa? kuinka kriittinen virhe on?) ja ota korjaukset tai lieventämistoimet käyttöön viipymättä.”

CSAF auttaa vastaanottamaan rakenteisia tiedotteita. SBOMit auttavat määrittämään komponentin läsnäolon. VEX auttaa dokumentoimaan hyväksikäytettävyyden ja tilan. ISMS hallitsee päätöstä.

Politiikkanäyttö ennen kriittisen tiedotteen saapumista

VEX-ohjelma epäonnistuu, jos ensimmäinen kriittinen tiedote saapuu ennen kuin roolit, kriteerit ja näyttövaatimukset on määritelty. Politiikkojen tulee määrittää etukäteen haavoittuvuuksien vastaanotto, eskalointi, kirjaaminen, toimittajavelvoitteet, poikkeusten käsittely ja näytön säilyttäminen.

Pk-yrityksille Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys määrittää seurantavelvoitteen:

”Valvoo järjestelmiä haavoittuvuuksien ja saatavilla olevien korjauspäivitysten osalta käyttäen toimittajahälytyksiä, uhkatiedustelutiedotteita ja käyttöjärjestelmätason ilmoituksia”

Tämä Roolit ja vastuut -kohdan politiikkalauseke 4.2.1 soveltuu suoraan CSAF-vastaanottoon. CSAF-tiedotteet ovat toimittajan tai ekosysteemin haavoittuvuustiedotteita, joita on seurattava, korreloitava ja luokiteltava.

Sama pk-yrityspolitiikka asettaa odotukset valmiudelle osoittaa vaatimustenmukaisuus:

”Säilytä tarkat tallenteet käyttöön otetuista korjauspäivityksistä, avoimista ongelmista ja poikkeuksista, jotta valmius auditointia varten voidaan varmistaa”

Tavoitteet-kohdan politiikkalausekkeesta 3.4 alkaen VEX muuttuu teknistä tiedostoa laajemmaksi. Jos tiimi ei paikkaa, koska tuote on not affected, kyseinen poikkeus tarvitsee näytön, hyväksynnän ja jäljitettävyyden.

Yritysympäristöissä Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka on täsmällinen:

”Seuraa uhkailmoituksia (esim. CVE, CISA KEV, toimittajien tiedotteet) ja eskaloi kriittiset haavoittuvuudet.”

Roolit ja vastuut -kohdan politiikkalauseke 4.5.1 tukee rakenteista vastaanottokanavaa CSAF:lle, CVE:lle, toimittajien tiedotteille ja hyväksikäyttöä koskevalle tiedustelulle. Se edellyttää myös eskalointia, kun VEX-tila on affected tai under investigation kriittisen tuotteen osalta.

Yrityspolitiikka toteaa myös:

”Kaikki kriittiset ja korkean riskin haavoittuvuudet on kirjattava ISMS:n riskirekisteriin ja niitä on seurattava, kunnes ne on korjattu tai katettu hyväksytyllä poikkeuksella.”

Tämä Hallintavaatimukset-kohdan politiikkalauseke 5.3 on vaatimustenmukaisuuden ankkuri. Kriittistä CVE:tä koskeva VEXin not affected -lausuma on puolustettavissa vain, kun sitä käsitellään hyväksyttynä poikkeuksena, jolla on näyttö. VEXin fixed-lausuma sulkee kehän vain, kun korjaus on varmennettu.

Riskipisteytys tarvitsee myös kontekstia. Sama politiikka viittaa seuraavaan:

”Riskien arviointi (perustuu CVSS-pisteytykseen, omaisuuserän kriittisyyteen ja uhkatiedusteluun)”

Riskienkäsittely ja poikkeukset -kohdan politiikkalauseke 7.2.2 tukee yhdistettyä luokittelumallia. Pelkkä CVSS ei riitä. Keskivakava haavoittuvuus, jota hyödynnetään aktiivisesti kriittisessä identiteettikomponentissa, voi olla kiireellisempi kuin kriittinen CVSS-ongelma koodissa, joka ei ole saavutettavissa.

Sovellusturvallisuus- ja turvallisen kehityksen politiikat laajentavat saman kurinalaisuuden tuotekehitykseen ja toimittajiin. Sovellusturvallisuusvaatimusten politiikka - pk-yritys edellyttää tiimeiltä seuraavien seuraamista:

”tunnetut haavoittuvuudet ja korjaavien toimenpiteiden tila.”

Politiikan toteutusvaatimukset -kohdan politiikkalauseke 6.4.2.3 liittyy suoraan VEX-tiloihin. Sama politiikka edellyttää sopimuksilta, että niissä:

”määritetään velvoitteet haavoittuvuuksien julkistamiselle, vasteajoille ja paikkaamiselle.”

Hallintavaatimukset-kohdan politiikkalausekkeesta 5.3.2 muodostuu käytännön toimittajalauseke: toimita tiedotteet oikea-aikaisesti, tunnista affected-versiot, anna VEX-tila mahdollisuuksien mukaan, määritä korjausaikataulut ja tue asiakkaan julkistamista.

Yritystason turvallisessa kehityksessä Turvallisen kehityksen politiikka edellyttää seuraavaa:

”Tunnettujen haavoittuvuuksien skannaus (CVE:t, OSS Index jne.)”

Hallintavaatimukset-kohdan politiikkalauseke 5.4.3 antaa tuotekehitykselle määritellyn mekanismin tiedotteiden yhdistämiseksi komponentteihin ja VEX-analyysin käynnistämiseksi.

Kun haavoittuvuudesta tulee poikkeama tai mahdollinen oikeudellinen asia, näytön käsittelyn kurinalaisuus on välttämätöntä. Todisteiden keräämisen ja forensiikan politiikka - pk-yritys toteaa:

”Jokaisesta poikkeamasta on ylläpidettävä yksinkertaista hallussapitoketjulokia (esim. Excel-tiedosto tai asiakirjapohja).”

Hallintavaatimukset-kohdan politiikkalauseke 5.3.1 muodostaa rajan rutiininomaisen VEX-luokittelun ja poikkeamatasoisen näytön käsittelyn välille. Jos hyväksikäyttöä epäillään, lokit, tiedotetallenteet, analyysimuistiinpanot, viestintä ja forensiset artefaktit tarvitsevat jäljitettävyyden.

VEXin ja CSAF:n kytkeminen ISO 27001:een, NIS2:een, DORA:an, GDPR:ään ja CRA:han

Vahvimmat VEX-ohjelmat eivät ole erillisiä tietoturva- tai tuotekehityshankkeita. Ne kytketään siihen kontrollijärjestelmään, jota organisaatio jo käyttää.

ISO/IEC 27001:2022 -standardin mukaisesti ISMS:n on huomioitava sidosryhmät, lakisääteiset ja sopimusperusteiset velvoitteet sekä rajapinnat ja riippuvuudet muiden organisaatioiden kanssa. Tämä soveltamisalalogiikka on VEXille olennainen, koska toimittajatiedotteet, asiakassitoumukset, avoimen lähdekoodin komponentit ja ulkoistetut palvelut vaikuttavat kaikki haavoittuvuuspäätöksiin.

Keskeisimpiä liite A:n hallintakeinoja ovat 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services, 5.28 Collection of evidence ja 8.8 Management of technical vulnerabilities. Turvallisen kehityksen hallintakeinot 8.25–8.29 ovat myös relevantteja silloin, kun organisaatio rakentaa ohjelmistoja tai digitaalisia tuotteita.

NIS2 lisää hallintapainetta. Article 21 edellyttää asianmukaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta, kehittäminen ja ylläpito, haavoittuvuuksien käsittely ja julkistaminen, kontrollien tehokkuus, kyberhygienia, kryptografia, HR-turvallisuus, pääsynhallinta, omaisuudenhallinta ja todennus. Article 20 edellyttää, että hallintoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niitä. Tämä tekee VEX-mittareista sopivia hallitusraportointiin.

DORA:aa sovelletaan soveltamisalaan kuuluviin finanssialan toimijoihin 17. tammikuuta 2025 alkaen. Se edellyttää ICT-riskien hallinnan viitekehystä, ICT-omaisuuserien, haavoittuvuuksien, riippuvuuksien ja ICT-kolmansien osapuolten palvelujen tunnistamista ja luokittelua, poikkeamien hallintaa, häiriönsietokyvyn testausta, kolmansien osapuolten riskienhallintaa ja johdon valvontaa. Finanssialan toimijoille VEX-tallenteet ovat erityisen hyödyllisiä, kun toimittajatiedote on kytkettävä kriittisiin tai tärkeisiin toimintoihin, sopimusvelvoitteisiin ja poikkeamaluokitteluun.

GDPR tulee mukaan, kun hyväksikäyttö voisi vaikuttaa henkilötietoihin. Haavoittuva ohjelmointirajapinta, kirjasto tai palvelu, joka voisi paljastaa asiakastietueita, edellyttää arviointia luottamuksellisuuden, eheyden, saatavuuden ja loukkauksista ilmoittamisen kriteerien perusteella. VEXin not affected -päätelmä voi tukea päätöstä olla ilmoittamatta, mutta vain, jos organisaatio pystyy osoittamaan, miksi henkilötietojen tietoturvaloukkausta ei tapahtunut.

Cyber Resilience Act lisää tuotehallinnan vaatimuksia. Kun CRA-velvoitteet tulevat vaiheittain voimaan, valmistajat ja muut talouden toimijat tarvitsevat toistettavat prosessit haavoittuvuuksien käsittelyyn, tietoturvapäivityksiin, koordinoituun julkistamiseen ja näyttöön. CSAF voi jäsentää tiedotteet. VEX voi selkeyttää, mitkä tuotteet ja versiot ovat affected, fixed tai not affected.

Mitä Clarysecin vaatimustenmukaisuuksien välinen opas lisää

Zenith Controls on arvokas, koska se yhdistää teknisen työn auditointiodotuksiin ja päällekkäisiin viitekehyksiin. VEXin ja CSAF:n kannalta kolme aluetta ovat tärkeimpiä: ICT-toimitusketjun turvallisuus, teknisten haavoittuvuuksien hallinta ja näytön kerääminen.

ICT-toimitusketjun turvallisuuden osalta Zenith Controls tunnistaa ISO/IEC 27002:2022 -standardin hallintakeinon 5.21 nimellä ”Managing information security in the ICT supply chain.” Se selittää, että 5.21 laajentaa toimittajasuhteiden hallintakeinot 5.19 ja 5.20 ICT-kohtaisiin riskeihin, mukaan lukien turvattomat ohjelmistokomponentit sekä kolmannen osapuolen tai avoimen lähdekoodin kirjastot. Se liittyy turvalliseen suunnitteluun, turvalliseen ohjelmointiin, tietoturvatestaukseen, pääsynhallintaan, näytön keräämiseen, turvallisen kehityksen elinkaareen ja ulkoistettuun kehittämiseen.

Tämä on juuri se alue, jolla CSAF ja VEX toimivat. Toimittajatiedote ei ole vain viesti toimittajalta. Se on näyttö toimittajan kyberturvallisuuskäytännöstä. Toimittajan VEX-lausuma ei ole vain käytännön apu. Se voi tukea hankintaa, asianmukaista huolellisuutta, seurantaa ja asiakkaan riskipäätöksiä.

Teknisten haavoittuvuuksien hallinnan osalta Zenith Controls tunnistaa hallintakeinon 8.8 nimellä ”Management of Technical Vulnerabilities.” Se luokittelee hallintakeinon ennaltaehkäiseväksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi sekä uhka- ja haavoittuvuuksien hallintaan liittyväksi. Se huomauttaa myös, että haavoittuvuuksien hallinta liittyy haittaohjelmasuojaukseen, konfiguraationhallintaan, muutoksenhallintaan, uhkatiedusteluun ja seurantaan.

Erityisen hyödyllinen Zenith Controls -kohta VEX-hallintaan on:

”Tehokas haavoittuvuuksien hallinta priorisoi todellisten uhkien perusteella. Uhkatiedustelu kertoo, mitä haavoittuvuuksia hyödynnetään aktiivisesti, ja ohjaa korjauspäivitysten priorisointia.”

Tämä on ero raakojen SBOM-osumien ja riskiperusteisen VEX-luokittelun välillä. Pelkkä läsnäolo ei riitä. Hyväksikäytettävyys, omaisuuserän kriittisyys, altistuminen ja uhkatoiminta on huomioitava päätöksessä.

Näytön osalta Zenith Controls tunnistaa hallintakeinon 5.28, ”Collection of evidence,” korjaavaksi ja havaitsemiseen sekä reagointiin liittyväksi. Se yhdistää 5.28:n tietoturvapoikkeamiin reagointiin, lokitukseen, seurantaan ja tapahtumaraportointiin. Se kytkee näytön käsittelyn myös ISO/IEC 27037:2012 -standardiin digitaalisen todistusaineiston tunnistamisen, keräämisen, hankinnan ja säilyttämisen osalta.

Kun haavoittuvuus on vain teoreettinen, rutiininomaiset VEX-tallenteet voivat riittää. Kun hyväksikäyttöä epäillään, organisaation on siirryttävä poikkeamatason näytön käsittelyyn. Lokit, toimittajaviestintä, asiakastiedotteet, korjauspäivitystallenteet ja forensiset artefaktit tarvitsevat eheyden, säilyttämisen ja jäljitettävyyden.

Käytännön VEX-näyttöpaketti hälytyksestä sulkemiseen

Palataan Anyan FinTech-alustaan. CSAF-tiedote saapuu kriittisestä haavoittuvuudesta komponentissa lib-common-utils, joka näkyy maksuyhdyskäytävän SBOMissa. Kurinalainen reagointi loisi yhden näyttöpaketin, ei hajanaisia Slack-viestejä ja kuvakaappauksia.

Vaihe 1: Luo tiedotteen vastaanottotallenne

Avaa haavoittuvuustapaus ISMS:n näyttöseurannassa. Liitä CSAF-tiedote, CVE-viite, toimittajatiedote, SBOM-osuma ja affected-omaisuuserien luettelo. Nimeä haavoittuvuuden omistaja ja liiketoimintajärjestelmän omistaja. Kytke maksupalvelu asiakasvaikutukseen, henkilötietoihin, maksuliikenteeseen ja operatiiviseen kriittisyyteen.

Politiikkaperusta: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka edellyttää tiedotteiden seurantaa ja kriittisten haavoittuvuuksien eskalointia. ISO-perusta: liite A:n hallintakeino 8.8. NIS2-perusta: haavoittuvuuksien käsittely ja turvallinen ylläpito. DORA-perusta: ICT-haavoittuvuuksien tunnistaminen ja poikkeamavalmius.

Vaihe 2: Aseta alustavaksi tilaksi under investigation

Alustavan tilan tulisi usein olla under investigation, erityisesti kriittisten tiedotteiden osalta. Aseta päätöksen määräaika, esimerkiksi 24 tuntia ulkoisesti altistuville tai kriittisille palveluille. Kirjaa väliaikaiset kontrollit, kuten tehostettu valvonta, tilapäiset ominaisuusrajoitukset tai WAF-säännöt. Tämä estää kriittistä tiedotetta katoamasta hallitsemattomaan backlogiin.

Vaihe 3: Tee hyväksikäytettävyyden analyysi

Tuotekehityksen tulee vastata käytännön kysymyksiin:

• Onko haavoittuva versio läsnä tuotannossa?
• Onko haavoittuva toiminto ladattu, kutsuttu tai saavutettavissa?
• Onko haavoittuva konfiguraatio käytössä?
• Altistuuko komponentti epäluotetulle syötteelle?
• Edellytetäänkö todennusta ennen kuin haavoittuva polku voidaan saavuttaa?
• Ovatko korvaavat kontrollit tehokkaita?
• Onko aktiivista hyväksikäyttöä tai uskottavaa uhkatiedustelua?
• Voisiko hyväksikäyttö vaikuttaa henkilötietoihin, maksutapahtumiin tai palvelun saatavuuteen?

Anyan tapauksessa staattinen analyysi vahvistaa, että komponentti on läsnä, mutta maksuyhdyskäytävä ei kutsu haavoittuvaa toimintoa. Tuotannossa ei ole suorituspolkua. Tiimi valmistelee not affected -VEX-lausuman sitä tukevalla näytöllä.

Jos analyysi olisi osoittanut, että todennettu ylläpitäjäajo voisi saavuttaa haavoittuvan toiminnon, oikea tila olisi affected, ei not affected. Tiimi loisi tällöin riskienkäsittelysuunnitelman, avaisi muutostiketin, paikkaisi tai lieventäisi haavoittuvuuden ja päivittäisi tilaksi fixed vasta varmennuksen jälkeen.

Vaihe 4: Kytke tapaus riskirekisteriin ja toimittajatallenteeseen

Kriittiset ja korkean riskin tapaukset tulee kirjata ISMS:n riskirekisteriin, ellei niitä suljeta hyväksytyllä, näyttöön perustuvalla poikkeuksella. Toimittajatiedotteet tulee myös linkittää toimittajarekisteriin, sopimusvelvoitteisiin ja seurantatallenteisiin.

Tämä tukee Zenith Blueprintin vaihetta 23, jossa organisaatioita ohjeistetaan kokoamaan toimittajat, luokittelemaan ne pääsyn ja operatiivisen kontrollin perusteella, sisällyttämään tietoturvaodotukset sopimuksiin ja määrittämään seurantamenettelyt toimittajamuutoksille.

Vaihe 5: Validoi korjaus tai hyväksy poikkeus

Fixed-tilaa varten liitä korjauspäivitysversio, muutostallenne, CI/CD-putken tulos, riippuvuusskannaus, kontti-levykuvan digest, käyttöönottonäyttö ja regressiotesti. Not affected -tilaa varten liitä koodipolkuanalyysi, konfiguraationäyttö, versionäyttö, korvaavan kontrollin näyttö ja hyväksyntä.

Jos asiakkaat käyttävät itse ylläpidettyjä versioita tai haavoittuvuus voisi vaikuttaa ulkoisiin käyttäjiin, viestintä on koordinoitava. Haavoittuvuuksien koordinoidun julkistamisen politiikka tarjoaa mallin:

”Kun vahvistettu haavoittuvuus voisi vaikuttaa asiakkaisiin tai palvelun käyttäjiin, viestintätiimin on VRT:n ohjauksessa laadittava tietoturvatiedote. Tiedotteen on sisällettävä yleiskuvaus asiasta ilman hyväksikäyttömenetelmän yksityiskohtien paljastamista, affected-tuotteet tai -versiot, lieventämisohjeet tai korjauspäivityksen latausohjeet sekä tukiyhteystiedot.”

Toteutusvaatimukset-kohdan politiikkalauseke 6.8 vastaa suoraan CSAF-julkaisun kurinalaisuutta.

Vaihe 6: Säilytä näyttö, jos hyväksikäyttöä epäillään

Jos lokit osoittavat hyväksikäyttöyrityksiä, siirry haavoittuvuuksien käsittelystä tietoturvapoikkeamiin reagointiin ja näytön keräämiseen. Aloita hallussapitoketjuloki, säilytä lokit, kirjaa SIEM-kyselyt, vie relevantit tapahtumat, ota tarvittaessa tilannevedokset affected-järjestelmistä ja dokumentoi, kuka käsitteli kutakin artefaktia. Linkitä poikkeamatapaus VEX-tallenteeseen.

Mitä auditoijat ja viranomaiset kysyvät

Auditoijat eivät testaa VEX- ja CSAF-hallintaa kaikki samalla tavalla. Yhden näyttöpaketin tulisi täyttää useiden näkökulmien tarpeet.

Zenith Controls sisältää auditointimenetelmäohjeistusta, joka sopii tähän taulukkoon. ICT-toimitusketjun turvallisuuden osalta ISO/IEC 19011- ja ISO/IEC 27007 -standardeja käyttävät auditoijat tutkivat hankintapolitiikkoja, RFP-pohjia ja toimittajahallinnan prosesseja varmistaakseen ICT-kohtaiset tietoturvavaatimukset. He poimivat sopimuksista otoksia turvallisen kehityksen, haavoittuvuuksien julkistamisen ja ohjelmiston aitouden lausekkeista.

Teknisten haavoittuvuuksien hallinnan osalta auditoijat katselmoivat haavoittuvuuksien hallintapolitiikan, skannaustiheyden, omaisuuseräkattavuuden, riskiperusteisen priorisoinnin, korjausaikataulut ja vastuut. Näytön keräämisen osalta he testaavat, noudatettiinko todellisissa poikkeamissa hallussapitoketjua, turvallista säilytystä ja säilytysaikoja.

Siksi VEX-hallinta ei saa koskaan päättyä tilatunnisteeseen. Tunniste on yhteenveto. Näyttöketju on kontrolli.

Johdon mittarit, jotka tekevät VEXistä hallituskelpoisen

ISO/IEC 27001:2022 edellyttää suorituskyvyn arviointia, sisäistä tarkastusta ja johdon katselmointia. NIS2 edellyttää johdon valvontaa. DORA edellyttää ICT-riskien hallintaa. VEX ja CSAF luovat mittareita, jotka muuttavat tuotekehityksen työn johdon riskinäkyvyydeksi.

Hyödyllisiä johdon katselmointimittareita ovat:

• Tällä vuosineljänneksellä vastaanotettujen kriittisten CSAF-tiedotteiden määrä
• SBOM-komponentteihin täsmäytettyjen osuus
• VEX-tilojen määrä ja ikä tiloittain: affected, not affected, fixed ja under investigation
• Erääntyneet under investigation -tapaukset
• Toimittajatiedotteet, joissa ei ole riittäviä affected-versiotietoja
• Hyväksyttyinä poikkeuksina hyväksytyt kriittiset haavoittuvuudet
• Aika tiedotteen vastaanotosta VEX-päätökseen
• Aika affected-päätöksestä korjaaviin toimenpiteisiin
• Tapausten määrä, joissa on mahdollinen vaikutus henkilötietoihin
• Julkaistujen asiakastiedotteiden määrä

Nämä mittarit auttavat johtoa esittämään parempia kysymyksiä. Mitkä toimittajat eivät toimita käyttökelpoisia haavoittuvuustietoja? Millä tuotteilla on pisimmät korjausajat? Mitkä tiimit jättävät tutkimukset avoimiksi? Mitkä haavoittuvuudet voivat vaikuttaa henkilötietoihin tai kriittisiin toimintoihin?

Yleiset poistettavat epäonnistumismallit

Ensimmäinen epäonnistuminen on SBOM-osuman käsittely hyväksikäytettävyyden analyysina. Komponenttiosuma on signaali, ei päätelmä.

Toinen epäonnistuminen on not affected -tilan käyttäminen ilman perustelua. Auditoijat kysyvät miksi. Oliko koodipolku saavuttamaton? Oliko haavoittuva ominaisuus poistettu käytöstä? Oliko versio eri? Käytettiinkö komponenttia vain build-aikana? Hyväksyikö tuoteturvallisuus päätelmän?

Kolmas epäonnistuminen on under investigation -tilan jättäminen avoimeksi. Tämä tila on hyödyllinen vain, jos sillä on omistaja, määräaika ja väliaikaiset kontrollit.

Neljäs epäonnistuminen on toimittajahallinnan erottaminen haavoittuvuuksien hallinnasta. Toimittajasopimusten tulee edellyttää oikea-aikaista haavoittuvuuksien julkistamista, vasteaikoja, paikkausvelvoitteita, tiedotteen sisältöä ja näyttötukea.

Viides epäonnistuminen on henkilötietojen ja asiakasviestinnän sivuuttaminen. Haavoittuvuus, joka voisi paljastaa henkilötietoja, tarvitsee GDPR-arvioinnin. Vahvistettu tuotehaavoittuvuus, joka voisi vaikuttaa asiakkaisiin, tarvitsee koordinoidun julkistamisen kurinalaisuuden. Finanssipalvelun riippuvuus voi edellyttää DORA-poikkeama-analyysiä.

Kuudes epäonnistuminen on heikko näytön säilyttäminen. Zenith Blueprint varoittaa vaiheessa 23, hallintakeino 5.28, että näyttö jätetään usein huomiotta:

”se, mitä pystyt osoittamaan, on yhtä tärkeää kuin se, mitä tosiasiallisesti tapahtui”

Tämä lause kiteyttää vuoden 2026 todellisuuden. Tietoturvatiimit eivät ainoastaan korjaa haavoittuvuuksia. Ne osoittavat, että päätökset olivat oikea-aikaisia, riskiperusteisia ja kontrolloituja.

Seuraavat askeleet auditointikelpoiseen haavoittuvuusnäyttöön

Jos organisaatiollasi on jo SBOMit, seuraava kypsyysaskel ei ole uusi inventaariolaskentataulukko. Se on haavoittuvuustilojen, toimittajatiedotteiden ja julkistamisnäytön hallinta.

Aloita neljällä toimenpiteellä:

1. Lisää CSAF- ja VEX-vastaanotto haavoittuvuuksien hallintamenettelyyn.
2. Määritä hyväksymiskriteerit tiloille affected, not affected, fixed ja under investigation.
3. Linkitä VEX-tallenteet ISMS:n riskirekisteriin, toimittajarekisteriin, omaisuusluetteloon, SBOM-tietovarastoon ja poikkeamaprosessiin.
4. Testaa prosessi yhdellä tuoreella kriittisellä tiedotteella ja tuota auditointivalmis näyttöpaketti.

Clarysec voi auttaa tämän nopeassa toteutuksessa hyödyntämällä Zenith Blueprint- ja Zenith Controls -ratkaisuja sekä relevanttia politiikkakokonaisuutta, mukaan lukien Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys, Sovellusturvallisuusvaatimusten politiikka - pk-yritys, Turvallisen kehityksen politiikka, Todisteiden keräämisen ja forensiikan politiikka - pk-yritys ja Haavoittuvuuksien koordinoidun julkistamisen politiikka.

Vuoden 2026 ratkaiseva kysymys ei ole ”Onko meillä SBOM?” vaan ”Pystymmekö osoittamaan jokaisen vakavan tiedotteen osalta täsmällisesti, miten määritimme haavoittuvuuden tilan, käsittelimme riskin ja viestimme tuloksen?”

Varaa Clarysec-arviointi tai pyydä relevantti politiikkatyökalupaketti, jotta VEX ja CSAF voidaan muuttaa auditointivalmiiksi haavoittuvuusnäytöksi ennen kuin seuraava kriittinen tiedote päätyy hallituksen käsiteltäväksi.