VEX ir CSAF: audituojami pažeidžiamumų įrodymai

07:40 saugumo pranešimas, kuris SBOM paverčia valdybos klausimu

2026 m. pradžios antradienio rytą, 07:40, sparčiai augančios FinTech platformos CISO Anya pamato kritinį tiekėjo saugumo pranešimą CSAF formatu. Plačiai naudojamoje atvirojo kodo bibliotekoje aptiktas nuotolinio kodo vykdymo pažeidžiamumas. Jos Software Bill of Materials patvirtina, kad biblioteka yra įtraukta į pagrindinę mokėjimų apdorojimo programą, dvi vidaus paslaugas ir išorinės analizės komponentą.

08:10 jos telefonas jau netyla. Inžinerijos komanda nori žinoti, ar pažeidžiama funkcija yra pasiekiama. Atitikties komanda klausia, ar tai susiję su ISO/IEC 27001:2022, NIS2 arba DORA. Teisininkai klausia, ar Kibernetinio atsparumo aktas galėtų pareikalauti komunikacijos klientams arba institucijoms. Valdybos narys, ką tik baigęs mokymus apie NIS2 vadovybės atskaitomybę, užduoda klausimą, kurį turi omenyje visi:

Ar esame paveikti?

Pirmas inžinerijos komandos atsakymas techniškai sąžiningas: paketas yra, bet pažeidžiama funkcija gamybinėje aplinkoje gali būti nekviečiama. 2026 m. tokio atsakymo nepakanka.

Valdybai reikia įrodymų. Klientams reikia aiškaus atsakymo. Pirkimų funkcija nori žinoti, ar tiekėjas įvykdė sutartinius atskleidimo įsipareigojimus. Duomenų apsaugos pareigūnas nori žinoti, ar galėjo būti atskleisti asmens duomenys. ISO 27001 auditorius nepriims „taip pasakė kūrėjas“ kaip saugotino įrodymo. DORA auditorius tikėsis, kad pažeidžiamumas bus susietas su IRT turtu, kritinėmis funkcijomis ir priklausomybėmis nuo trečiųjų šalių.

Čia VEX ir CSAF nustoja būti techniniais formatais ir tampa valdysenos infrastruktūra.

CSAF, Common Security Advisory Framework, struktūrizuoja pažeidžiamumų saugumo pranešimus taip, kad žmonės ir sistemos galėtų apdoroti paveiktus produktus, versijas, taisymo gaires, nuorodas ir būsenos informaciją. VEX, Vulnerability Exploitability eXchange, suteikia sprendimo sluoksnį. Jis suinteresuotosioms šalims parodo, ar žinomas pažeidžiamumas konkrečiame produkte, paslaugoje arba aplinkoje faktiškai yra išnaudojamas.

Praktinės VEX būsenos yra paprastos: paveikta, nepaveikta, ištaisyta ir tiriama. Už jų esanti valdysena nėra paprasta. Kiekvienai būsenai reikia įrodymų, savininko, pagrindimo, patvirtinimo ir peržiūros paleidiklio.

Atitikties spraga nebėra SBOM nebuvimas. Daugelis organizacijų jau turi SBOM. Spraga yra gebėjimas įrodyti, kaip kiekvienas pažeidžiamumo saugumo pranešimas buvo pirminiai įvertintas, kas patvirtino būsenos sprendimą, kokie įrodymai pagrindė išvadą „nepaveikta“, kaip buvo prioritetizuotas taisymas, kai produktas buvo „paveiktas“, ir kaip organizacija išsaugojo šį pėdsaką auditoriams, reguliuotojams, klientams ir vadovybei.

Clarysec VEX ir CSAF vertina kaip ISVS veiklos modelio dalį. Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane tai priklauso rizikos valdymo, tiekėjų saugumo, technologinių kontrolės priemonių ir įrodymų etapams. Zenith Controls: kryžminės atitikties vadove ši tema susieja ISO/IEC 27001:2022 kontroles su IRT tiekimo grandinės saugumu, pažeidžiamumų valdymu, įrodymų tvarkymu, NIS2, DORA, GDPR ir NIST lūkesčiais.

Kodėl SBOM sukuria signalus, o VEX sukuria įrodymus

SBOM yra sudedamųjų dalių sąrašas. Jis parodo, kas yra produkto arba paslaugos viduje. Kai vienai iš šių sudedamųjų dalių paskelbiamas CVE, SBOM parodo, kad galite būti paveikti.

Šis signalas vertingas, bet tai nėra išvada.

