VEX és CSAF: auditálható sérülékenységi bizonyítékok

A 07:40-kor érkező tájékoztató, amelyből az SBOM igazgatósági ügy lesz

2026 elején, egy kedd reggelen 07:40-kor Anya, egy gyorsan növekvő fintech platform információbiztonsági vezetője azt látja, hogy kritikus beszállítói tájékoztató érkezik CSAF formátumban. Egy széles körben használt nyílt forráskódú könyvtárban távoli kódfuttatási sérülékenységet találtak. A szoftveranyagjegyzék (SBOM) megerősíti, hogy a könyvtár be van ágyazva a zászlóshajónak számító fizetésfeldolgozó alkalmazásba, két belső szolgáltatásba és egy kiszervezett analitikai komponensbe.

08:10-re már folyamatosan rezeg a telefonja. A mérnöki csapat tudni akarja, hogy a sérülékeny függvény elérhető-e. A megfelelőségi terület azt kérdezi, érinti-e ez az ISO/IEC 27001:2022, NIS2 vagy DORA követelményeket. A jogi terület azt vizsgálja, hogy a Cyber Resilience Act előírhat-e ügyfél- vagy hatósági kommunikációt. Egy igazgatósági tag, aki nemrég képzést kapott az NIS2 szerinti vezetői elszámoltathatóságról, felteszi azt a kérdést, amely mindenkiben felmerül:

Érintettek vagyunk?

Az első mérnöki válasz műszakilag helytálló: a csomag jelen van, de a sérülékeny függvényt éles környezetben valószínűleg nem hívják meg. 2026-ban ez a válasz nem elegendő.

Az igazgatóság bizonyítékot vár. Az ügyfelek egyértelmű választ akarnak. A beszerzés tudni akarja, hogy a beszállító teljesítette-e szerződéses közzétételi kötelezettségeit. Az adatvédelmi tisztviselő azt kérdezi, előfordulhat-e személyes adatok kitettsége. Egy ISO 27001 auditor nem fogadja el megőrzött bizonyítékként azt, hogy „a fejlesztő ezt mondta”. Egy DORA-auditor elvárja, hogy a sérülékenység kapcsolódjon az IKT-eszközökhöz, kritikus funkciókhoz és harmadik felektől való függőségekhez.

Itt szűnik meg a VEX és a CSAF pusztán technikai formátumnak lenni, és válik irányítási infrastruktúrává.

A CSAF, a Common Security Advisory Framework, úgy strukturálja a sérülékenységi tájékoztatókat, hogy az emberek és a gépek egyaránt feldolgozhassák az érintett termékeket, verziókat, helyesbítési útmutatást, hivatkozásokat és státuszinformációkat. A VEX, a Vulnerability Exploitability eXchange, a döntési réteget biztosítja. Megmutatja az érdekelt feleknek, hogy egy ismert sérülékenység ténylegesen kihasználható-e egy adott termékben, szolgáltatásban vagy környezetben.

A gyakorlati VEX-státuszok egyszerűek: érintett, nem érintett, javított és kivizsgálás alatt. A mögöttük álló irányítás azonban nem egyszerű. Minden státuszhoz bizonyíték, felelős, indoklás, jóváhagyás és felülvizsgálati kiváltó esemény szükséges.

A megfelelőségi hiányosság ma már nem az SBOM-ok hiánya. Sok szervezetnek már vannak SBOM-jai. A hiányosság annak bizonyítása, hogy az egyes sérülékenységi tájékoztatókat hogyan triázsolták, ki hagyta jóvá a státuszdöntést, milyen bizonyíték támasztotta alá a „nem érintett” következtetést, hogyan priorizálták a helyesbítő intézkedéseket, amikor a termék „érintett” volt, és hogyan őrizte meg a szervezet ezt a nyomvonalat auditorok, szabályozó hatóságok, ügyfelek és a vezetés számára.

A Clarysec a VEX-et és a CSAF-ot az IBIR működési modell részeként kezeli. A Zenith Blueprint: auditor 30 lépéses útiterve keretében ez a kockázatkezelés, a beszállítói biztonság, a technikai kontrollok és a bizonyítéki szakaszok körébe tartozik. A Zenith Controls: keresztmegfelelőségi útmutató ugyanezt a témát az ISO/IEC 27001:2022 kontrollokkal, az IKT ellátási lánc biztonságával, a sérülékenységkezeléssel, a bizonyítékkezeléssel, valamint az NIS2, DORA, GDPR és NIST elvárásokkal kapcsolja össze.

Miért jelez az SBOM, miközben a VEX bizonyítékot hoz létre

Az SBOM komponenslista. Megmutatja, mi található egy termékben vagy szolgáltatásban. Amikor egy CVE megjelenik az egyik komponensben, az SBOM azt jelzi, hogy Ön érintett lehet.

