VEX un CSAF: auditējami ievainojamību pierādījumi

07:40 paziņojums, kas pārvērš SBOM par valdes jautājumu

2026. gada sākumā, otrdienas rītā plkst. 07:40, Anja, strauji augošas FinTech platformas informācijas drošības vadītāja (CISO), saņem kritisku piegādātāja paziņojumu CSAF formātā. Plaši izmantotā atvērtā pirmkoda bibliotēkā ir konstatēta attālinātas koda izpildes ievainojamība. Viņas programmatūras sastāva saraksts (SBOM) apstiprina, ka bibliotēka ir iekļauta galvenajā maksājumu apstrādes lietotnē, divos iekšējos pakalpojumos un ārpakalpojumā nodotā analītikas komponentā.

Plkst. 08:10 viņas tālrunis nepārtraukti vibrē. Inženierijas komanda vēlas zināt, vai ievainojamā funkcija ir sasniedzama. Atbilstības komanda vēlas zināt, vai tas skar ISO/IEC 27001:2022, NIS2 vai DORA. Juridiskais dienests jautā, vai Kibernoturības akts varētu prasīt saziņu ar klientiem vai iestādēm. Valdes loceklis, tikko apmācīts par NIS2 vadības atbildību, uzdod jautājumu, par kuru domā visi:

Vai mēs esam ietekmēti?

Pirmā inženieru atbilde tehniski ir godīga: pakotne pastāv, bet ievainojamā funkcija ražošanas vidē, iespējams, netiek izsaukta. 2026. gadā ar šādu atbildi nepietiek.

Valde vēlas pierādījumus. Klienti vēlas skaidru atbildi. Iepirkuma komanda vēlas zināt, vai piegādātājs ir izpildījis līgumiskos izpaušanas pienākumus. Datu aizsardzības speciālists (DPO) vēlas zināt, vai varētu tikt atklāti personas dati. ISO 27001 auditors kā saglabātus pierādījumus nepieņems frāzi “izstrādātājs tā teica”. DORA auditors sagaidīs, ka ievainojamība būs sasaistīta ar IKT aktīviem, kritiskām funkcijām un trešo pušu atkarībām.

Tieši šeit VEX un CSAF pārstāj būt tikai tehniski formāti un kļūst par pārvaldības infrastruktūru.

CSAF jeb Common Security Advisory Framework strukturē ievainojamību paziņojumus tā, lai cilvēki un sistēmas varētu apstrādāt ietekmētos produktus, versijas, novēršanas norādījumus, atsauces un statusa informāciju. VEX jeb Vulnerability Exploitability eXchange nodrošina lēmumu slāni. Tas iesaistītajām pusēm pasaka, vai zināma ievainojamība konkrētā produktā, pakalpojumā vai vidē faktiski ir izmantojama.

Praktiskie VEX statusa iznākumi ir vienkārši: ietekmēts, neietekmēts, novērsts un tiek izmeklēts. Pārvaldība aiz tiem nav vienkārša. Katram statusam ir nepieciešami pierādījumi, īpašnieks, pamatojums, apstiprinājums un pārskatīšanas ierosinātājs.

Atbilstības plaisa vairs nav SBOM neesamība. Daudzām organizācijām SBOM jau ir. Plaisa ir spējā pierādīt, kā katrs ievainojamības paziņojums tika izvērtēts, kurš apstiprināja statusa lēmumu, kādi pierādījumi pamatoja secinājumu “neietekmēts”, kā novēršana tika prioritizēta, ja produkts bija “ietekmēts”, un kā organizācija saglabāja šo audita pēdu auditoriem, regulatoriem, klientiem un vadībai.

Clarysec uzskata VEX un CSAF par daļu no IDPS darbības modeļa. Zenith Blueprint: auditora 30 soļu ceļvedī tas ietilpst risku pārvaldības, piegādātāju drošības, tehnoloģisko kontroles pasākumu un pierādījumu posmos. Zenith Controls: starpatbilstības ceļvedī šī pati tēma sasaista ISO/IEC 27001:2022 kontroles pasākumus ar IKT piegādes ķēdes drošību, ievainojamību pārvaldību, pierādījumu pārvaldību, NIS2, DORA, GDPR un NIST prasībām.

Kāpēc SBOM rada signālus, bet VEX rada pierādījumus

SBOM ir sastāvdaļu saraksts. Tas parāda, kas atrodas produktā vai pakalpojumā. Kad kādā no šīm sastāvdaļām parādās CVE, SBOM norāda, ka jūs, iespējams, esat ietekmēti.