Brandžioje programinės įrangos aplinkoje gali būti sugeneruota tūkstančiai SBOM pažeidžiamumų atitikmenų. Dalis jų yra reali rizika. Dalis nėra išnaudojami, nes pažeidžiamas kodas nėra pristatomas, nėra importuojamas, nėra pasiekiamas, nėra sukonfigūruotas, nėra veikiamas nepatikimos įvesties arba yra suvaldytas kompensuojamosiomis kontrolės priemonėmis. Be formalaus tyrimo fiksavimo proceso komandos paprastai patenka į vieną iš dviejų ydingo veikimo modelių.

Pirmasis – pirminio vertinimo išsekimas. Inžinieriai vienodu skubumu vejasi kiekvieną pažeidžiamumo atitikmenį, net kai komponentas yra tik kūrimo metu naudojama priklausomybė, neaktyvus kodo kelias arba tik vidaus funkcija, apsaugota daugiasluoksnėmis kontrolės priemonėmis.

Antrasis – nedokumentuotas rizikos priėmimas. Komandos uždaro užduotis trumpais komentarais, pvz., „netaikoma“ arba „klaidingai teigiamas atvejis“. Tai gali atrodyti efektyvu, bet auditoriui tai yra nekontroliuojamas sprendimas. Reguliuotojui tai gali atrodyti kaip nevaldomas pažeidžiamumas.

VEX ir CSAF išsprendžia šią problemą paversdami pažeidžiamumų triukšmą struktūrizuotais, audituojamais pažeidžiamumų įrodymais.

Pagrįstas VEX ir CSAF valdysenos procesas atsako į penkis klausimus:

1. Ar gavome arba identifikavome saugumo pranešimą?
2. Ar susiejome jį su produktais, turtu, tiekėjais, klientais ir asmens duomenų srautais?
3. Ar nustatėme pažeidžiamumo būseną pagal apibrėžtus kriterijus?
4. Ar dokumentavome sprendimą, įrodymus, savininką, patvirtinimą ir peržiūros paleidiklį?
5. Ar, remdamiesi rizika, atlikome taisymą, atskleidimą, stebėseną arba išsaugojome įrodymus?

Skirtumas tarp „nepaveikta“ ir „ignoruota“ yra įrodymai.

VEX būsena „nepaveikta“ turi būti pagrįsta, pavyzdžiui, tuo, kad pažeidžiamas komponentas nėra naudojamas, pažeidžiama versija nėra įdiegta, pažeidžiamas kodo kelias nevykdomas, pažeidžiama konfigūracija išjungta arba kompensuojamoji kontrolės priemonė neleidžia išnaudoti pažeidžiamumo. Būsenai „tiriama“ turi būti nustatytas terminuotas tolesnis veiksmas – ji neturi tapti darbų sąrašo kapinynu. Būsena „ištaisyta“ turi nurodyti pataisą, rizikos mažinimo priemonę, versijos atnaujinimą, testavimo rezultatą ir diegimo įrašą. Būsena „paveikta“ turi patekti į rizikos tvarkymo, taisymo planavimo, tiekėjo informavimo, klientų komunikacijos ir, kai aktualu, incidento arba saugumo pažeidimo vertinimo darbo eigas.

Clarysec valdysenos modelis VEX būsenos sprendimams

Kiekvienas CSAF saugumo pranešimas ir VEX pareiškimas turi būti traktuojamas kaip kontroliuojamas įrašas ISVS viduje, o ne kaip izoliuotas inžinerinis artefaktas. Darbo eiga gali būti GRC platformoje, pažeidžiamumų valdymo priemonėje, užklausų sistemoje, pirminio kodo valdymo darbo eigoje arba Clarysec įrodymų darbaknygėje. Svarbiausia, kad būsena, įrodymai, patvirtinimas ir rizikos tvarkymas liktų susieti.

Ši lentelė atrodo paprasta, bet ji keičia kontrolės aplinką. Pareiškimas „nepaveikta“ tampa mini rizikos sprendimu konkrečiam produktui ir aplinkai. Būsena „ištaisyta“ susieja pažeidžiamumų valdymą su pakeitimų valdymu ir testavimu. Būsena „paveikta“ paleidžia tvarkymą, eskalavimą ir galimą atskleidimą. Būsena „tiriama“ suteikia vadovybei matomą, terminuotą riziką.

Zenith Blueprint sustiprina šį požiūrį 13 žingsnyje apie rizikos tvarkymo planavimą ir Taikomumo pareiškimą. Jame paaiškinama, kad sprendimai dėl kontrolės priemonių turi būti pagrįsti rizikos tvarkymu, teisiniais ar sutartiniais reikalavimais, taikymo srities aktualumu ir organizacijos kontekstu:

„SoA lape kiekvieną kontrolę pažymėkite kaip „Yes“ (taikoma) arba „No“ (netaikoma). Pateikite pagrindimą / pastabas.“

VEX atveju „nepaveikta“ laikosi tos pačios disciplinos. Tai nėra atsitiktinis užduoties uždarymas. Tai pagrįstas sprendimas, kuris turi atlaikyti peržiūrą.

Zenith Blueprint 19 žingsnyje nagrinėjamas techninių pažeidžiamumų valdymas:

„Sekite informaciją apie naujas saugumo klaidas (per tiekėjų įspėjimus, CVE srautus ir pan.) savo programinei ir aparatinei įrangai. Įvertinkite, kurios iš jų aktualios (ar naudojame šią programinę įrangą? kiek kritinė klaida?) ir nedelsdami pritaikykite pataisas arba rizikos mažinimo priemones.“

CSAF padeda gauti struktūrizuotus saugumo pranešimus. SBOM padeda nustatyti komponento buvimą. VEX padeda dokumentuoti išnaudojamumą ir būseną. Sprendimą valdo ISVS.

Politikos įrodymai iki kritinio saugumo pranešimo

VEX programa žlunga, kai pirmasis kritinis saugumo pranešimas gaunamas dar neapibrėžus vaidmenų, kriterijų ir įrodymų reikalavimų. Politikose jau turi būti apibrėžtas pažeidžiamumų priėmimas, eskalavimas, registravimas, tiekėjų įsipareigojimai, išimčių tvarkymas ir įrodymų išsaugojimas.

MVĮ atveju Pažeidžiamumų ir pataisų valdymo politika – MVĮ nustato stebėsenos pareigą:

„Stebi sistemas dėl pažeidžiamumų ir prieinamų pataisų, naudodama tiekėjų įspėjimus, grėsmių žvalgybos pranešimus ir operacinės sistemos pranešimus“

Ši nuostata iš Vaidmenų ir atsakomybių, politikos 4.2.1 punkto, tiesiogiai taikoma CSAF priėmimui. CSAF saugumo pranešimai yra tiekėjų arba ekosistemos pažeidžiamumų pranešimai, kurie turi būti stebimi, koreliuojami ir pirminiai įvertinami.

Ta pati MVĮ politika nustato pasirengimo auditui lūkesčius:

„Tvarkyti tikslius įrašus apie pritaikytas pataisas, neišspręstus klausimus ir išimtis, siekiant užtikrinti pasirengimą auditui“

Iš Tikslų, politikos 3.4 punkto, matyti, kur VEX tampa daugiau nei technine rinkmena. Jei komanda nediegia pataisos, nes produkto būsena yra „nepaveikta“, šiai išimčiai reikia įrodymų, patvirtinimo ir atsekamumo.

Įmonių aplinkoms Pažeidžiamumų ir pataisų valdymo politika yra aiški:

„Stebėti grėsmių pranešimus (pvz., CVE, CISA KEV, tiekėjų biuletenius) ir eskaluoti kritinius pažeidžiamumus.“

Iš Vaidmenų ir atsakomybių, politikos 4.5.1 punkto, ši nuostata palaiko struktūrizuotą CSAF, CVE, tiekėjų biuletenių ir išnaudojimo žvalgybos priėmimo kanalą. Ji taip pat reikalauja eskalavimo, kai VEX būsena yra „paveikta“ arba „tiriama“ kritiniam produktui.

Įmonės politika taip pat nustato:

„Visi kritiniai ir didelės rizikos pažeidžiamumai turi būti registruojami ISVS rizikų registre ir stebimi tol, kol bus pašalinti arba padengti patvirtinta išimtimi.“

Ši nuostata iš Valdysenos reikalavimų, politikos 5.3 punkto, yra atitikties atrama. VEX pareiškimas „nepaveikta“ kritiniam CVE yra pagrįstas tik tada, kai jis traktuojamas kaip patvirtinta išimtis su įrodymais. VEX pareiškimas „ištaisyta“ uždaro ciklą tik tada, kai taisymas yra patikrintas.

Rizikos vertinimui taip pat reikia konteksto. Ta pati politika nurodo:

„Rizikos vertinimas (grindžiamas CVSS, turto kritiškumu, grėsmių žvalgyba)“

Iš Rizikos tvarkymo ir išimčių, politikos 7.2.2 punkto, tai palaiko mišrų pirminio vertinimo modelį. Vien CVSS nepakanka. Vidutinio sunkumo pažeidžiamumas, aktyviai išnaudojamas kritiniame tapatybės komponente, gali būti skubesnis nei kritinio CVSS lygio klausimas nepasiekiamame kode.

