VEX ja CSAF: auditikõlblik haavatavuste tõendusmaterjal

Kell 07.40 saabuv turvateade, mis muudab SBOM-i juhatuse probleemiks

2026. aasta alguse teisipäeva hommikul kell 07.40 näeb kiiresti kasvava fintech-platvormi infoturbejuht Anya, et kriitilise tarnija turvateade saabub CSAF-vormingus. Laialdaselt kasutatavas avatud lähtekoodiga teegis on avastatud koodi kaugkäivitamise haavatavus. Tema tarkvara komponentide loend (SBOM) kinnitab, et teek on põimitud põhilisse maksetöötluse rakendusse, kahte siseteenusesse ja allhanke korras kasutatavasse analüütikakomponenti.

Kell 08.10 hakkab tema telefon helisema. Inseneritiim tahab teada, kas haavatav funktsioon on kättesaadav. Vastavusüksus tahab teada, kas see puudutab ISO/IEC 27001:2022, NIS2 või DORA nõudeid. Õigusosakond küsib, kas Cyber Resilience Act võib nõuda suhtlust klientide või ametiasutustega. Juhatuse liige, kes on äsja läbinud NIS2 juhtkonna vastutuse koolituse, esitab küsimuse, millele kõik mõtlevad:

Kas see mõjutab meid?

Inseneritiimi esimene vastus on tehniliselt aus: pakett on olemas, kuid haavatavat funktsiooni ei pruugita tootmiskeskkonnas kutsuda. 2026. aastal ei ole selline vastus piisav.

Juhatus tahab tõendeid. Kliendid tahavad selget vastust. Hankeüksus tahab teada, kas tarnija täitis lepingulised avalikustamiskohustused. Andmekaitseametnik tahab teada, kas isikuandmed võisid sattuda ohtu. ISO 27001 audiitor ei aktsepteeri säilitatava audititõendina väidet „arendaja ütles nii”. DORA audiitor eeldab, et haavatavus seotakse IKT-varade, kriitiliste funktsioonide ja kolmandate osapoolte sõltuvustega.

Siin lakkavad VEX ja CSAF olemast pelgalt tehnilised vormingud ning muutuvad juhtimistaristuks.

CSAF ehk Common Security Advisory Framework struktureerib haavatavuste turvateated nii, et inimesed ja masinad saavad töödelda mõjutatud tooteid, versioone, parandusjuhiseid, viiteid ja staatuse teavet. VEX ehk Vulnerability Exploitability eXchange annab otsustuskihi. See ütleb sidusrühmadele, kas teadaolev haavatavus on konkreetses tootes, teenuses või keskkonnas tegelikult ärakasutatav.

Praktilised VEX-i staatuse tulemused on lihtsad: mõjutatud, ei mõjuta, parandatud ja uurimisel. Nende taga olev juhtimine ei ole lihtne. Iga staatus vajab tõendusmaterjali, omanikku, põhjendust, heakskiitu ja läbivaatamise alust.

Vastavuslünk ei seisne enam SBOM-ide puudumises. Paljudel organisatsioonidel on nüüd SBOM-id olemas. Lünk seisneb selles, kuidas tõendada, kuidas iga haavatavuse turvateade triaažiti, kes staatuse otsuse heaks kiitis, milline tõendusmaterjal toetas järeldust „ei mõjuta”, kuidas prioriseeriti parandamine juhul, kui toode oli „mõjutatud”, ja kuidas organisatsioon säilitas selle auditijälje audiitorite, regulaatorite, klientide ja juhtkonna jaoks.

Clarysec käsitleb VEX-i ja CSAF-i ISMS-i tegevusmudeli osana. Zenith Blueprint: audiitori 30-sammuline teekaart paigutab selle riskijuhtimise, tarnijate turbe, tehniliste kontrollimeetmete ja tõendusmaterjali etappidesse. Zenith Controls: ristvastavuse juhend seob sama teema ISO/IEC 27001:2022 kontrollimeetmed IKT tarneahela turbe, haavatavuste halduse, tõendusmaterjali käitlemise ning NIS2, DORA, GDPR ja NIST ootustega.

Miks SBOM-id loovad signaale, kuid VEX loob tõendusmaterjali

SBOM on koostisosade loend. See ütleb, mis on toote või teenuse sees. Kui mõnes neist koostisosadest ilmneb CVE, ütleb SBOM, et võite olla mõjutatud.