Šis signāls ir vērtīgs, bet tas nav secinājums.

Nobriedusi programmatūras vide var ģenerēt tūkstošiem SBOM ievainojamību sakritību. Daudzas no tām ir reāli riski. Daudzas nav izmantojamas, jo ievainojamais kods netiek piegādāts, importēts, sasniegts, konfigurēts vai pakļauts neuzticamai ievadei, vai arī risku mazina kompensējošie kontroles pasākumi. Bez formāla procesa izmeklēšanas reģistrēšanai komandas parasti nonāk vienā no diviem nevēlamiem modeļiem.

Pirmais ir izvērtēšanas izdegšana. Inženieri ar vienādu steidzamību izmeklē katru ievainojamības sakritību, pat ja komponents ir būvēšanas laika atkarība, neaktīvs koda ceļš vai tikai iekšēji lietojama funkcija, ko aizsargā daudzslāņu kontroles pasākumi.

Otrais ir nedokumentēta riska pieņemšana. Komandas aizver pieteikumus ar īsiem komentāriem, piemēram, “nav piemērojams” vai “kļūdaini pozitīvs gadījums”. Tas var šķist efektīvi, taču auditoram tas ir nekontrolēts lēmums. Regulatoram tas var izskatīties pēc nepārvaldītas ievainojamības.

VEX un CSAF risina šo problēmu, pārvēršot ievainojamību troksni strukturētos, auditējamos ievainojamību pierādījumos.

Aizstāvams VEX un CSAF pārvaldības process atbild uz pieciem jautājumiem:

1. Vai mēs saņēmām vai identificējām paziņojumu?
2. Vai mēs to sasaistījām ar produktiem, aktīviem, piegādātājiem, klientiem un personas datu plūsmām?
3. Vai mēs noteicām ievainojamības statusu, izmantojot definētus kritērijus?
4. Vai mēs dokumentējām lēmumu, pierādījumus, īpašnieku, apstiprinājumu un pārskatīšanas ierosinātāju?
5. Vai mēs veicām novēršanu, izpaušanu, uzraudzību vai saglabājām pierādījumus, pamatojoties uz risku?

Atšķirība starp “neietekmēts” un “ignorēts” ir pierādījumi.

VEX statuss “neietekmēts” jāatbalsta ar pamatojumu, piemēram, ievainojamais komponents nav klātesošs, ievainojamā versija nav izvietota, ievainojamais koda ceļš netiek izpildīts, ievainojamā konfigurācija ir atspējota vai kompensējošs kontroles pasākums nepieļauj izmantošanu. Statusam “tiek izmeklēts” jābūt ar laikā ierobežotu turpmāko rīcību; tas nedrīkst kļūt par darbu uzkrājuma kapsētu. Statusam “novērsts” jānorāda uz ielāpu, mazināšanas pasākumu, versijas atjauninājumu, testēšanas rezultātu un izvietošanas ierakstu. Statusam “ietekmēts” jānonāk riska apstrādē, novēršanas plānošanā, piegādātāja informēšanā, klientu komunikācijā un, ja piemērojams, incidenta vai pārkāpuma izvērtēšanas darbplūsmās.

Clarysec pārvaldības modelis VEX statusa lēmumiem

Katrs CSAF paziņojums un VEX paziņojums IDPS ietvaros jāuzskata par kontrolētu ierakstu, nevis izolētu inženierijas artefaktu. Darbplūsma var atrasties GRC platformā, ievainojamību pārvaldības rīkā, pieteikumu sistēmā, pirmkoda kontroles darbplūsmā vai Clarysec pierādījumu darbgrāmatā. Būtiski ir tas, lai statuss, pierādījumi, apstiprinājums un riska apstrāde paliktu sasaistīti.

Šī tabula izskatās vienkārša, bet tā maina kontroles vidi. Paziņojums “neietekmēts” kļūst par nelielu riska lēmumu konkrētam produktam un videi. Statuss “novērsts” sasaista ievainojamību pārvaldību ar izmaiņu pārvaldību un testēšanu. Statuss “ietekmēts” iedarbina apstrādi, eskalāciju un iespējamu izpaušanu. Statuss “tiek izmeklēts” vadībai rada redzamu, laikā ierobežotu risku.

Zenith Blueprint nostiprina šo pieeju 13. solī par riska apstrādes plānošanu un Piemērojamības paziņojumu. Tajā skaidrots, ka lēmumi par kontroles pasākumiem jāpamato ar riska apstrādi, juridiskajām vai līgumiskajām prasībām, darbības jomas atbilstību un organizācijas kontekstu:

“SoA lapā katram kontroles pasākumam atzīmējiet ‘Jā’ (piemērojams) vai ‘Nē’ (nav piemērojams). Norādiet pamatojumu/piezīmes.”

VEX gadījumā “neietekmēts” ievēro to pašu disciplīnu. Tā nav formāla pieteikuma nejauša aizvēršana. Tas ir pamatots lēmums, kam jāiztur pārskatīšana.

Zenith Blueprint 19. solis apskata tehnisko ievainojamību pārvaldību:

“Sekojiet līdzi jaunām drošības kļūdām (izmantojot piegādātāju brīdinājumus, CVE plūsmas u. c.) jūsu programmatūrai un aparatūrai. Izvērtējiet, kuras ir atbilstošas (vai mēs izmantojam šo programmatūru? cik kritiska ir kļūda?), un savlaicīgi piemērojiet labojumus vai mazināšanas pasākumus.”

CSAF palīdz saņemt strukturētus paziņojumus. SBOM palīdz noteikt komponenta klātbūtni. VEX palīdz dokumentēt izmantojamību un statusu. Lēmumu pārvalda IDPS.

Politikas pierādījumi pirms kritiskā paziņojuma saņemšanas

VEX programma neizdodas, ja pirmais kritiskais paziņojums pienāk, pirms ir noteiktas lomas, kritēriji un pierādījumu prasības. Politikām jau iepriekš jādefinē ievainojamību saņemšana, eskalācija, reģistrēšana, piegādātāju pienākumi, izņēmumu pārvaldība un pierādījumu saglabāšana.

SME gadījumā Ievainojamību un ielāpu pārvaldības politika - SME nosaka uzraudzības pienākumu:

“Uzrauga sistēmas attiecībā uz ievainojamībām un pieejamajiem ielāpiem, izmantojot piegādātāju brīdinājumus, draudu izlūkošanas paziņojumus un operētājsistēmas paziņojumus”

Šis punkts no sadaļas Lomas un pienākumi, politikas punkts 4.2.1, ir tieši piemērojams CSAF saņemšanai. CSAF paziņojumi ir piegādātāju vai ekosistēmas ievainojamību paziņojumi, kas jāuzrauga, jāsasaista un jāizvērtē.

Tā pati SME politika nosaka auditgatavības prasības:

“Uzturēt precīzus ierakstus par piemērotajiem ielāpiem, neatrisinātajiem jautājumiem un izņēmumiem, lai nodrošinātu gatavība auditam”

No sadaļas Mērķi, politikas punkts 3.4, šeit VEX kļūst par ko vairāk nekā tehnisku datni. Ja komanda neievieš ielāpu, jo produkts ir “neietekmēts”, šim izņēmumam ir nepieciešami pierādījumi, apstiprinājums un izsekojamība.

Uzņēmuma vidēm Ievainojamību un ielāpu pārvaldības politika ir skaidra:

“Uzraudzīt draudu paziņojumus (piem., CVE, CISA KEV, piegādātāju biļetenus) un eskalēt kritiskās ievainojamības.”

No sadaļas Lomas un pienākumi, politikas punkts 4.5.1, šis punkts atbalsta strukturētu saņemšanas kanālu CSAF, CVE, piegādātāju biļeteniem un informācijai par izmantošanas aktivitāti. Tas arī prasa eskalāciju, ja VEX statuss kritiskam produktam ir “ietekmēts” vai “tiek izmeklēts”.

Uzņēmuma politika arī nosaka:

“Visas kritiskās un augsta riska ievainojamības jāreģistrē IDPS Riska reģistrā un jāuzrauga līdz to novēršanai vai līdz brīdim, kad tās sedz apstiprināts izņēmums.”

Šis punkts no sadaļas Pārvaldības prasības, politikas punkts 5.3, ir atbilstības enkurs. VEX paziņojums “neietekmēts” kritiskam CVE ir aizstāvams tikai tad, ja to apstrādā kā apstiprinātu izņēmumu ar pierādījumiem. VEX paziņojums “novērsts” noslēdz ciklu tikai tad, kad novēršana ir verificēta.

Risku vērtēšanai arī nepieciešams konteksts. Tā pati politika atsaucas uz:

“Riska novērtējumu (balstīts uz CVSS, aktīva kritiskumu, draudu izlūkošanu)”

No sadaļas Risku apstrāde un izņēmumi, politikas punkts 7.2.2, tas atbalsta kombinētu izvērtēšanas modeli. Ar CVSS vien nepietiek. Vidējas smaguma pakāpes ievainojamība, kas tiek aktīvi izmantota kritiskā identitātes komponentā, var būt steidzamāka nekā kritisks CVSS jautājums nesasniedzamā kodā.