Taikomųjų programų ir saugaus kūrimo politikos tą pačią discipliną išplečia į inžineriją ir tiekėjus. Taikomųjų programų saugumo reikalavimų politika – MVĮ reikalauja, kad komandos sektų:

„žinomus pažeidžiamumus ir taisymo būseną.“

Iš Politikos įgyvendinimo reikalavimų, politikos 6.4.2.3 punkto, tai tiksliai atitinka VEX būsenas. Ta pati politika reikalauja, kad susitarimuose būtų:

„nustatyti įsipareigojimai dėl pažeidžiamumų atskleidimo, reagavimo terminų ir pataisų diegimo.“

Iš Valdysenos reikalavimų, politikos 5.3.2 punkto, tai tampa praktine tiekėjo sutarties nuostata: laiku teikti saugumo pranešimus, identifikuoti paveiktas versijas, kai įmanoma, pateikti VEX būseną, apibrėžti taisymo terminus ir palaikyti klientų informavimą.

Įmonių saugaus kūrimo atveju Saugaus kūrimo politika numato:

„Žinomų pažeidžiamumų skenavimą (CVE, OSS Index ir pan.)“

Iš Valdysenos reikalavimų, politikos 5.4.3 punkto, tai suteikia inžinerijai apibrėžtą mechanizmą saugumo pranešimams susieti su komponentais ir inicijuoti VEX analizę.

Kai pažeidžiamumas tampa incidentu arba galimu teisiniu klausimu, įrodymų disciplina tampa esminė. Įrodymų rinkimo ir kriminalistikos politika – MVĮ nustato:

„Kiekvienam incidentui turi būti tvarkomas paprastas perdavimo grandinės žurnalas (pvz., Excel failas arba šabloninis dokumentas).“

Iš Valdysenos reikalavimų, politikos 5.3.1 punkto, tai yra riba tarp įprasto VEX pirminio vertinimo ir incidento lygmens įrodymų tvarkymo. Jei įtariamas išnaudojimas, žurnalams, saugumo pranešimų įrašams, analizės pastaboms, komunikacijai ir kriminalistiniams artefaktams reikia atsekamumo.

VEX ir CSAF susiejimas su ISO 27001, NIS2, DORA, GDPR ir CRA

Stipriausios VEX programos nėra atskiri saugumo inžinerijos projektai. Jos susiejamos su kontrolės sistema, kurią organizacija jau naudoja.

Pagal ISO/IEC 27001:2022 ISVS turi atsižvelgti į suinteresuotąsias šalis, teisines ir sutartines prievoles, sąsajas ir priklausomybes su kitomis organizacijomis. Ši taikymo srities logika yra būtina VEX, nes tiekėjų saugumo pranešimai, klientų įsipareigojimai, atvirojo kodo komponentai ir išorinės paslaugos daro įtaką sprendimams dėl pažeidžiamumų.

Svarbiausios A priedo kontrolės apima 5.19 Informacijos saugumas tiekėjų santykiuose, 5.20 Informacijos saugumo užtikrinimas tiekėjų susitarimuose, 5.21 Informacijos saugumo valdymas IRT tiekimo grandinėje, 5.22 Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas, 5.28 Įrodymų rinkimas ir 8.8 Techninių pažeidžiamumų valdymas. Saugaus kūrimo kontrolės 8.25–8.29 taip pat aktualios, kai organizacija kuria programinę įrangą arba skaitmeninius produktus.

NIS2 didina valdysenos spaudimą. Article 21 reikalauja tinkamų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, kūrimą ir priežiūrą, pažeidžiamumų tvarkymą ir atskleidimą, kontrolės veiksmingumą, kibernetinę higieną, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą ir autentifikavimą. Article 20 reikalauja, kad valdymo organai patvirtintų ir prižiūrėtų kibernetinio saugumo rizikos valdymo priemones. Dėl to VEX rodikliai tinka valdybos ataskaitoms.

DORA taikomas nuo 2025 m. sausio 17 d. į taikymo sritį patenkantiems finansų subjektams. Jis reikalauja IRT rizikos valdymo sistemos, IRT turto, pažeidžiamumų, priklausomybių ir IRT trečiųjų šalių paslaugų identifikavimo ir klasifikavimo, incidentų valdymo, atsparumo testavimo, trečiųjų šalių rizikos valdymo ir vadovybės priežiūros. Finansų subjektams VEX įrašai ypač naudingi, kai tiekėjo saugumo pranešimą reikia susieti su kritinėmis arba svarbiomis funkcijomis, sutartiniais įsipareigojimais ir incidento klasifikavimu.