See signaal on väärtuslik, kuid see ei ole järeldus.

Küps tarkvarakeskkond võib genereerida tuhandeid SBOM-i haavatavuse vasteid. Paljud neist on tegelikud riskid. Paljud ei ole ärakasutatavad, sest haavatavat koodi ei tarnita, ei impordita, see ei ole kättesaadav, ei ole konfigureeritud, ei ole avatud mitteusaldusväärsele sisendile või on maandatud kompenseerivate kontrollimeetmetega. Kui uurimise kirjendamiseks puudub ametlik protsess, satuvad meeskonnad tavaliselt ühte kahest halvast mustrist.

Esimene on triaaživäsimus. Insenerid jälitavad iga haavatavuse vastet võrdse kiireloomulisusega isegi siis, kui komponent on ehitusaegne sõltuvus, kasutamata kooditee või ainult sisekasutuseks mõeldud funktsioon, mida kaitsevad mitmekihilised kontrollimeetmed.

Teine on dokumenteerimata riski aktsepteerimine. Meeskonnad sulgevad piletid lühikeste kommentaaridega nagu „ei kohaldu” või „valepositiivne”. See võib tunduda tõhus, kuid audiitori jaoks on see kontrollimata otsus. Regulaatori jaoks võib see näida juhtimata haavatavusena.

VEX ja CSAF lahendavad selle, muutes haavatavuste müra struktureeritud, auditikõlblikuks haavatavuste tõendusmaterjaliks.

Kaitstav VEX-i ja CSAF-i juhtimisprotsess vastab viiele küsimusele:

1. Kas saime turvateate kätte või tuvastasime selle?
2. Kas vastendasime selle toodete, varade, tarnijate, klientide ja isikuandmete voogudega?
3. Kas määrasime haavatavuse staatuse määratletud kriteeriumide alusel?
4. Kas dokumenteerisime otsuse, tõendusmaterjali, omaniku, heakskiidu ja läbivaatamise aluse?
5. Kas parandasime, avalikustasime, seirasime või säilitasime tõendusmaterjali riski alusel?

Erinevus „ei mõjuta” ja „ignoreeritud” vahel on tõendusmaterjal.

VEX-i „ei mõjuta” staatust peab toetama põhjendus, näiteks et haavatav komponent puudub, haavatavat versiooni ei ole juurutatud, haavatavat kooditeed ei käivitata, haavatav konfiguratsioon on keelatud või kompenseeriv kontrollimeede takistab ärakasutamist. „Uurimisel” peab sisaldama ajaliselt piiratud järeltegevust, mitte muutuma tööjärjekorra surnuaiaks. „Parandatud” peab viitama paigale, leevendusele, versiooniuuendusele, testitulemusele ja juurutuskirjele. „Mõjutatud” peab sisenema riskikäsitluse, paranduste planeerimise, tarnija teavitamise, kliendisuhtluse ning vajaduse korral intsidendi või rikkumise hindamise töövoogudesse.

Claryseci juhtimismudel VEX-i staatuse otsuste jaoks

Iga CSAF-turvateadet ja VEX-avaldust tuleb käsitleda ISMS-is kontrollitud kirjena, mitte eraldiseisva inseneriartefaktina. Töövoog võib asuda GRC-platvormis, haavatavuste halduse tööriistas, piletihaldussüsteemis, lähtekoodi halduse töövoos või Claryseci tõendusmaterjali töövihikus. Oluline on, et staatus, tõendusmaterjal, heakskiit ja riskikäsitlus jääksid omavahel seotuks.

See tabel näib lihtne, kuid muudab kontrollikeskkonda. „Ei mõjuta” avaldus muutub konkreetse toote ja keskkonna väikeseks riskiotsuseks. „Parandatud” staatus seob haavatavuste halduse muudatuste juhtimise ja testimisega. „Mõjutatud” staatus käivitab käsitluse, eskaleerimise ja võimaliku avalikustamise. „Uurimisel” staatus annab juhtkonnale nähtava, ajaliselt piiratud riski.

Zenith Blueprint kinnistab seda mõtteviisi 13. sammus, mis käsitleb riski käsitlemise planeerimist ja kohaldatavusdeklaratsiooni. See selgitab, et kontrollimeetmete otsused peavad olema põhjendatud riskikäsitluse, õiguslike või lepinguliste nõuete, kohaldamisala asjakohasuse ja organisatsiooni kontekstiga:

„Märkige SoA-lehel iga kontrollimeede kui „Jah” (kohaldatav) või „Ei” (mittekohaldatav). Lisage põhjendus/märkused.”

VEX-i puhul järgib „ei mõjuta” sama distsipliini. See ei ole juhuslik pileti sulgemine. See on põhjendatud otsus, mis peab läbivaatamisel vastu pidama.

Zenith Blueprint 19. samm käsitleb tehniliste haavatavuste haldust:

„Hoidke end kursis oma tarkvara ja riistvara uute turvavigadega (tarnijate teavituste, CVE-voogude jne kaudu). Hinnake, millised neist on asjakohased (kas kasutame seda tarkvara? kui kriitiline on viga?) ning rakendage viivitamata parandused või leevendusmeetmed.”

CSAF aitab vastu võtta struktureeritud turvateateid. SBOM-id aitavad määrata komponendi olemasolu. VEX aitab dokumenteerida ärakasutatavust ja staatust. Otsust juhib ISMS.

Poliitikatõendid enne kriitilise turvateate saabumist

VEX-programm ebaõnnestub, kui esimene kriitiline turvateade saabub enne, kui rollid, kriteeriumid ja tõendusmaterjali nõuded on olemas. Poliitikad peavad juba määratlema haavatavuste vastuvõtu, eskaleerimise, kirjendamise, tarnijate kohustused, erandite käsitlemise ja tõendusmaterjali säilitamise.

VKE-de jaoks kehtestab Haavatavuste ja paikade halduse poliitika – VKE seirekohustuse:

„Seirab süsteeme haavatavuste ja saadaolevate paikade suhtes, kasutades tarnijate teavitusi, ohuteabe teateid ja operatsioonisüsteemi teavitusi”

See klausel rollide ja vastutuste jaotisest, poliitika punkt 4.2.1, kohaldub otse CSAF-i vastuvõtule. CSAF-turvateated on tarnija või ökosüsteemi haavatavuste turvateated, mida tuleb seirata, korreleerida ja triaažida.

Sama VKE poliitika määrab auditivalmiduse ootused:

„Säilitage täpsed kirjed rakendatud paikade, lahendamata probleemide ja erandite kohta, et tagada auditiks valmisolek”

Eesmärkide jaotisest, poliitika punkt 3.4, algab siin VEX-i roll enam kui tehnilise failina. Kui meeskond ei paika, sest toode on „ei mõjuta” staatuses, vajab see erand tõendusmaterjali, heakskiitu ja jälgitavust.

Ettevõtte keskkondade jaoks on Haavatavuste ja paikade halduse poliitika selgesõnaline:

„Seirake ohuteateid (nt CVE, CISA KEV, tarnijate turvateated) ja eskaleerige kriitilised haavatavused.”

Rollide ja vastutuste jaotisest, poliitika punkt 4.5.1, toetab see klausel struktureeritud vastuvõtukanalit CSAF-i, CVE, tarnijate turvateadete ja ärakasutusteabe jaoks. Samuti nõuab see eskaleerimist, kui VEX-i staatus on kriitilise toote puhul „mõjutatud” või „uurimisel”.

Ettevõtte poliitika sätestab ka:

„Kõik kriitilised ja kõrge riskiga haavatavused tuleb kanda ISMS-i riskiregistrisse ning neid tuleb jälgida kuni kõrvaldamiseni või kuni need on kaetud heakskiidetud erandiga.”

See klausel juhtimisnõuete jaotisest, poliitika punkt 5.3, on vastavuse ankur. VEX-i „ei mõjuta” avaldus kriitilise CVE kohta on kaitstav ainult siis, kui seda käsitletakse tõendusmaterjaliga heakskiidetud erandina. VEX-i „parandatud” avaldus sulgeb tsükli ainult siis, kui parandamine on verifitseeritud.

Riskiskoorimine vajab samuti konteksti. Sama poliitika viitab järgmisele:

„Riskihindamine (CVSS-i, vara kriitilisuse ja ohuteabe alusel)”

Riskikäsitluse ja erandite jaotisest, poliitika punkt 7.2.2, toetab see kombineeritud triaažimudelit. CVSS üksi ei ole piisav. Keskmise tõsidusega haavatavus, mida aktiivselt kasutatakse ära kriitilises identiteedikomponendis, võib olla kiireloomulisem kui kriitilise CVSS-hindega probleem kättesaamatus koodis.