Lietojumprogrammu un drošas izstrādes politikas paplašina to pašu disciplīnu inženierijā un piegādātāju pārvaldībā. Lietojumprogrammu drošības prasību politika - SME prasa komandām izsekot:

“zināmās ievainojamības un trūkumu novēršanas statusu.”

No sadaļas Politikas ieviešanas prasības, politikas punkts 6.4.2.3, tas precīzi kartējas uz VEX statusiem. Tā pati politika prasa vienošanās:

“noteikt pienākumus attiecībā uz ievainojamību izpaušanu, reaģēšanas laikiem un ielāpu uzstādīšanu.”

No sadaļas Pārvaldības prasības, politikas punkts 5.3.2, tas kļūst par praktisku piegādātāja klauzulu: nodrošināt savlaicīgus paziņojumus, identificēt ietekmētās versijas, pēc iespējas izdot VEX statusu, definēt novēršanas termiņus un atbalstīt klientu informēšanu.

Uzņēmuma drošas izstrādes vajadzībām Drošas izstrādes politika paredz:

“Zināmo ievainojamību skenēšanu (CVE, OSS Index u. c.)”

No sadaļas Pārvaldības prasības, politikas punkts 5.4.3, tas dod inženierijai definētu mehānismu paziņojumu sasaistīšanai ar komponentiem un VEX analīzes ierosināšanai.

Kad ievainojamība kļūst par incidentu vai potenciālu juridisku jautājumu, pierādījumu disciplīna kļūst būtiska. Digitālo pierādījumu iegūšanas un kriminālistikas politika - SME nosaka:

“Katram incidentam jāuztur vienkāršs pierādījumu glabāšanas ķēdes žurnāls (piem., Excel datne vai veidnes dokuments).”

No sadaļas Pārvaldības prasības, politikas punkts 5.3.1, šī ir robeža starp rutīnas VEX izvērtēšanu un incidenta līmeņa pierādījumu pārvaldību. Ja ir aizdomas par izmantošanu, žurnāliem, paziņojumu ierakstiem, analīzes piezīmēm, saziņai un digitālās kriminālistikas artefaktiem ir nepieciešama izsekojamība.

VEX un CSAF kartēšana uz ISO 27001, NIS2, DORA, GDPR un CRA

Spēcīgākās VEX programmas nav atsevišķi drošības inženierijas projekti. Tās ir kartētas uz kontroles sistēmu, ko organizācija jau izmanto.

Saskaņā ar ISO/IEC 27001:2022 IDPS jāņem vērā iesaistītās puses, juridiskie un līgumiskie pienākumi, saskarnes un atkarības ar citām organizācijām. Šī darbības jomas loģika ir būtiska VEX, jo piegādātāju paziņojumi, klientu saistības, atvērtā pirmkoda komponenti un ārpakalpojumi — tas viss ietekmē lēmumus par ievainojamībām.

Visatbilstošākie A pielikuma kontroles pasākumi ietver 5.19 Informācijas drošība piegādātāju attiecībās, 5.20 Informācijas drošības risināšana piegādātāju līgumos, 5.21 Informācijas drošības pārvaldība IKT piegādes ķēdē, 5.22 Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība, 5.28 Pierādījumu vākšana un 8.8 Tehnisko ievainojamību pārvaldība. Drošas izstrādes kontroles pasākumi 8.25 līdz 8.29 ir nozīmīgi arī tad, ja organizācija izstrādā programmatūru vai digitālus produktus.

NIS2 palielina pārvaldības spiedienu. Article 21 prasa atbilstošus tehniskos, darbības un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iepirkumu, izstrādi un uzturēšanu, ievainojamību apstrādi un izpaušanu, kontroles efektivitāti, kiberdrošības higiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un autentifikāciju. Article 20 prasa, lai vadības struktūras apstiprinātu un pārraudzītu kiberdrošības risku pārvaldības pasākumus. Tādēļ VEX metrika ir piemērota ziņošanai valdei.

DORA no 2025. gada 17. janvāra attiecas uz finanšu vienībām tās piemērošanas jomā. Tā prasa IKT risku pārvaldības ietvaru, IKT aktīvu, ievainojamību, atkarību un IKT trešo pušu pakalpojumu identificēšanu un klasificēšanu, incidentu pārvaldību, noturības testēšanu, trešo pušu risku pārvaldību un vadības pārraudzību. Finanšu vienībām VEX ieraksti ir īpaši noderīgi, ja piegādātāja paziņojums jāsasaista ar kritiskām vai svarīgām funkcijām, līgumiskajiem pienākumiem un incidentu klasifikāciju.