GDPR aktualus, kai išnaudojimas galėtų paveikti asmens duomenis. Pažeidžiama taikomųjų programų sąsaja, biblioteka arba paslauga, galinti atskleisti klientų įrašus, reikalauja vertinimo pagal konfidencialumo, vientisumo, prieinamumo ir pranešimo apie pažeidimą kriterijus. VEX išvada „nepaveikta“ gali palaikyti sprendimą nepranešti, bet tik tada, kai organizacija gali parodyti, kodėl asmens duomenų saugumo pažeidimas neįvyko.

Kibernetinio atsparumo aktas papildo produkto valdyseną. Įsigaliojant CRA įpareigojimams, gamintojams ir kitiems ekonominės veiklos vykdytojams reikia kartotinių pažeidžiamumų tvarkymo, saugumo naujinimų, koordinuoto atskleidimo ir įrodymų procesų. CSAF gali struktūrizuoti saugumo pranešimus. VEX gali paaiškinti, kurie produktai ir versijos yra paveikti, ištaisyti arba nepaveikti.

Ką prideda Clarysec kryžminės atitikties vadovas

Zenith Controls vertingas todėl, kad techninį darbą susieja su audito lūkesčiais ir persidengiančiomis sistemomis. VEX ir CSAF atveju svarbiausios trys sritys: IRT tiekimo grandinės saugumas, techninių pažeidžiamumų valdymas ir įrodymų rinkimas.

IRT tiekimo grandinės saugumo srityje Zenith Controls identifikuoja ISO/IEC 27002:2022 kontrolę 5.21 kaip „Informacijos saugumo valdymas IRT tiekimo grandinėje“. Jame paaiškinama, kad 5.21 išplečia tiekėjų santykių kontroles 5.19 ir 5.20 į IRT specifines rizikas, įskaitant nesaugius programinės įrangos komponentus ir trečiųjų šalių arba atvirojo kodo bibliotekas. Ji siejasi su saugia inžinerija, saugiu programavimu, saugumo testavimu, prieigos kontrole, įrodymų rinkimu, saugaus kūrimo gyvavimo ciklu ir išoriniu kūrimu.

Būtent čia veikia CSAF ir VEX. Tiekėjo saugumo pranešimas nėra tik tiekėjo žinutė. Tai tiekėjo kibernetinio saugumo praktikos įrodymas. Tiekėjo VEX pareiškimas nėra tik patogumas. Jis gali palaikyti pirkimus, deramą patikrinimą, stebėseną ir klientų rizikos sprendimus.

Techninių pažeidžiamumų valdymo srityje Zenith Controls identifikuoja kontrolę 8.8 kaip „Techninių pažeidžiamumų valdymas“. Kontrolė klasifikuojama kaip prevencinė, palaikanti konfidencialumą, vientisumą ir prieinamumą bei susieta su grėsmių ir pažeidžiamumų valdymu. Taip pat nurodoma, kad pažeidžiamumų valdymas susijęs su apsauga nuo kenkėjiškos programinės įrangos, konfigūracijų valdymu, pakeitimų valdymu, grėsmių žvalgyba ir stebėsena.

Ypač naudinga Zenith Controls ištrauka VEX valdysenai yra:

„Veiksmingas pažeidžiamumų valdymas prioritetus nustato pagal realias grėsmes. Grėsmių žvalgyba informuoja, kurie pažeidžiamumai yra aktyviai išnaudojami, ir nukreipia pataisų prioritetizavimą.“

Tai ir yra skirtumas tarp neapdoroto SBOM atitikmens ir rizika grindžiamo VEX pirminio vertinimo. Vien buvimo nepakanka. Sprendimą turi formuoti išnaudojamumas, turto kritiškumas, ekspozicija ir grėsmių aktyvumas.

Įrodymų srityje Zenith Controls identifikuoja kontrolę 5.28 „Įrodymų rinkimas“ kaip korekcinę ir susietą su aptikimu bei reagavimu. Ji sieja 5.28 su reagavimu į incidentus, žurnalų tvarkymu, stebėsena ir įvykių pranešimu. Ji taip pat susieja įrodymų tvarkymą su ISO/IEC 27037:2012 dėl skaitmeninių įrodymų identifikavimo, rinkimo, įgijimo ir išsaugojimo.