Rakenduste ja turvalise arenduse poliitikad laiendavad sama distsipliini inseneritöösse ja tarnijatele. Rakendusturbe nõuete poliitika – VKE nõuab meeskondadelt järgmise jälgimist:

„teadaolevad haavatavused ja parandamise staatus.”

Poliitika rakendamise nõuete jaotisest, poliitika punkt 6.4.2.3, vastendub see selgelt VEX-i staatustega. Sama poliitika nõuab, et kokkulepped:

„määraksid kindlaks kohustused haavatavuste avalikustamiseks, reageerimisajad ja paikamise.”

Juhtimisnõuete jaotisest, poliitika punkt 5.3.2, muutub see praktiliseks tarnijaklausliks: esitage õigeaegsed turvateated, tuvastage mõjutatud versioonid, väljastage võimaluse korral VEX-i staatus, määrake parandusajad ja toetage kliendi avalikustamist.

Ettevõtte turvalise arenduse puhul eeldab Turvalise arenduse poliitika:

„Teadaolevate haavatavuste skannimine (CVE-d, OSS Index jne)”

Juhtimisnõuete jaotisest, poliitika punkt 5.4.3, annab see inseneritiimile määratletud mehhanismi turvateadete komponentidega vastendamiseks ja VEX-analüüsi käivitamiseks.

Kui haavatavusest saab intsident või potentsiaalne õiguslik küsimus, muutub tõendusmaterjali distsipliin hädavajalikuks. Tõendite kogumise ja kohtuekspertiisi poliitika – VKE sätestab:

„Iga intsidendi kohta tuleb pidada lihtsat tõendite valduse ahela logi (nt Exceli fail või mallidokument).”

Juhtimisnõuete jaotisest, poliitika punkt 5.3.1, on see piir rutiinse VEX-triaaži ja intsidenditaseme tõendusmaterjali käitlemise vahel. Kui kahtlustatakse ärakasutamist, vajavad logid, turvateadete kirjed, analüüsimärkmed, suhtlus ja kohtuekspertiisi artefaktid jälgitavust.

VEX-i ja CSAF-i vastendamine ISO 27001, NIS2, DORA, GDPR ja CRA-ga

Tugevaimad VEX-programmid ei ole eraldiseisvad turbeinseneri projektid. Need on vastendatud kontrollisüsteemiga, mida organisatsioon juba kasutab.

ISO/IEC 27001:2022 alusel peab ISMS arvestama huvitatud poolte, õiguslike ja lepinguliste kohustuste ning teiste organisatsioonidega seotud liideste ja sõltuvustega. See kohaldamisala loogika on VEX-i jaoks oluline, sest tarnijate turvateated, kliendikohustused, avatud lähtekoodiga komponendid ja allhanke korras osutatavad teenused mõjutavad kõik haavatavuse otsuseid.

Kõige asjakohasemad lisa A kontrollimeetmed hõlmavad 5.19 Infoturve tarnijasuhetes, 5.20 Infoturbe käsitlemine tarnijalepingutes, 5.21 Infoturbe juhtimine IKT tarneahelas, 5.22 Tarnijateenuste seire, läbivaatamine ja muudatuste juhtimine, 5.28 Tõendite kogumine ja 8.8 Tehniliste haavatavuste haldus. Turvalise arenduse kontrollimeetmed 8.25 kuni 8.29 on samuti asjakohased, kui organisatsioon arendab tarkvara või digitaalseid tooteid.

NIS2 suurendab juhtimissurvet. Article 21 nõuab asjakohaseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist, arendust ja hooldust, haavatavuste käsitlemist ja avalikustamist, kontrollimeetmete tõhusust, küberhügieeni, krüptograafiat, personaliturvet, juurdepääsukontrolli, varahaldust ja autentimist. Article 20 nõuab, et juhtorganid kiidaksid heaks ja jälgiksid küberturbe riskijuhtimise meetmeid. See muudab VEX-i mõõdikud sobivaks juhatuse aruandluseks.