Ez a jel értékes, de nem következtetés.

Egy érett szoftverkörnyezet több ezer SBOM-alapú sérülékenységi találatot generálhat. Ezek közül sok valódi kockázat. Sok azonban nem kihasználható, mert a sérülékeny kódot nem szállítják, nem importálják, nem érhető el, nincs konfigurálva, nincs kitéve nem megbízható bemenetnek, vagy kompenzáló kontrollok mérséklik. Ha nincs formális folyamat a vizsgálat rögzítésére, a csapatok általában két hibás mintázat egyikébe esnek.

Az első a triázs miatti kifáradás. A mérnökök minden sérülékenységi találatot azonos sürgősséggel követnek, még akkor is, ha az adott komponens csak összeállítási időben használt függőség, inaktív kódútvonal vagy rétegzett kontrollokkal védett, kizárólag belső funkció.

A második a dokumentálatlan kockázatelfogadás. A csapatok rövid megjegyzésekkel zárják a jegyeket, például „nem alkalmazható” vagy „téves pozitív”. Ez hatékonynak tűnhet, de auditori szemmel kontrollálatlan döntés. Szabályozói nézőpontból pedig kezeletlen sérülékenységnek tűnhet.

A VEX és a CSAF ezt azzal oldja meg, hogy a sérülékenységi zajt strukturált, auditálható sérülékenységi bizonyítékká alakítja.

Egy igazolható VEX- és CSAF-irányítási folyamat öt kérdésre ad választ:

1. Megkaptuk vagy azonosítottuk a tájékoztatót?
2. Leképeztük azt termékekre, eszközökre, beszállítókra, ügyfelekre és személyesadat-áramlásokra?
3. Meghatározott kritériumok alapján állapítottuk meg a sérülékenységi státuszt?
4. Dokumentáltuk a döntést, a bizonyítékot, a felelőst, a jóváhagyást és a felülvizsgálati kiváltó eseményt?
5. A kockázat alapján végrehajtottuk a helyesbítő intézkedést, közzétettünk információt, nyomon követtük az ügyet vagy megőriztük a bizonyítékokat?

A „nem érintett” és a „figyelmen kívül hagyott” közötti különbség a bizonyíték.

A VEX „nem érintett” státuszát indoklással kell alátámasztani, például azzal, hogy a sérülékeny komponens nincs jelen, a sérülékeny verzió nincs telepítve, a sérülékeny kódútvonal nem fut le, a sérülékeny konfiguráció le van tiltva, vagy kompenzáló kontroll akadályozza meg a kihasználást. A „kivizsgálás alatt” státuszhoz határidőhöz kötött utánkövetés kell, nem válhat feladatlista-temetővé. A „javított” státusznak javításra, kockázatcsökkentő intézkedésre, verziófrissítésre, teszteredményre és bevezetési bejegyzésre kell mutatnia. Az „érintett” státusznak kockázatkezelésbe, helyesbítő intézkedési tervezésbe, beszállítói értesítésbe, ügyfélkommunikációba, valamint ahol releváns, incidens- vagy adatvédelmi incidens-értékelési munkafolyamatokba kell kerülnie.

A Clarysec irányítási modellje VEX-státuszdöntésekhez

Minden CSAF-tájékoztatót és VEX-nyilatkozatot kontrollált nyilvántartásként kell kezelni az IBIR-ben, nem elszigetelt mérnöki artefaktumként. A munkafolyamat működhet GRC-platformban, sérülékenységkezelési eszközben, jegykezelő rendszerben, forráskód-kezelési munkafolyamatban vagy Clarysec bizonyítéki munkafüzetben. A lényeg az, hogy a státusz, a bizonyíték, a jóváhagyás és a kockázatkezelés összekapcsolva maradjon.

Ez a táblázat egyszerűnek tűnik, de megváltoztatja a kontrollkörnyezetet. A „nem érintett” nyilatkozat egy adott termékre és környezetre vonatkozó mini kockázati döntéssé válik. A „javított” státusz összekapcsolja a sérülékenységkezelést a változáskezeléssel és a teszteléssel. Az „érintett” státusz kezelést, eszkalációt és lehetséges közzétételt indít el. A „kivizsgálás alatt” státusz látható, határidőhöz kötött kockázatot ad a vezetésnek.

A Zenith Blueprint ezt a szemléletet erősíti meg a 13. lépésben, amely a kockázatkezelési tervezésről és az alkalmazhatósági nyilatkozatról szól. Kifejti, hogy a kontrollokra vonatkozó döntéseket kockázatkezeléssel, jogi vagy szerződéses követelményekkel, hatálybeli relevanciával és szervezeti kontextussal kell indokolni:

„Az SoA munkalapon minden kontrollt jelöljön „Igen” (alkalmazható) vagy „Nem” (nem alkalmazható) értékkel. Adjon meg indoklást/megjegyzést.”

A VEX esetében a „nem érintett” ugyanezt a fegyelmet követi. Nem alkalmi jegyzárás. Indokolt döntés, amelynek ki kell állnia a felülvizsgálatot.

A Zenith Blueprint 19. lépése a technikai sérülékenységkezeléssel foglalkozik:

„Maradjon naprakész a szoftvereket és hardvereket érintő új biztonsági hibákkal kapcsolatban (például beszállítói riasztások, CVE-hírcsatornák stb. útján). Értékelje, melyek relevánsak (használjuk-e ezt a szoftvert? mennyire kritikus a hiba?), és haladéktalanul alkalmazzon javításokat vagy kockázatcsökkentő intézkedéseket.”

A CSAF segít strukturált tájékoztatók fogadásában. Az SBOM-ok segítenek meghatározni a komponens jelenlétét. A VEX segít dokumentálni a kihasználhatóságot és a státuszt. A döntést az IBIR irányítja.

Szabályzati bizonyíték a kritikus tájékoztató érkezése előtt

Egy VEX-program kudarcot vall, ha az első kritikus tájékoztató még a szerepkörök, kritériumok és bizonyítékkövetelmények meghatározása előtt érkezik. A szabályzatoknak előre meg kell határozniuk a sérülékenységek befogadását, eszkalációját, rögzítését, a beszállítói kötelezettségeket, a kivételkezelést és a bizonyítékok megőrzését.

KKV-k esetében a Sérülékenység- és javításkezelési szabályzat - KKV rögzíti a felügyeleti kötelezettséget:

„Figyelemmel kíséri a rendszerek sérülékenységeit és az elérhető javításokat beszállítói riasztások, fenyegetettségi tájékoztatók és operációsrendszer-szintű értesítések felhasználásával”

Ez a szerepkörök és felelősségek közül származó, 4.2.1. szabályzati pont közvetlenül alkalmazható a CSAF-befogadásra. A CSAF-tájékoztatók olyan beszállítói vagy ökoszisztéma-szintű sérülékenységi tájékoztatók, amelyeket figyelni, korrelálni és triázsolni kell.

Ugyanez a KKV-szabályzat meghatározza az auditkészségi elvárásokat:

„Pontos nyilvántartásokat kell vezetni az alkalmazott javításokról, a nyitott problémákról és a kivételekről az auditra való felkészültség biztosítása érdekében”

A célkitűzések közül származó, 3.4. szabályzati pont az a hely, ahol a VEX többé válik technikai fájlnál. Ha egy csapat azért nem telepít javítást, mert a termék „nem érintett”, akkor ehhez a kivételhez bizonyíték, jóváhagyás és visszakövethetőség szükséges.

Vállalati környezetek esetében a Sérülékenység- és javításkezelési szabályzat egyértelmű:

„Kövesse nyomon a fenyegetettségi tájékoztatókat (pl. CVE, CISA KEV, beszállítói közlemények), és eszkalálja a kritikus sérülékenységeket.”

Ez a szerepkörök és felelősségek közül származó, 4.5.1. szabályzati pont támogatja a CSAF, CVE, beszállítói közlemények és exploit-információk strukturált befogadási csatornáját. Emellett eszkalációt ír elő, ha egy VEX-státusz kritikus termék esetében „érintett” vagy „kivizsgálás alatt”.

A vállalati szabályzat azt is kimondja:

„Minden kritikus és magas kockázatú sérülékenységet rögzíteni kell az ISMS kockázati nyilvántartásban, és nyomon kell követni mindaddig, amíg meg nem történik a helyesbítő intézkedés, vagy amíg jóváhagyott kivétel nem fedi le.”

Ez az irányítási követelmények közül származó, 5.3. szabályzati pont a megfelelési horgony. Egy kritikus CVE-re vonatkozó VEX „nem érintett” nyilatkozat csak akkor igazolható, ha bizonyítékkal alátámasztott, jóváhagyott kivételként kezelik. Egy VEX „javított” nyilatkozat csak akkor zárja le a kört, ha a helyesbítő intézkedést ellenőrizték.

A kockázati pontozáshoz szintén kontextus kell. Ugyanez a szabályzat hivatkozik a következőre:

„Kockázatértékelés (CVSS, eszközkritikusság és fenyegetettségi információk alapján)”

A kockázatkezelés és kivételek közül származó, 7.2.2. szabályzati pont támogatja a kombinált triázsmodellt. A CVSS önmagában nem elegendő. Egy kritikus identitáskomponensben aktívan kihasznált közepes súlyosságú sérülékenység sürgősebb lehet, mint egy kritikus CVSS-pontszámú, de el nem érhető kódban lévő probléma.