GDPR kļūst aktuāls, ja izmantošana var ietekmēt personas datus. Ievainojama API, bibliotēka vai pakalpojums, kas varētu atklāt klientu ierakstus, jāizvērtē pret konfidencialitātes, integritātes, pieejamības un paziņošanas par pārkāpumu kritērijiem. VEX secinājums “neietekmēts” var atbalstīt lēmumu nepaziņot, bet tikai tad, ja organizācija var parādīt, kāpēc personas datu aizsardzības pārkāpums nav noticis.

Kibernoturības akts papildina produkta pārvaldību. Pakāpeniski stājoties spēkā CRA pienākumiem, ražotājiem un citiem ekonomikas dalībniekiem ir nepieciešami atkārtojami ievainojamību apstrādes, drošības atjauninājumu, koordinētas izpaušanas un pierādījumu procesi. CSAF var strukturēt paziņojumus. VEX var precizēt, kuri produkti un versijas ir ietekmēti, novērsti vai neietekmēti.

Ko papildina Clarysec starpatbilstības ceļvedis

Zenith Controls ir vērtīgs, jo kartē tehnisko darbu uz audita gaidām un pārklājošiem ietvariem. VEX un CSAF gadījumā vissvarīgākās ir trīs jomas: IKT piegādes ķēdes drošība, tehnisko ievainojamību pārvaldība un pierādījumu vākšana.

IKT piegādes ķēdes drošībai Zenith Controls identificē ISO/IEC 27002:2022 kontroles pasākumu 5.21 kā “Informācijas drošības pārvaldība IKT piegādes ķēdē”. Tajā skaidrots, ka 5.21 paplašina piegādātāju attiecību kontroles pasākumus 5.19 un 5.20 uz IKT specifiskiem riskiem, tostarp nedrošiem programmatūras komponentiem un trešo pušu vai atvērtā pirmkoda bibliotēkām. Tas sasaistās ar drošu inženieriju, drošu kodēšanu, drošības testēšanu, piekļuves kontroli, pierādījumu vākšanu, drošas izstrādes dzīves ciklu un ārpakalpojuma izstrādi.

Tieši šeit darbojas CSAF un VEX. Piegādātāja paziņojums nav tikai ziņa no piegādātāja. Tas ir pierādījums piegādātāja kiberdrošības praksei. Piegādātāja VEX paziņojums nav tikai ērtība. Tas var atbalstīt iepirkumu, padziļināto pārbaudi, uzraudzību un klientu riska lēmumus.

Tehnisko ievainojamību pārvaldībai Zenith Controls identificē kontroles pasākumu 8.8 kā “Tehnisko ievainojamību pārvaldība”. Tas klasificē šo kontroles pasākumu kā preventīvu, kas atbalsta konfidencialitāti, integritāti un pieejamību un ir saistīts ar draudu un ievainojamību pārvaldību. Tajā arī norādīts, ka ievainojamību pārvaldība sasaistās ar aizsardzību pret ļaunprogrammatūru, konfigurāciju pārvaldību, izmaiņu pārvaldību, draudu izlūkošanu un uzraudzību.

Īpaši noderīgs Zenith Controls fragments VEX pārvaldībai ir šāds:

“Efektīva ievainojamību pārvaldība nosaka prioritātes, pamatojoties uz reāliem apdraudējumiem. Draudu izlūkošana norāda, kuras ievainojamības tiek aktīvi izmantotas, palīdzot noteikt ielāpu prioritāti.”

Tā ir atšķirība starp neapstrādātu SBOM sakritību un uz risku balstītu VEX izvērtēšanu. Klātbūtne vien nav pietiekama. Lēmumu nosaka izmantojamība, aktīva kritiskums, ekspozīcija un apdraudējuma aktivitāte.

Pierādījumiem Zenith Controls identificē kontroles pasākumu 5.28 “Pierādījumu vākšana” kā koriģējošu un saistītu ar atklāšanu un reaģēšanu. Tas sasaista 5.28 ar reaģēšanu uz incidentiem, žurnālfiksēšanu, uzraudzību un notikumu ziņošanu. Tas arī kartē pierādījumu pārvaldību uz ISO/IEC 27037:2012 digitālo pierādījumu identificēšanai, vākšanai, iegūšanai un saglabāšanai.