DORA kohaldub kohaldamisalasse kuuluvatele finantsüksustele alates 17. jaanuarist 2025. See nõuab IKT-riski juhtimise raamistikku, IKT-varade, haavatavuste, sõltuvuste ja IKT kolmandate osapoolte teenuste tuvastamist ja klassifitseerimist, intsidendihaldust, vastupidavuse testimist, kolmandate osapoolte riskijuhtimist ja juhtkonna järelevalvet. Finantsüksuste jaoks on VEX-i kirjed eriti kasulikud, kui tarnija turvateade tuleb siduda kriitiliste või oluliste funktsioonide, lepinguliste kohustuste ja intsidendi klassifitseerimisega.

GDPR muutub asjakohaseks, kui ärakasutamine võib mõjutada isikuandmeid. Haavatav API, teek või teenus, mis võib avaldada kliendikirjeid, nõuab hindamist konfidentsiaalsuse, tervikluse, käideldavuse ja rikkumisest teatamise kriteeriumide suhtes. VEX-i „ei mõjuta” järeldus võib toetada otsust mitte teavitada, kuid ainult siis, kui organisatsioon suudab näidata, miks isikuandmete rikkumist ei toimunud.

Cyber Resilience Act lisab tootejuhtimise mõõtme. CRA kohustuste järkjärgulisel jõustumisel vajavad tootjad ja teised majandustegevuses osalejad korratavaid haavatavuste käsitlemise, turvauuenduste, koordineeritud avalikustamise ja tõendusmaterjali protsesse. CSAF saab turvateateid struktureerida. VEX saab selgitada, millised tooted ja versioonid on mõjutatud, parandatud või mitte mõjutatud.

Mida Claryseci ristvastavuse juhend lisab

Zenith Controls on väärtuslik, sest see seob tehnilise töö auditi ootuste ja kattuvate raamistikega. VEX-i ja CSAF-i puhul on kolm kõige olulisemat valdkonda: IKT tarneahela turve, tehniliste haavatavuste haldus ja tõendite kogumine.

IKT tarneahela turbe puhul tuvastab Zenith Controls ISO/IEC 27002:2022 kontrollimeetme 5.21 kui „Infoturbe juhtimine IKT tarneahelas”. See selgitab, et 5.21 laiendab tarnijasuhete kontrollimeetmed 5.19 ja 5.20 IKT-spetsiifilistele riskidele, sealhulgas ebaturvalistele tarkvarakomponentidele ning kolmandate osapoolte või avatud lähtekoodiga teekidele. See seob selle turvalise inseneeria, turvalise programmeerimise, turbetestimise, juurdepääsukontrolli, tõendite kogumise, turvalise arenduse elutsükli ja allhankearendusega.

Täpselt seal CSAF ja VEX toimivadki. Tarnija turvateade ei ole lihtsalt sõnum tarnijalt. See on tõendusmaterjal tarnija küberturbe praktika kohta. Tarnija VEX-avaldus ei ole lihtsalt mugavus. See võib toetada hankeid, hoolsuskontrolli, seiret ja kliendi riskiotsuseid.

Tehniliste haavatavuste halduse puhul tuvastab Zenith Controls kontrollimeetme 8.8 kui „Tehniliste haavatavuste haldus”. See liigitab kontrollimeetme ennetavaks, toetades konfidentsiaalsust, terviklust ja käideldavust, ning seob selle ohtude ja haavatavuste haldusega. Samuti märgib see, et haavatavuste haldus on seotud pahavarakaitse, konfiguratsioonihalduse, muudatuste juhtimise, ohuteabe ja seirega.

Eriti kasulik Zenith Controls katkend VEX-i juhtimise jaoks on:

„Tõhus haavatavuste haldus prioriseerib tegelike ohtude alusel. Ohuteave näitab, milliseid haavatavusi aktiivselt ära kasutatakse, suunates paikamise prioriseerimist.”

See on erinevus toore SBOM-vastendamise ja riskipõhise VEX-triaaži vahel. Ainuüksi olemasolu ei ole piisav. Otsust peavad kujundama ärakasutatavus, vara kriitilisus, kokkupuude ja ohutegevus.

Tõendusmaterjali puhul tuvastab Zenith Controls kontrollimeetme 5.28 „Tõendite kogumine” kui korrigeeriva ning seotuna tuvastamise ja reageerimisega. See seob 5.28 intsidentidele reageerimise, logimise, seire ja sündmustest teatamisega. Samuti vastendab see tõendusmaterjali käitlemise ISO/IEC 27037:2012 standardiga digitaalse tõendusmaterjali tuvastamiseks, kogumiseks, hankimiseks ja säilitamiseks.