Az alkalmazásbiztonsági és biztonságos fejlesztési szabályzatok ugyanezt a fegyelmet kiterjesztik a mérnöki munkára és a beszállítókra. Az Alkalmazásbiztonsági követelmények szabályzata - KKV előírja, hogy a csapatok kövessék nyomon:

„az ismert sérülékenységeket és a helyesbítő intézkedések státuszát.”

A szabályzat végrehajtásának követelményei közül származó, 6.4.2.3. szabályzati pont közvetlenül leképezhető a VEX-státuszokra. Ugyanez a szabályzat előírja, hogy a megállapodások:

„határozzák meg a sérülékenység-feltárásra, válaszidőkre és javítások telepítésére vonatkozó kötelezettségeket.”

Az irányítási követelmények közül származó, 5.3.2. szabályzati pontból gyakorlati beszállítói záradék lesz: időben kell tájékoztatókat biztosítani, azonosítani kell az érintett verziókat, ahol lehetséges VEX-státuszt kell kiadni, meg kell határozni a helyesbítő intézkedési határidőket, és támogatni kell az ügyféloldali közzétételt.

Vállalati biztonságos fejlesztés esetén a Biztonságos fejlesztési szabályzat elvárja:

„Ismert sérülékenységek vizsgálata (CVE-k, OSS Index stb.)”

Az irányítási követelmények közül származó, 5.4.3. szabályzati pont meghatározott mechanizmust ad a mérnöki csapatnak a tájékoztatók komponensekhez való illesztésére és a VEX-elemzés elindítására.

Amikor egy sérülékenység incidenssé vagy potenciális jogi üggyé válik, a bizonyítékok fegyelmezett kezelése alapvető. A Bizonyítékgyűjtési és forenzikai szabályzat - KKV kimondja:

„Minden incidenshez egyszerű bizonyítéklánc-naplót (pl. Excel-fájlt vagy sablondokumentumot) kell vezetni.”

Az irányítási követelmények közül származó, 5.3.1. szabályzati pont a rutinszerű VEX-triázs és az incidensszintű bizonyítékkezelés közötti határ. Ha kihasználás gyanúja merül fel, a naplóknak, tájékoztatói nyilvántartásoknak, elemzési jegyzeteknek, kommunikációknak és forenzikus artefaktumoknak visszakövethetőnek kell lenniük.

A VEX és a CSAF leképezése ISO 27001, NIS2, DORA, GDPR és CRA követelményekre

A legerősebb VEX-programok nem önálló biztonságmérnöki projektek. Be vannak illesztve abba a kontrollrendszerbe, amelyet a szervezet már használ.

Az ISO/IEC 27001:2022 szerint az IBIR-nek figyelembe kell vennie az érdekelt feleket, a jogi és szerződéses kötelezettségeket, valamint a más szervezetekkel fennálló interfészeket és függőségeket. Ez a hatálylogika alapvető a VEX szempontjából, mert a beszállítói tájékoztatók, ügyfélvállalások, nyílt forráskódú komponensek és kiszervezett szolgáltatások mind hatással vannak a sérülékenységi döntésekre.

A legrelevánsabb A melléklet szerinti kontrollok közé tartozik az 5.19 információbiztonság a beszállítói kapcsolatokban, az 5.20 információbiztonság kezelése a beszállítói megállapodásokban, az 5.21 információbiztonság kezelése az IKT ellátási láncban, az 5.22 beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése, az 5.28 bizonyítékgyűjtés és a 8.8 technikai sérülékenységek kezelése. A 8.25–8.29 biztonságos fejlesztési kontrollok szintén relevánsak, ha a szervezet szoftvert vagy digitális termékeket fejleszt.

Az NIS2 növeli az irányítási nyomást. Az Article 21 megfelelő technikai, operatív és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, incidenskezelést, üzletmenet-folytonosságot, ellátási lánc biztonságát, biztonságos beszerzést, fejlesztést és karbantartást, sérülékenységkezelést és közzétételt, kontrollhatékonyságot, kiberhigiéniát, kriptográfiát, HR-biztonságot, hozzáférés-szabályozást, eszközkezelést és hitelesítést. Az Article 20 előírja, hogy a vezető testületek hagyják jóvá és felügyeljék a kiberbiztonsági kockázatkezelési intézkedéseket. Ez alkalmassá teszi a VEX-mutatókat az igazgatósági jelentéstételre.