Ja ievainojamība ir tikai teorētiska, ar rutīnas VEX ierakstiem var pietikt. Ja ir aizdomas par izmantošanu, organizācijai jāpāriet uz incidenta pierādījumu pārvaldību. Žurnāliem, piegādātāju komunikācijai, klientu paziņojumiem, ielāpu ierakstiem un digitālās kriminālistikas artefaktiem ir nepieciešama integritāte, saglabāšana un izsekojamība.

Praktiska VEX pierādījumu pakete no brīdinājuma līdz slēgšanai

Atgriezīsimies pie Anjas FinTech platformas. CSAF paziņojums pienāk par kritisku ievainojamību lib-common-utils, kas parādās maksājumu vārtejas SBOM. Disciplinēta reakcija izveidotu vienu pierādījumu paketi, nevis izkaisītus Slack ziņojumus un ekrānuzņēmumus.

1. solis: izveidot paziņojuma saņemšanas ierakstu

Atveriet ievainojamības lietu IDPS pierādījumu izsekošanas rīkā. Pievienojiet CSAF paziņojumu, CVE atsauci, piegādātāja biļetenu, SBOM sakritību un ietekmēto aktīvu sarakstu. Piešķiriet ievainojamības īpašnieku un biznesa sistēmas īpašnieku. Sasaistiet maksājumu pakalpojumu ar ietekmi uz klientiem, personas datiem, finanšu apstrādi un darbības kritiskumu.

Politikas pamats: Ievainojamību un ielāpu pārvaldības politika prasa paziņojumu uzraudzību un kritisko ievainojamību eskalāciju. ISO pamats: A pielikuma kontroles pasākums 8.8. NIS2 pamats: ievainojamību apstrāde un droša uzturēšana. DORA pamats: IKT ievainojamību identificēšana un gatavība incidentiem.

2. solis: noteikt sākotnējo statusu “tiek izmeklēts”

Sākotnējam statusam bieži jābūt “tiek izmeklēts”, īpaši kritisku paziņojumu gadījumā. Nosakiet lēmuma termiņu, piemēram, 24 stundas ārēji eksponētiem vai kritiskiem pakalpojumiem. Reģistrējiet pagaidu kontroles pasākumus, piemēram, pastiprinātu uzraudzību, pagaidu funkcionalitātes ierobežojumus vai WAF noteikumus. Tas nepieļauj, ka kritisks paziņojums pazūd nepārvaldītā darbu uzkrājumā.

3. solis: veikt izmantojamības analīzi

Inženierijas komandai jāatbild uz praktiskiem jautājumiem:

• Vai ievainojamā versija atrodas ražošanas vidē?
• Vai ievainojamā funkcija ir importēta, izsaukta vai sasniedzama?
• Vai ievainojamā konfigurācija ir iespējota?
• Vai komponents ir pakļauts neuzticamai ievadei?
• Vai pirms ievainojamā ceļa sasniegšanas ir nepieciešama autentifikācija?
• Vai kompensējošie kontroles pasākumi ir efektīvi?
• Vai pastāv aktīva izmantošana vai ticama draudu izlūkošana?
• Vai izmantošana varētu ietekmēt personas datus, finanšu darījumus vai pakalpojumu pieejamību?

Anjas gadījumā statiskā analīze apstiprina, ka komponents ir klātesošs, bet maksājumu vārteja neizsauc ievainojamo funkciju. Ražošanas vidē nepastāv izpildes ceļš. Komanda sagatavo VEX paziņojumu “neietekmēts” ar atbalsta pierādījumiem.

Ja analīze būtu parādījusi, ka autentificēts administratora uzdevums var sasniegt ievainojamo funkciju, pareizais statuss būtu “ietekmēts”, nevis “neietekmēts”. Tad komandai būtu jāizveido riska apstrādes plāns, jāatver izmaiņu pieteikums, jāievieš ielāps vai jāpiemēro mazināšanas pasākums un jāatjaunina statuss uz “novērsts” tikai pēc verifikācijas.

4. solis: sasaistīt lietu ar Riska reģistru un piegādātāja ierakstu

Kritiskie un augsta riska gadījumi jāievada IDPS Riska reģistrā, ja vien tie netiek slēgti ar apstiprinātu, pierādījumos balstītu izņēmumu. Piegādātāju paziņojumi jāsasaista arī ar piegādātāju reģistru, līgumiskajiem pienākumiem un uzraudzības ierakstiem.

Tas atbalsta Zenith Blueprint 23. soli, kas uzdod organizācijām apkopot piegādātājus, klasificēt tos pēc piekļuves un darbības kontroles, iekļaut drošības prasības līgumos un noteikt uzraudzības procedūras piegādātāju izmaiņām.