Kui haavatavus on pelgalt teoreetiline, võivad rutiinsed VEX-i kirjed olla piisavad. Kui kahtlustatakse ärakasutamist, peab organisatsioon liikuma intsidendi tõendusmaterjali käitlemisele. Logid, tarnijasuhtlus, klientidele saadetud teated, paikamiskirjed ja kohtuekspertiisi artefaktid vajavad terviklust, säilitamist ja jälgitavust.

Praktiline VEX-i tõendusmaterjali pakett teavitusest sulgemiseni

Naaseme Anya fintech-platvormi juurde. CSAF-turvateade saabub kriitilise haavatavuse kohta teegis lib-common-utils, mis esineb makselüüsi SBOM-is. Distsiplineeritud reageerimine looks ühe tõendusmaterjali paketi, mitte hajutatud Slacki sõnumid ja ekraanitõmmised.

1. samm: looge turvateate vastuvõtukirje

Avage ISMS-i tõendusmaterjali jälgimissüsteemis haavatavuse juhtum. Lisage CSAF-turvateade, CVE-viide, tarnija bülletään, SBOM-i vaste ja mõjutatud varade loend. Määrake haavatavuse omanik ja ärisüsteemi omanik. Siduge makseteenus kliendimõju, isikuandmete, finantstöötluse ja tegevuskriitilisusega.

Poliitiline alus: Haavatavuste ja paikade halduse poliitika nõuab turvateadete seiret ja kriitiliste haavatavuste eskaleerimist. ISO alus: lisa A kontrollimeede 8.8. NIS2 alus: haavatavuste käsitlemine ja turvaline hooldus. DORA alus: IKT haavatavuste tuvastamine ja intsidentideks valmisolek.

2. samm: määrake esialgseks staatuseks uurimisel

Esialgne staatus peab sageli olema „uurimisel”, eriti kriitiliste turvateadete puhul. Määrake otsuse tähtaeg, näiteks 24 tundi väliselt avatud või kriitiliste teenuste korral. Kirjendage ajutised kontrollimeetmed, näiteks tugevdatud seire, ajutised funktsioonipiirangud või WAF-i reeglid. See hoiab ära kriitilise turvateate kadumise juhtimata tööjärjekorda.

3. samm: tehke ärakasutatavuse analüüs

Inseneritiim peab vastama praktilistele küsimustele:

• Kas haavatav versioon on tootmiskeskkonnas olemas?
• Kas haavatav funktsioon on imporditud, kutsutud või kättesaadav?
• Kas haavatav konfiguratsioon on lubatud?
• Kas komponent on avatud mitteusaldusväärsele sisendile?
• Kas enne haavatava tee kättesaamist on nõutav autentimine?
• Kas kompenseerivad kontrollimeetmed on tõhusad?
• Kas toimub aktiivne ärakasutamine või on olemas usaldusväärne ohuteave?
• Kas ärakasutamine võib mõjutada isikuandmeid, finantstehinguid või teenuse käideldavust?

Anya juhtumis kinnitab staatiline analüüs, et komponent on olemas, kuid haavatavat funktsiooni makselüüs ei käivita. Tootmiskeskkonnas puudub käivitustee. Meeskond koostab VEX-i „ei mõjuta” avalduse koos seda toetava tõendusmaterjaliga.

Kui analüüs oleks näidanud, et autentitud administraatori töö saab haavatava funktsioonini jõuda, oleks õige staatus „mõjutatud”, mitte „ei mõjuta”. Seejärel looks meeskond riskikäsitluse plaani, avaks muudatuse pileti, paigaks või leevendaks ning uuendaks staatuseks „parandatud” alles pärast verifitseerimist.

4. samm: siduge juhtum riskiregistri ja tarnijakirjega

Kriitilised ja kõrge riskiga juhtumid tuleb kanda ISMS-i riskiregistrisse, välja arvatud juhul, kui need suletakse heakskiidetud ja tõendatud erandiga. Tarnijate turvateated tuleb siduda ka tarnijaregistri, lepinguliste kohustuste ja seirekirjetega.

See toetab Zenith Blueprint 23. sammu, mis juhendab organisatsioone koostama tarnijate loendi, klassifitseerima neid juurdepääsu ja operatiivse kontrolli alusel, lisama lepingutesse turbeootused ning määratlema tarnijamuudatuste seireprotseduurid.

5. samm: valideerige parandus või kinnitage erand