A DORA 2025. január 17-től alkalmazandó a hatálya alá tartozó pénzügyi szervezetekre. IKT-kockázatkezelési keretrendszert, IKT-eszközök, sérülékenységek, függőségek és IKT harmadik fél szolgáltatások azonosítását és osztályozását, incidenskezelést, rezilienciatesztelést, harmadik fél kockázatkezelést és vezetői felügyeletet ír elő. Pénzügyi szervezeteknél a VEX-nyilvántartások különösen hasznosak, amikor egy beszállítói tájékoztatót kritikus vagy fontos funkciókhoz, szerződéses kötelezettségekhez és incidensbesoroláshoz kell kötni.

A GDPR akkor lép be, amikor a kihasználás személyes adatokat érinthet. Egy sérülékeny API, könyvtár vagy szolgáltatás, amely ügyfél-nyilvántartásokat tehet ki, értékelést igényel a bizalmasság, sértetlenség, rendelkezésre állás és incidensbejelentési kritériumok alapján. Egy VEX „nem érintett” következtetés támogathatja azt a döntést, hogy nincs szükség bejelentésre, de csak akkor, ha a szervezet be tudja mutatni, miért nem történt személyesadat-sértés.

A Cyber Resilience Act termékszintű irányítást ad hozzá. Ahogy a CRA-kötelezettségek fokozatosan hatályba lépnek, a gyártóknak és más gazdasági szereplőknek ismételhető sérülékenységkezelési, biztonsági frissítési, koordinált közzétételi és bizonyítéki folyamatokra van szükségük. A CSAF strukturálhatja a tájékoztatókat. A VEX tisztázhatja, mely termékek és verziók érintettek, javítottak vagy nem érintettek.

Mit ad hozzá a Clarysec keresztmegfelelőségi útmutatója

A Zenith Controls azért értékes, mert a technikai munkát auditori elvárásokhoz és átfedő keretrendszerekhez rendeli. A VEX és CSAF esetében három terület a legfontosabb: az IKT ellátási lánc biztonsága, a technikai sérülékenységkezelés és a bizonyítékgyűjtés.

Az IKT ellátási lánc biztonságánál a Zenith Controls az ISO/IEC 27002:2022 5.21 kontrollját „információbiztonság kezelése az IKT ellátási láncban” kontrollként azonosítja. Kifejti, hogy az 5.21 a beszállítói kapcsolatokra vonatkozó 5.19 és 5.20 kontrollokat IKT-specifikus kockázatokra terjeszti ki, beleértve a nem biztonságos szoftverkomponenseket és a harmadik féltől származó vagy nyílt forráskódú könyvtárakat. Kapcsolódik a biztonságos mérnöki munkához, biztonságos kódoláshoz, biztonsági teszteléshez, hozzáférés-szabályozáshoz, bizonyítékgyűjtéshez, biztonságos fejlesztési életciklushoz és kiszervezett fejlesztéshez.

Pontosan itt működik a CSAF és a VEX. A beszállítói tájékoztató nem pusztán egy üzenet a beszállítótól. A beszállító kiberbiztonsági gyakorlatának bizonyítéka. A beszállítói VEX-nyilatkozat nem pusztán kényelmi elem. Támogathatja a beszerzést, a kellő gondosságot, a nyomon követést és az ügyféloldali kockázati döntéseket.

A technikai sérülékenységkezelésnél a Zenith Controls a 8.8 kontrollt „technikai sérülékenységek kezelése” kontrollként azonosítja. A kontrollt megelőző jellegűnek minősíti, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, és a fenyegetés- és sérülékenységkezeléshez kapcsolódik. Azt is rögzíti, hogy a sérülékenységkezelés kapcsolódik a kártékony kód elleni védelemhez, konfigurációkezeléshez, változáskezeléshez, fenyegetettségi információkhoz és felügyelethez.

A Zenith Controls egyik különösen hasznos VEX-irányítási megállapítása:

„A hatékony sérülékenységkezelés valós fenyegetések alapján priorizál. A fenyegetettségi információk megmutatják, mely sérülékenységeket használják ki aktívan, és ezzel irányítják a javítások priorizálását.”

Ez a különbség a nyers SBOM-illesztés és a kockázatalapú VEX-triázs között. A jelenlét önmagában nem elég. A kihasználhatóságnak, eszközkritikusságnak, kitettségnek és fenyegetési aktivitásnak kell formálnia a döntést.

A bizonyítékoknál a Zenith Controls az 5.28 kontrollt, a „bizonyítékgyűjtést” helyesbítő kontrollként azonosítja, amely az észleléshez és reagáláshoz kapcsolódik. Az 5.28 kontrollt az incidensreagálással, naplózással, felügyelettel és eseményjelentéssel köti össze. A bizonyítékkezelést az ISO/IEC 27037:2012 szabványhoz is rendeli, amely a digitális bizonyítékok azonosításával, gyűjtésével, beszerzésével és megőrzésével foglalkozik.