Kai pažeidžiamumas yra tik teorinis, įprastų VEX įrašų gali pakakti. Kai įtariamas išnaudojimas, organizacija turi pereiti prie incidento įrodymų tvarkymo. Žurnalams, tiekėjų komunikacijai, klientų pranešimams, pataisų įrašams ir kriminalistiniams artefaktams reikia vientisumo, išsaugojimo ir atsekamumo.

Praktinis VEX įrodymų paketas nuo įspėjimo iki uždarymo

Grįžkime prie Anyos FinTech platformos. Gaunamas CSAF saugumo pranešimas dėl kritinio pažeidžiamumo lib-common-utils, kuris matomas mokėjimų vartų SBOM. Disciplinuotas atsakas sukurtų vieną įrodymų paketą, o ne išsibarsčiusias Slack žinutes ir ekrano kopijas.

1 žingsnis: sukurkite saugumo pranešimo priėmimo įrašą

Atidarykite pažeidžiamumo bylą ISVS įrodymų sekimo priemonėje. Pridėkite CSAF saugumo pranešimą, CVE nuorodą, tiekėjo biuletenį, SBOM atitikmenį ir paveikto turto sąrašą. Priskirkite pažeidžiamumo savininką ir verslo sistemos savininką. Susiekite mokėjimų paslaugą su poveikiu klientams, asmens duomenimis, finansų apdorojimu ir operaciniu kritiškumu.

Politikos pagrindas: Pažeidžiamumų ir pataisų valdymo politika reikalauja stebėti saugumo pranešimus ir eskaluoti kritinius pažeidžiamumus. ISO pagrindas: A priedo kontrolė 8.8. NIS2 pagrindas: pažeidžiamumų tvarkymas ir saugi priežiūra. DORA pagrindas: IRT pažeidžiamumų identifikavimas ir pasirengimas incidentams.

2 žingsnis: nustatykite preliminarią būseną „tiriama“

Pradinė būsena dažnai turėtų būti „tiriama“, ypač kritinių saugumo pranešimų atveju. Nustatykite sprendimo terminą, pvz., 24 valandas išorėje pasiekiamoms arba kritinėms paslaugoms. Užregistruokite laikinas kontrolės priemones, pvz., sustiprintą stebėseną, laikinus funkcijų apribojimus arba WAF taisykles. Tai neleidžia kritiniam saugumo pranešimui pradingti nevaldomame darbų sąraše.

3 žingsnis: atlikite išnaudojamumo analizę

Inžinerijos komanda turi atsakyti į praktinius klausimus:

• Ar pažeidžiama versija yra gamybinėje aplinkoje?
• Ar pažeidžiama funkcija importuojama, kviečiama arba pasiekiama?
• Ar pažeidžiama konfigūracija įjungta?
• Ar komponentas veikiamas nepatikimos įvesties?
• Ar prieš pasiekiant pažeidžiamą kelią reikalingas autentifikavimas?
• Ar kompensuojamosios kontrolės priemonės veiksmingos?
• Ar vyksta aktyvus išnaudojimas arba yra patikima grėsmių žvalgyba?
• Ar išnaudojimas galėtų paveikti asmens duomenis, finansines operacijas arba paslaugos prieinamumą?

Anyos atveju statinė analizė patvirtina, kad komponentas yra, bet mokėjimų vartai pažeidžiamos funkcijos nekviečia. Gamybinėje aplinkoje vykdymo kelio nėra. Komanda parengia VEX pareiškimą „nepaveikta“ su patvirtinamaisiais įrodymais.

Jei analizė būtų parodžiusi, kad autentifikuota administratoriaus užduotis gali pasiekti pažeidžiamą funkciją, teisinga būsena būtų „paveikta“, o ne „nepaveikta“. Tada komanda sukurtų Rizikos tvarkymo planą, atidarytų pakeitimo užduotį, įdiegtų pataisą arba rizikos mažinimo priemonę ir atnaujintų būseną į „ištaisyta“ tik po patikrinimo.

4 žingsnis: susiekite bylą su rizikų registru ir tiekėjo įrašu

Kritinės ir didelės rizikos bylos turi būti įtrauktos į ISVS rizikų registrą, nebent jos uždaromos patvirtinta, įrodymais pagrįsta išimtimi. Tiekėjų saugumo pranešimai taip pat turi būti susieti su tiekėjų registru, sutartiniais įsipareigojimais ir stebėsenos įrašais.

Tai palaiko Zenith Blueprint 23 žingsnį, kuriame organizacijoms nurodoma sudaryti tiekėjų sąrašą, klasifikuoti juos pagal prieigą ir operacinę kontrolę, į sutartis įtraukti saugumo lūkesčius ir apibrėžti tiekėjų pakeitimų stebėsenos procedūras.