„Parandatud” staatuse puhul lisage paiga versioon, muudatuse kirje, CI/CD torustiku tulemus, sõltuvuste skannimine, konteineri tõmmise digest, juurutamise tõendusmaterjal ja regressioonitest. „Ei mõjuta” staatuse puhul lisage kooditee analüüs, konfiguratsiooni tõendusmaterjal, versiooni tõendusmaterjal, kompenseeriva kontrollimeetme tõendusmaterjal ja heakskiit.

Kui kliendid kasutavad ise majutatavaid versioone või haavatavus võib mõjutada väliseid kasutajaid, koordineerige kommunikatsiooni. Koordineeritud haavatavuste avalikustamise poliitika annab mudeli:

„Kui kinnitatud haavatavus võib mõjutada kliente või teenusekasutajaid, koostab kommunikatsioonimeeskond VRT juhtimisel turvateate. Turvateade peab sisaldama probleemi ülevaadet ilma ärakasutamise üksikasju avaldamata, mõjutatud tooteid või versioone, leevendusjuhiseid või paiga allalaadimise juhiseid ning tugikontakti teavet.”

Rakendusnõuete jaotisest, poliitika punkt 6.8, vastendub see otse CSAF-i avaldamise distsipliiniga.

6. samm: säilitage tõendusmaterjal, kui kahtlustatakse ärakasutamist

Kui logid näitavad ärakasutamiskatseid, liikuge haavatavuste käsitlemiselt intsidentidele reageerimisele ja tõendite kogumisele. Käivitage tõendite valduse ahela logi, säilitage logid, kirjendage SIEM-i päringud, eksportige asjakohased sündmused, vajaduse korral tehke mõjutatud süsteemidest tõmmised ja dokumenteerige, kes iga artefakti käsitles. Siduge intsidendijuhtum VEX-i kirjega.

Mida audiitorid ja regulaatorid küsivad

Kõik audiitorid ei testi VEX-i ja CSAF-i juhtimist ühtemoodi. Üks tõendusmaterjali pakett peaks rahuldama mitut vaatenurka.

Zenith Controls sisaldab auditi metoodika juhiseid, mis sobivad selle tabeliga. IKT tarneahela turbe puhul uurivad audiitorid ISO/IEC 19011 ja ISO/IEC 27007 alusel hankepoliitikaid, RFP-malle ja tarnijahaldusprotsesse, et kontrollida IKT-spetsiifilisi turbenõudeid. Nad valimivad lepinguid turvalise arenduse, haavatavuste avalikustamise ja tarkvara autentsuse klauslite suhtes.

Tehniliste haavatavuste halduse puhul vaatavad audiitorid läbi haavatavuste halduse poliitika, skannimissageduse, varade katvuse, riskipõhise prioriseerimise, parandustähtajad ja vastutused. Tõendite kogumise puhul testivad nad, kas tõendite valduse ahelat, turvalist säilitamist ja säilitustähtaegu järgiti tegelikes intsidentides.

Seetõttu ei tohi VEX-i juhtimine kunagi lõppeda staatuse sildiga. Silt on kokkuvõte. Tõendusmaterjali jälg on kontrollimeede.

Juhtkonna mõõdikud, mis muudavad VEX-i juhatuse jaoks kasutatavaks

ISO/IEC 27001:2022 nõuab tulemuslikkuse hindamist, siseauditit ja juhtkonnapoolset ülevaatust. NIS2 nõuab juhtkonna järelevalvet. DORA nõuab IKT-riski juhtimist. VEX ja CSAF loovad mõõdikud, mis tõlgivad inseneritöö juhtkonnale arusaadavaks riskinähtavuseks.

Kasulikud juhtkonnapoolse ülevaatuse mõõdikud on näiteks:

• Käesolevas kvartalis saadud kriitiliste CSAF-turvateadete arv
• SBOM-i komponentidega vastendatud teadete osakaal
• VEX-i staatuste arv ja vanus staatuste mõjutatud, ei mõjuta, parandatud ja uurimisel kaupa
• Tähtaja ületanud „uurimisel” juhtumid
• Tarnijate turvateated ilma piisavate mõjutatud versioonide andmeteta
• Kriitilised haavatavused, mis on aktsepteeritud heakskiidetud eranditena
• Aeg turvateate vastuvõtust VEX-i otsuseni
• Aeg mõjutatud otsusest parandamiseni
• Võimaliku isikuandmete mõjuga juhtumite arv
• Väljastatud kliendi turvateadete arv