Ha egy sérülékenység pusztán elméleti, a rutinszerű VEX-nyilvántartások elegendők lehetnek. Ha kihasználás gyanúja merül fel, a szervezetnek át kell lépnie az incidensszintű bizonyítékkezelésbe. A naplóknak, beszállítói kommunikációknak, ügyfélértesítéseknek, javítási bejegyzéseknek és forenzikus artefaktumoknak sértetlenségre, megőrzésre és visszakövethetőségre van szükségük.

Gyakorlati VEX bizonyítékcsomag a riasztástól a lezárásig

Térjünk vissza Anya fintech platformjához. CSAF-tájékoztató érkezik egy kritikus sérülékenységről a lib-common-utils könyvtárban, amely szerepel a fizetési átjáró SBOM-jában. Fegyelmezett reagálás esetén egy bizonyítékcsomag jön létre, nem szétszórt Slack-üzenetek és képernyőképek.

1. lépés: Tájékoztató-befogadási nyilvántartás létrehozása

Nyisson sérülékenységi ügyet az IBIR bizonyíték-nyomonkövető rendszerében. Csatolja a CSAF-tájékoztatót, a CVE-hivatkozást, a beszállítói közleményt, az SBOM-találatot és az érintett eszközök listáját. Jelöljön ki sérülékenység-felelőst és üzleti rendszergazdát. Kapcsolja össze a fizetési szolgáltatást az ügyfélhatással, személyes adatokkal, pénzügyi feldolgozással és működési kritikussággal.

Szabályzati alap: a Sérülékenység- és javításkezelési szabályzat előírja a tájékoztatók figyelését és a kritikus sérülékenységek eszkalálását. ISO alap: A melléklet 8.8 kontroll. NIS2 alap: sérülékenységkezelés és biztonságos karbantartás. DORA alap: IKT-sérülékenységek azonosítása és incidenskezelési felkészültség.

2. lépés: Előzetes státusz beállítása kivizsgálás alatt állóra

A kezdeti státusz gyakran legyen „kivizsgálás alatt”, különösen kritikus tájékoztatók esetén. Állítson be döntési határidőt, például 24 órát külsőleg elérhető vagy kritikus szolgáltatásoknál. Rögzítse az átmeneti kontrollokat, például fokozott felügyeletet, ideiglenes funkciókorlátozásokat vagy WAF-szabályokat. Ez megakadályozza, hogy egy kritikus tájékoztató kezeletlen feladatlistába tűnjön el.

3. lépés: Kihasználhatósági elemzés elvégzése

A mérnöki csapatnak gyakorlati kérdésekre kell válaszolnia:

• Jelen van a sérülékeny verzió éles környezetben?
• A sérülékeny függvényt importálják, meghívják vagy el lehet érni?
• Engedélyezve van a sérülékeny konfiguráció?
• A komponens ki van téve nem megbízható bemenetnek?
• Szükséges hitelesítés, mielőtt a sérülékeny útvonal elérhető lenne?
• Hatékonyak a kompenzáló kontrollok?
• Van aktív kihasználás vagy hiteles fenyegetettségi információ?
• A kihasználás érinthet személyes adatokat, pénzügyi tranzakciókat vagy a szolgáltatás rendelkezésre állását?

Anya esetében a statikus elemzés megerősíti, hogy a komponens jelen van, de a sérülékeny függvényt a fizetési átjáró nem hívja meg. Éles környezetben nincs végrehajtási útvonal. A csapat bizonyítékokkal alátámasztott „nem érintett” VEX-nyilatkozatot készít.

Ha az elemzés azt mutatta volna, hogy egy hitelesített adminisztrátori feladat elérheti a sérülékeny függvényt, a helyes státusz „érintett” lenne, nem „nem érintett”. A csapatnak ekkor kockázatkezelési tervet kellene létrehoznia, változásjegyet kellene nyitnia, javítást vagy kockázatcsökkentő intézkedést kellene alkalmaznia, és a státuszt csak ellenőrzés után frissíthetné „javított”-ra.

4. lépés: Az ügy összekapcsolása a kockázati nyilvántartással és a beszállítói bejegyzéssel

A kritikus és magas kockázatú ügyeket rögzíteni kell az IBIR kockázati nyilvántartásban, kivéve ha bizonyítékkal alátámasztott, jóváhagyott kivétellel lezárják őket. A beszállítói tájékoztatókat szintén össze kell kapcsolni a beszállítói nyilvántartással, szerződéses kötelezettségekkel és felügyeleti nyilvántartásokkal.

Ez támogatja a Zenith Blueprint 23. lépését, amely arra utasítja a szervezeteket, hogy gyűjtsék össze a beszállítókat, osztályozzák őket hozzáférés és operatív kontroll szerint, építsék be a biztonsági elvárásokat a szerződésekbe, és határozzák meg a beszállítói változások nyomon követési eljárásait.