5 žingsnis: patvirtinkite pataisą arba patvirtinkite išimtį

Būsenai „ištaisyta“ pridėkite pataisos versiją, pakeitimo įrašą, CI/CD konvejerio rezultatą, priklausomybių skenavimą, konteinerio atvaizdo santrauką, diegimo įrodymus ir regresinį testą. Būsenai „nepaveikta“ pridėkite kodo kelio analizę, konfigūracijos įrodymus, versijos įrodymus, kompensuojamųjų kontrolės priemonių įrodymus ir patvirtinimą.

Jei klientai naudoja savarankiškai talpinamas versijas arba pažeidžiamumas galėtų paveikti išorės naudotojus, koordinuokite komunikaciją. Koordinuoto pažeidžiamumų atskleidimo politika pateikia modelį:

„Kai patvirtintas pažeidžiamumas gali paveikti klientus arba paslaugų naudotojus, Komunikacijos komanda, vadovaujama VRT, turi parengti saugumo pranešimą. Pranešime turi būti problemos apžvalga, neatskleidžiant išnaudojimo detalių, paveikti produktai arba versijos, rizikos mažinimo gairės arba pataisos atsisiuntimo instrukcijos ir palaikymo kontaktinė informacija.“

Iš Įgyvendinimo reikalavimų, politikos 6.8 punkto, tai tiesiogiai atitinka CSAF publikavimo discipliną.

6 žingsnis: išsaugokite įrodymus, jei įtariamas išnaudojimas

Jei žurnalai rodo bandymą išnaudoti pažeidžiamumą, pereikite nuo pažeidžiamumų tvarkymo prie reagavimo į incidentus ir įrodymų rinkimo. Pradėkite perdavimo grandinės žurnalą, išsaugokite žurnalus, užregistruokite SIEM užklausas, eksportuokite aktualius įvykius, prireikus padarykite paveiktų sistemų momentines kopijas ir dokumentuokite, kas tvarkė kiekvieną artefaktą. Susiekite incidento bylą su VEX įrašu.

Ko klaus auditoriai ir reguliuotojai

Auditoriai VEX ir CSAF valdyseną tikrina nevienodai. Vienas įrodymų paketas turi tenkinti kelias perspektyvas.

Zenith Controls apima audito metodikos gaires, atitinkančias šią lentelę. IRT tiekimo grandinės saugumo srityje auditoriai, taikantys ISO/IEC 19011 ir ISO/IEC 27007, nagrinės pirkimų politikas, RFP šablonus ir tiekėjų valdymo procesus, kad patikrintų IRT specifinius saugumo reikalavimus. Jie atrankiniu būdu tikrins sutartis dėl saugaus kūrimo, pažeidžiamumų atskleidimo ir programinės įrangos autentiškumo nuostatų.

Techninių pažeidžiamumų valdymo srityje auditoriai peržiūri pažeidžiamumų valdymo politiką, skenavimo dažnį, turto aprėptį, prioritetizavimą pagal riziką, taisymo terminus ir atsakomybes. Įrodymų rinkimo srityje jie tikrina, ar realių incidentų metu buvo laikomasi perdavimo grandinės, saugaus saugojimo ir išsaugojimo reikalavimų.

Todėl VEX valdysena niekada neturi baigtis būsenos etikete. Etiketė yra santrauka. Įrodymų pėdsakas yra kontrolės priemonė.

Vadovybės rodikliai, kurie VEX parengia valdybai

ISO/IEC 27001:2022 reikalauja veiklos vertinimo, vidaus audito ir vadovybės peržiūros. NIS2 reikalauja vadovybės priežiūros. DORA reikalauja IRT rizikos valdysenos. VEX ir CSAF sukuria rodiklius, kurie inžinerinį darbą paverčia vykdomajai vadovybei matoma rizika.

Naudingi vadovybės peržiūros rodikliai:

• Šį ketvirtį gautų kritinių CSAF saugumo pranešimų skaičius
• Procentinė dalis, susieta su SBOM komponentais
• VEX būsenų skaičius ir amžius pagal „paveikta“, „nepaveikta“, „ištaisyta“ ir „tiriama“
• Pradelstos „tiriama“ bylos
• Tiekėjų saugumo pranešimai be pakankamų paveiktos versijos duomenų
• Kritiniai pažeidžiamumai, priimti kaip patvirtintos išimtys
• Laikas nuo saugumo pranešimo priėmimo iki VEX sprendimo
• Laikas nuo sprendimo „paveikta“ iki taisymo
• Bylų su galimu poveikiu asmens duomenims skaičius
• Paskelbtų klientų saugumo pranešimų skaičius