5. solis: pārbaudīt labojumu vai apstiprināt izņēmumu

Statusam “novērsts” pievienojiet ielāpa versiju, izmaiņu ierakstu, CI/CD cauruļvada rezultātu, atkarību skenēšanu, konteinera attēla digest, izvietošanas pierādījumus un regresijas testu. Statusam “neietekmēts” pievienojiet koda ceļa analīzi, konfigurācijas pierādījumus, versijas pierādījumus, kompensējošo kontroles pasākumu pierādījumus un apstiprinājumu.

Ja klienti izmanto pašmitinātas versijas vai ievainojamība varētu ietekmēt ārējos lietotājus, koordinējiet komunikāciju. Koordinētas ievainojamību izpaušanas politika nodrošina modeli:

“Ja apstiprināta ievainojamība varētu ietekmēt klientus vai pakalpojumu lietotājus, Komunikācijas komandai VRT vadībā jāsagatavo drošības paziņojums. Paziņojumā jāiekļauj jautājuma pārskats, neizpaužot izmantošanas detaļas, ietekmētie produkti vai versijas, mazināšanas norādījumi vai ielāpa lejupielādes instrukcijas un atbalsta kontaktinformācija.”

No sadaļas Ieviešanas prasības, politikas punkts 6.8, tas tieši kartējas uz CSAF publicēšanas disciplīnu.

6. solis: saglabāt pierādījumus, ja ir aizdomas par izmantošanu

Ja žurnāli rāda izmantošanas mēģinājumus, pārejiet no ievainojamību apstrādes uz reaģēšanu uz incidentiem un pierādījumu vākšanu. Sāciet pierādījumu glabāšanas ķēdes žurnālu, saglabājiet žurnālus, reģistrējiet SIEM vaicājumus, eksportējiet attiecīgos notikumus, ja nepieciešams, izveidojiet ietekmēto sistēmu momentuzņēmumus un dokumentējiet, kurš rīkojās ar katru artefaktu. Sasaistiet incidenta lietu ar VEX ierakstu.

Ko prasīs auditori un regulatori

Auditori VEX un CSAF pārvaldību nepārbauda vienādi. Vienai pierādījumu paketei jāspēj apmierināt vairākus skatījumus.

Zenith Controls ietver audita metodoloģijas norādījumus, kas atbilst šai tabulai. IKT piegādes ķēdes drošībai auditori, kas izmanto ISO/IEC 19011 un ISO/IEC 27007, pārbaudīs iepirkuma politikas, RFP veidnes un piegādātāju pārvaldības procesus, lai verificētu IKT specifiskās drošības prasības. Viņi izlases veidā pārbaudīs līgumus par drošas izstrādes, ievainojamību izpaušanas un programmatūras autentiskuma klauzulām.

Tehnisko ievainojamību pārvaldībai auditori pārskata ievainojamību pārvaldības politiku, skenēšanas biežumu, aktīvu pārklājumu, uz risku balstītu prioritizāciju, novēršanas termiņus un atbildības. Pierādījumu vākšanai viņi pārbauda, vai reālos incidentos tika ievērota pierādījumu glabāšanas ķēde, droša glabāšana un saglabāšana.

Tāpēc VEX pārvaldībai nekad nevajadzētu beigties ar statusa marķējumu. Marķējums ir kopsavilkums. Pierādījumu audita pēda ir kontroles pasākums.

Vadības metrika, kas padara VEX piemērotu valdei

ISO/IEC 27001:2022 prasa veiktspējas izvērtēšanu, iekšējo auditu un vadības pārskatīšanu. NIS2 prasa vadības pārraudzību. DORA prasa IKT risku pārvaldību. VEX un CSAF rada metriku, kas pārvērš inženierijas darbu vadībai saprotamā riska redzamībā.

Noderīga vadības pārskatīšanas metrika ietver:

• Šajā ceturksnī saņemto kritisko CSAF paziņojumu skaits
• Procentuālā daļa, kas sasaistīta ar SBOM komponentiem
• VEX statusu skaits un vecums pēc kategorijām: ietekmēts, neietekmēts, novērsts un tiek izmeklēts
• Nokavētie “tiek izmeklēts” gadījumi
• Piegādātāju paziņojumi bez pietiekamiem datiem par ietekmētajām versijām
• Kritiskās ievainojamības, kas pieņemtas kā apstiprināti izņēmumi
• Laiks no paziņojuma saņemšanas līdz VEX lēmumam
• Laiks no lēmuma “ietekmēts” līdz novēršanai
• Gadījumu skaits ar potenciālu ietekmi uz personas datiem
• Izdoto klientu paziņojumu skaits