Need mõõdikud aitavad juhtkonnal esitada paremaid küsimusi. Millised tarnijad ei paku rakendatavaid haavatavuste andmeid? Millistel toodetel on pikimad parandamisajad? Millised meeskonnad jätavad uurimised avatuks? Millised haavatavused võivad mõjutada isikuandmeid või kriitilisi funktsioone?

Levinud tõrkemustrid, mis tuleb kõrvaldada

Esimene tõrge on SBOM-i vaste käsitlemine ärakasutatavuse analüüsina. Komponendi vaste on signaal, mitte järeldus.

Teine tõrge on „ei mõjuta” kasutamine ilma põhjenduseta. Audiitorid küsivad, miks. Kas kooditee oli kättesaamatu? Kas haavatav funktsioon oli keelatud? Kas versioon oli erinev? Kas komponenti kasutati ainult ehitamise ajal? Kas järelduse kiitis heaks tooteturbe funktsioon?

Kolmas tõrge on „uurimisel” staatuse avatuks jätmine. See staatus on kasulik ainult siis, kui sellel on omanik, tähtaeg ja ajutised kontrollimeetmed.

Neljas tõrge on tarnijajuhtimise lahutamine haavatavuste juhtimisest. Tarnijalepingud peavad nõudma õigeaegset haavatavuste avalikustamist, reageerimisaegu, paikamiskohustusi, turvateate sisu ja tõendusmaterjali tuge.

Viies tõrge on isikuandmete ja kliendisuhtluse ignoreerimine. Haavatavus, mis võib avaldada isikuandmeid, vajab GDPR-i hinnangut. Kinnitatud tootehaavatavus, mis võib mõjutada kliente, vajab koordineeritud avalikustamise distsipliini. Finantsteenuse sõltuvus võib nõuda DORA intsidendianalüüsi.

Kuues tõrge on nõrk tõendusmaterjali säilitamine. Zenith Blueprint hoiatab 23. sammus, kontrollimeede 5.28, et tõendusmaterjal jäetakse sageli tähelepanuta:

„see, mida suudate tõendada, on sama oluline kui see, mis tegelikult juhtus”

See lause võtab kokku 2026. aasta reaalsuse. Turbemeeskonnad mitte ainult ei paranda haavatavusi. Nad tõendavad, et otsused olid õigeaegsed, riskipõhised ja kontrollitud.

Järgmised sammud auditikõlbliku haavatavuste tõendusmaterjali loomiseks

Kui teie organisatsioonil on SBOM-id juba olemas, ei ole järgmine küpsussamm veel üks registritabel. See on haavatavuse staatuse, tarnijate turvateadete ja avalikustamise tõendusmaterjali juhtimine.

Alustage nelja tegevusega:

1. Lisage CSAF-i ja VEX-i vastuvõtt oma haavatavuste halduse protseduuri.
2. Määratlege heakskiidukriteeriumid staatustele mõjutatud, ei mõjuta, parandatud ja uurimisel.
3. Siduge VEX-i kirjed oma ISMS-i riskiregistri, tarnijaregistri, varade registri, SBOM-repositooriumi ja intsidendiprotsessiga.
4. Testige protsessi ühe hiljutise kriitilise turvateatega ja koostage auditivalmis tõendusmaterjali pakett.

Clarysec aitab teil selle kiiresti rakendada, kasutades Zenith Blueprinti, Zenith Controlsi ja asjakohast poliitikakomplekti, sealhulgas Haavatavuste ja paikade halduse poliitikat, Haavatavuste ja paikade halduse poliitikat – VKE, Rakendusturbe nõuete poliitikat – VKE, Turvalise arenduse poliitikat, Tõendite kogumise ja kohtuekspertiisi poliitikat – VKE ning Koordineeritud haavatavuste avalikustamise poliitikat.

2026. aastal ei ole otsustav küsimus „Kas meil on SBOM?”. See on „Kas suudame iga tõsise turvateate puhul täpselt tõendada, kuidas määrasime haavatavuse staatuse, käsitlesime riski ja edastasime tulemuse?”

Broneerige Claryseci hindamine või küsige asjakohast poliitikakomplekti, et muuta VEX ja CSAF auditivalmis haavatavuste tõendusmaterjaliks enne, kui järgmine kriitiline turvateade jõuab teie juhatuseni.