Šie rodikliai padeda vadovybei užduoti geresnius klausimus. Kurie tiekėjai nepateikia veiksmingų pažeidžiamumų duomenų? Kurie produktai turi ilgiausius taisymo terminus? Kurios komandos palieka tyrimus atvirus? Kurie pažeidžiamumai gali paveikti asmens duomenis arba kritines funkcijas?

Dažniausi šalintini nesėkmių modeliai

Pirmoji nesėkmė – SBOM atitikmens traktavimas kaip išnaudojamumo analizės. Komponento atitikmuo yra signalas, o ne išvada.

Antroji nesėkmė – „nepaveikta“ naudojimas be pagrindimo. Auditoriai paklaus kodėl. Ar kodo kelias buvo nepasiekiamas? Ar pažeidžiama funkcija buvo išjungta? Ar versija buvo kita? Ar komponentas naudotas tik kūrimo metu? Ar išvadą patvirtino produkto saugumo funkcija?

Trečioji nesėkmė – leidimas būsenai „tiriama“ likti atvirai. Ši būsena naudinga tik turint savininką, terminą ir laikinas kontrolės priemones.

Ketvirtoji nesėkmė – tiekėjų valdysenos atskyrimas nuo pažeidžiamumų valdysenos. Tiekėjų sutartyse turi būti reikalaujama laiku atskleisti pažeidžiamumus, nustatyti reagavimo terminus, pataisų diegimo įpareigojimus, saugumo pranešimų turinį ir įrodymų palaikymą.

Penktoji nesėkmė – asmens duomenų ir klientų komunikacijos ignoravimas. Pažeidžiamumui, galinčiam atskleisti asmens duomenis, reikia GDPR vertinimo. Patvirtintam produkto pažeidžiamumui, galinčiam paveikti klientus, reikia koordinuoto atskleidimo disciplinos. Finansinių paslaugų priklausomybei gali reikėti DORA incidento analizės.

Šeštoji nesėkmė – silpnas įrodymų išsaugojimas. Zenith Blueprint 23 žingsnyje, kontrolėje 5.28, įspėja, kad įrodymai dažnai lieka nepastebėti:

„tai, ką galite įrodyti, yra taip pat svarbu kaip tai, kas iš tikrųjų įvyko“

Šis sakinys tiksliai apibūdina 2026 m. realybę. Saugumo komandos ne tik taiso pažeidžiamumus. Jos įrodo, kad sprendimai buvo savalaikiai, grindžiami rizika ir kontroliuojami.

Tolesni žingsniai audituojamiems pažeidžiamumų įrodymams

Jei jūsų organizacija jau turi SBOM, kitas brandos žingsnis nėra dar viena apskaitos skaičiuoklė. Tai pažeidžiamumų būsenos, tiekėjų saugumo pranešimų ir atskleidimo įrodymų valdysena.

Pradėkite nuo keturių veiksmų:

1. Įtraukite CSAF ir VEX priėmimą į pažeidžiamumų valdymo procedūrą.
2. Apibrėžkite patvirtinimo kriterijus būsenoms „paveikta“, „nepaveikta“, „ištaisyta“ ir „tiriama“.
3. Susiekite VEX įrašus su ISVS rizikų registru, tiekėjų registru, turto apskaita, SBOM saugykla ir incidentų procesu.
4. Išbandykite procesą su vienu nesenu kritiniu saugumo pranešimu ir parenkite auditui tinkamą įrodymų paketą.

Clarysec gali padėti tai greitai įgyvendinti naudojant Zenith Blueprint, Zenith Controls ir aktualų politikų rinkinį, įskaitant Pažeidžiamumų ir pataisų valdymo politiką, Pažeidžiamumų ir pataisų valdymo politiką – MVĮ, Taikomųjų programų saugumo reikalavimų politiką – MVĮ, Saugaus kūrimo politiką, Įrodymų rinkimo ir kriminalistikos politiką – MVĮ ir Koordinuoto pažeidžiamumų atskleidimo politiką.

Laimintis 2026 m. klausimas nėra „Ar turime SBOM?“ Jis yra „Ar galime kiekvienam rimtam saugumo pranešimui tiksliai įrodyti, kaip nustatėme pažeidžiamumo būseną, tvarkėme riziką ir komunikavome rezultatą?“

Užsisakykite Clarysec vertinimą arba paprašykite aktualaus politikų rinkinio, kad VEX ir CSAF paverstumėte auditui tinkamais pažeidžiamumų įrodymais dar prieš kitam kritiniam saugumo pranešimui pasiekiant jūsų valdybą.