Šī metrika palīdz vadībai uzdot labākus jautājumus. Kuri piegādātāji nespēj nodrošināt izmantojamus ievainojamību datus? Kuriem produktiem ir visilgākie novēršanas laiki? Kuras komandas atstāj izmeklēšanas atvērtas? Kuras ievainojamības var ietekmēt personas datus vai kritiskas funkcijas?

Biežākie kļūmju modeļi, kas jānovērš

Pirmā kļūme ir SBOM sakritību uzskatīšana par izmantojamības analīzi. Komponenta sakritība ir signāls, nevis secinājums.

Otrā kļūme ir statusa “neietekmēts” izmantošana bez pamatojuma. Auditori jautās — kāpēc? Vai koda ceļš bija nesasniedzams? Vai ievainojamā funkcija bija atspējota? Vai versija bija atšķirīga? Vai komponents tika izmantots tikai būvēšanas laikā? Vai secinājumu apstiprināja produkta drošības komanda?

Trešā kļūme ir ļaut statusam “tiek izmeklēts” palikt atvērtam. Šis statuss ir lietderīgs tikai ar īpašnieku, termiņu un pagaidu kontroles pasākumiem.

Ceturtā kļūme ir piegādātāju pārvaldības nodalīšana no ievainojamību pārvaldības. Piegādātāju līgumos jāparedz savlaicīga ievainojamību izpaušana, reaģēšanas termiņi, ielāpu ieviešanas pienākumi, paziņojumu saturs un pierādījumu atbalsts.

Piektā kļūme ir personas datu un klientu komunikācijas ignorēšana. Ievainojamībai, kas varētu atklāt personas datus, ir nepieciešams GDPR izvērtējums. Apstiprinātai produkta ievainojamībai, kas varētu ietekmēt klientus, ir nepieciešama koordinētas izpaušanas disciplīna. Finanšu pakalpojuma atkarībai var būt nepieciešama DORA incidenta analīze.

Sestā kļūme ir vāja pierādījumu saglabāšana. Zenith Blueprint 23. solī, kontroles pasākumā 5.28, brīdina, ka pierādījumi bieži tiek atstāti novārtā:

“tas, ko varat pierādīt, ir tikpat svarīgi kā tas, kas faktiski notika”

Šis teikums raksturo 2026. gada realitāti. Drošības komandas ne tikai labo ievainojamības. Tās pierāda, ka lēmumi bija savlaicīgi, uz risku balstīti un kontrolēti.

Nākamie soļi auditējamu ievainojamību pierādījumu izveidei

Ja jūsu organizācijai jau ir SBOM, nākamais brieduma solis nav vēl viena uzskaites izklājlapa. Tas ir pārvaldības ieviešana pār ievainojamību statusu, piegādātāju paziņojumiem un izpaušanas pierādījumiem.

Sāciet ar četrām darbībām:

1. Pievienojiet CSAF un VEX saņemšanu savai ievainojamību pārvaldības procedūrai.
2. Definējiet apstiprināšanas kritērijus statusiem ietekmēts, neietekmēts, novērsts un tiek izmeklēts.
3. Sasaistiet VEX ierakstus ar savu IDPS Riska reģistru, piegādātāju reģistru, aktīvu uzskaiti, SBOM repozitoriju un incidentu procesu.
4. Pārbaudiet procesu ar vienu nesenu kritisku paziņojumu un sagatavojiet auditam gatavu pierādījumu paketi.

Clarysec var palīdzēt to ātri ieviest, izmantojot Zenith Blueprint, Zenith Controls un attiecīgo politiku komplektu, tostarp Ievainojamību un ielāpu pārvaldības politiku, Ievainojamību un ielāpu pārvaldības politiku - SME, Lietojumprogrammu drošības prasību politiku - SME, Drošas izstrādes politiku, Digitālo pierādījumu iegūšanas un kriminālistikas politiku - SME un Koordinētas ievainojamību izpaušanas politiku.

2026. gada izšķirošais jautājums nav “Vai mums ir SBOM?” Tas ir “Vai mēs par katru nopietnu paziņojumu varam pierādīt, kā tieši noteicām ievainojamības statusu, apstrādājām risku un paziņojām rezultātu?”

Rezervējiet Clarysec izvērtēšanu vai pieprasiet attiecīgo politiku rīkkopu, lai pārvērstu VEX un CSAF par auditam gataviem ievainojamību pierādījumiem, pirms nākamais kritiskais paziņojums nonāk līdz jūsu valdei.