5. lépés: A javítás ellenőrzése vagy a kivétel jóváhagyása

„Javított” státusz esetén csatolja a javított verziót, a változásbejegyzést, a CI/CD-folyamat eredményét, a függőségvizsgálatot, a konténerkép lenyomatát, a bevezetési bizonyítékot és a regressziós tesztet. „Nem érintett” esetén csatolja a kódútvonal-elemzést, a konfigurációs bizonyítékot, a verzióbizonyítékot, a kompenzáló kontroll bizonyítékát és a jóváhagyást.

Ha az ügyfelek saját üzemeltetésű verziókat használnak, vagy a sérülékenység külső felhasználókat érinthet, koordinálni kell a kommunikációt. A Koordinált sérülékenység-feltárási szabályzat adja a modellt:

„Ha egy megerősített sérülékenység ügyfeleket vagy szolgáltatáshasználókat érinthet, a kommunikációs csapatnak a VRT irányítása alatt biztonsági tájékoztatót kell készítenie. A tájékoztatónak tartalmaznia kell a probléma áttekintését, az exploit-részletek közzététele nélkül, az érintett termékeket vagy verziókat, a kockázatcsökkentési útmutatást vagy a javítás letöltésére vonatkozó utasításokat, valamint a támogatási kapcsolattartási adatokat.”

A végrehajtási követelmények közül származó, 6.8. szabályzati pont közvetlenül leképezhető a CSAF-közzétételi fegyelemre.

6. lépés: Bizonyítékok megőrzése, ha kihasználás gyanúja merül fel

Ha a naplók kihasználási kísérleteket mutatnak, át kell lépni a sérülékenységkezelésből az incidensreagálásba és bizonyítékgyűjtésbe. Indítson bizonyítéklánc-naplót, őrizze meg a naplókat, rögzítse a SIEM-lekérdezéseket, exportálja a releváns eseményeket, szükség esetén készítsen pillanatképet az érintett rendszerekről, és dokumentálja, ki kezelte az egyes artefaktumokat. Kapcsolja az incidensügyet a VEX-nyilvántartáshoz.

Mit fognak kérni az auditorok és szabályozó hatóságok

Az auditorok nem egyformán tesztelik a VEX- és CSAF-irányítást. Egyetlen bizonyítékcsomagnak több nézőpontot is ki kell szolgálnia.

A Zenith Controls olyan auditmódszertani útmutatást tartalmaz, amely illeszkedik ehhez a táblázathoz. Az IKT ellátási lánc biztonsága esetén az ISO/IEC 19011 és ISO/IEC 27007 alapján dolgozó auditorok megvizsgálják a beszerzési szabályzatokat, ajánlatkérési sablonokat és beszállítókezelési folyamatokat, hogy ellenőrizzék az IKT-specifikus biztonsági követelményeket. Mintát vesznek a szerződésekből biztonságos fejlesztésre, sérülékenység-feltárásra és szoftverhitelességi záradékokra.

A technikai sérülékenységkezelésnél az auditorok áttekintik a sérülékenységkezelési szabályzatot, a vizsgálati gyakoriságot, az eszközlefedettséget, a kockázatalapú priorizálást, a helyesbítő intézkedési határidőket és a felelősségi köröket. A bizonyítékgyűjtésnél tesztelik, hogy valós incidensekben követték-e a bizonyítékláncot, a biztonságos tárolást és a megőrzést.

Ezért a VEX-irányítás soha nem érhet véget a státuszcímkénél. A címke az összefoglaló. A bizonyítéki nyomvonal maga a kontroll.

Vezetői mutatók, amelyek a VEX-et igazgatóság elé vihetővé teszik

Az ISO/IEC 27001:2022 teljesítményértékelést, belső auditot és vezetőségi felülvizsgálatot ír elő. Az NIS2 vezetői felügyeletet követel meg. A DORA az IKT-kockázatok irányítását írja elő. A VEX és a CSAF olyan mutatókat hoz létre, amelyek a mérnöki munkát felsővezetői kockázati láthatósággá fordítják le.

Hasznos vezetőségi felülvizsgálati mutatók:

• A negyedévben beérkezett kritikus CSAF-tájékoztatók száma
• Az SBOM-komponensekhez illesztett tájékoztatók aránya
• A VEX-státuszok száma és életkora érintett, nem érintett, javított és kivizsgálás alatt kategóriában
• Lejárt határidejű „kivizsgálás alatt” ügyek
• Olyan beszállítói tájékoztatók, amelyek nem tartalmaznak elegendő érintettverzió-adatot
• Jóváhagyott kivételként elfogadott kritikus sérülékenységek
• A tájékoztató befogadásától a VEX-döntésig eltelt idő
• Az érintett döntéstől a helyesbítő intézkedésig eltelt idő
• Potenciális személyesadat-hatással járó ügyek száma
• Kiadott ügyféltájékoztatók száma

Ezek a mutatók segítenek a vezetésnek jobb kérdéseket feltenni. Mely beszállítók nem adnak használható sérülékenységi adatokat? Mely termékeknél a leghosszabbak a helyesbítési idők? Mely csapatok hagynak nyitva kivizsgálásokat? Mely sérülékenységek érinthetnek személyes adatokat vagy kritikus funkciókat?

Megszüntetendő gyakori hibaminták

Az első hiba az SBOM-illesztés kihasználhatósági elemzésként való kezelése. Egy komponens-találat jel, nem következtetés.

A második hiba a „nem érintett” használata indoklás nélkül. Az auditorok meg fogják kérdezni, miért. Elérhetetlen volt a kódútvonal? Letiltották a sérülékeny funkciót? Más volt a verzió? A komponenst csak összeállítási időben használták? A következtetést jóváhagyta a termékbiztonsági funkció?

A harmadik hiba, ha a „kivizsgálás alatt” nyitva marad. Ez a státusz csak felelőssel, határidővel és átmeneti kontrollokkal hasznos.

A negyedik hiba a beszállítói irányítás elválasztása a sérülékenységkezelés irányításától. A beszállítói szerződéseknek elő kell írniuk az időben történő sérülékenység-feltárást, válaszidőket, javításkezelési kötelezettségeket, tájékoztatói tartalmat és bizonyítéktámogatást.

Az ötödik hiba a személyes adatok és ügyfélkommunikáció figyelmen kívül hagyása. Egy személyes adatokat kitettségnek kitehető sérülékenység GDPR-értékelést igényel. Egy megerősített terméksérülékenység, amely ügyfeleket érinthet, koordinált közzétételi fegyelmet igényel. Egy pénzügyi szolgáltatási függőség DORA szerinti incidenselemzést igényelhet.

A hatodik hiba a gyenge bizonyítékmegőrzés. A Zenith Blueprint a 23. lépésben, az 5.28 kontrollnál figyelmeztet arra, hogy a bizonyítékokat gyakran figyelmen kívül hagyják:

„amit bizonyítani tud, legalább annyira számít, mint ami ténylegesen történt”

Ez a mondat foglalja össze a 2026-os valóságot. A biztonsági csapatok nemcsak sérülékenységeket javítanak. Azt is bizonyítják, hogy a döntések időben, kockázatalapon és kontrolláltan születtek.

Következő lépések az auditálható sérülékenységi bizonyítékokhoz

Ha a szervezetének már vannak SBOM-jai, a következő érettségi lépés nem egy újabb leltári táblázat. A következő lépés a sérülékenységi státusz, a beszállítói tájékoztatók és a közzétételi bizonyítékok irányítása.

Kezdje négy intézkedéssel:

1. Vegye fel a CSAF- és VEX-befogadást a sérülékenységkezelési eljárásba.
2. Határozzon meg jóváhagyási kritériumokat az érintett, nem érintett, javított és kivizsgálás alatt státuszokhoz.
3. Kapcsolja össze a VEX-nyilvántartásokat az IBIR kockázati nyilvántartással, beszállítói nyilvántartással, eszköznyilvántartással, SBOM-adattárral és incidensfolyamattal.
4. Tesztelje a folyamatot egy közelmúltbeli kritikus tájékoztatóval, és készítsen auditkész bizonyítékcsomagot.

A Clarysec segíthet ennek gyors bevezetésében a Zenith Blueprint, a Zenith Controls és a releváns szabályzatkészlet használatával, beleértve a Sérülékenység- és javításkezelési szabályzatot, a Sérülékenység- és javításkezelési szabályzat - KKV, az Alkalmazásbiztonsági követelmények szabályzata - KKV, a Biztonságos fejlesztési szabályzatot, a Bizonyítékgyűjtési és forenzikai szabályzat - KKV és a Koordinált sérülékenység-feltárási szabályzatot.

2026 nyertes kérdése nem az, hogy „Van SBOM-unk?” Hanem az, hogy „Minden súlyos tájékoztató esetén bizonyítani tudjuk-e pontosan, hogyan határoztuk meg a sérülékenységi státuszt, hogyan kezeltük a kockázatot, és hogyan kommunikáltuk az eredményt?”

Foglaljon Clarysec értékelést, vagy kérje a releváns szabályzat-eszköztárat, hogy a VEX-et és a CSAF-ot auditkész sérülékenységi bizonyítékokká alakítsa, mielőtt a következő kritikus tájékoztató eléri az igazgatóságot.