VEX a CSAF: auditovatelné důkazy o zranitelnostech

Bezpečnostní oznámení v 07:40, které ze SBOM udělá téma pro řídicí orgán

V úterý ráno v 07:40 na začátku roku 2026 vidí Anya, ředitelka informační bezpečnosti rychle rostoucí fintech platformy, kritické bezpečnostní oznámení dodavatele ve formátu CSAF. Ve široce používané open-source knihovně byla nalezena zranitelnost umožňující vzdálené spuštění kódu. Její softwarový kusovník (SBOM) potvrzuje, že knihovna je vložena do klíčové aplikace pro zpracování plateb, dvou interních služeb a outsourcované analytické komponenty.

V 08:10 jí už vibruje telefon. Vývojový tým chce vědět, zda je zranitelná funkce dosažitelná. Tým compliance chce vědět, zda se to týká ISO/IEC 27001:2022, NIS2 nebo DORA. Právní oddělení se ptá, zda by Cyber Resilience Act mohl vyžadovat komunikaci se zákazníky nebo orgány. Člen řídicího orgánu, čerstvě proškolený k odpovědnosti vedení podle NIS2, položí otázku, na kterou myslí všichni:

Jsme dotčeni?

První odpověď vývojového týmu je technicky poctivá: balíček existuje, ale zranitelná funkce se v produkčním prostředí možná nevolá. V roce 2026 taková odpověď nestačí.

Řídicí orgán chce důkaz. Zákazníci chtějí jasnou odpověď. Nákup chce vědět, zda dodavatel splnil smluvní povinnosti týkající se oznámení. DPO chce vědět, zda by mohlo dojít k expozici osobních údajů. Auditor ISO 27001 nepřijme „řekl to vývojář“ jako uchovávaný důkaz. Auditor DORA bude očekávat propojení zranitelnosti s ICT aktivy, kritickými funkcemi a závislostmi na třetích stranách.

Právě zde VEX a CSAF přestávají být technickými formáty a stávají se infrastrukturou správy a řízení.

CSAF, Common Security Advisory Framework, strukturuje bezpečnostní oznámení o zranitelnostech tak, aby lidé i stroje mohli zpracovávat dotčené produkty, verze, pokyny k nápravě, reference a informace o stavu. VEX, Vulnerability Exploitability eXchange, poskytuje rozhodovací vrstvu. Zainteresovaným stranám říká, zda je známá zranitelnost skutečně zneužitelná v konkrétním produktu, službě nebo prostředí.

Praktické výsledné stavy VEX jsou jednoduché: dotčeno, nedotčeno, opraveno a v šetření. Správa těchto stavů jednoduchá není. Každý stav vyžaduje důkazy, vlastníka, zdůvodnění, schválení a spouštěč přezkumu.

Mezera v souladu už nespočívá v absenci SBOM. Mnoho organizací dnes SBOM má. Mezera spočívá ve schopnosti prokázat, jak bylo každé bezpečnostní oznámení o zranitelnosti triážováno, kdo schválil rozhodnutí o stavu, jaké důkazy podpořily závěr „nedotčeno“, jak byla prioritizována náprava, když byl produkt „dotčen“, a jak organizace uchovala tuto stopu pro auditory, regulační orgány, zákazníky a vedení.

Clarysec chápe VEX a CSAF jako součást provozního modelu ISMS. V Zenith Blueprint: 30krokový plán auditora tato oblast spadá do fází řízení rizik, bezpečnosti dodavatelů, technických opatření a důkazů. V Zenith Controls: průvodce souladem napříč rámci stejné téma propojuje opatření ISO/IEC 27001:2022 se zabezpečením dodavatelského řetězce ICT, řízením zranitelností, nakládáním s důkazy a očekáváními podle NIS2, DORA, GDPR a NIST.

Proč SBOM vytváří signály, ale VEX vytváří důkazy

SBOM je seznam ingrediencí. Říká, co se nachází uvnitř produktu nebo služby. Když se u jedné z těchto ingrediencí objeví CVE, SBOM říká, že můžete být dotčeni.

Tento signál má hodnotu, ale není závěrem.

Vyspělé softwarové prostředí může generovat tisíce shod zranitelností ze SBOM. Mnohé představují skutečná rizika. Mnohé nejsou zneužitelné, protože zranitelný kód není dodáván, importován, dosažitelný, nakonfigurovaný, vystaven nedůvěryhodnému vstupu nebo je ošetřen kompenzačními opatřeními. Bez formálního procesu pro záznam šetření týmy obvykle sklouznou k jednomu ze dvou chybných vzorců.

Prvním je vyčerpání triáží. Inženýři řeší každou shodu zranitelnosti se stejnou naléhavostí, i když jde o závislost používanou pouze při sestavení, neaktivní větev kódu nebo funkci dostupnou jen interně a chráněnou vícevrstvou ochranou.

Druhým je nedokumentované přijetí rizika. Týmy zavírají tickety krátkými komentáři typu „nepoužitelné“ nebo „falešně pozitivní“. Může to působit efektivně, ale pro auditora jde o neřízené rozhodnutí. Pro regulační orgán to může vypadat jako neřízená zranitelnost.

VEX a CSAF tento problém řeší tím, že převádějí šum kolem zranitelností na strukturované, auditovatelné důkazy o zranitelnostech.

Obhajitelný proces správy VEX a CSAF odpovídá na pět otázek:

1. Přijali jsme nebo identifikovali bezpečnostní oznámení?
2. Namapovali jsme je na produkty, aktiva, dodavatele, zákazníky a toky osobních údajů?
3. Určili jsme stav zranitelnosti podle definovaných kritérií?
4. Zdokumentovali jsme rozhodnutí, důkazy, vlastníka, schválení a spouštěč přezkumu?
5. Provedli jsme nápravu, oznámení, monitorování nebo uchování důkazů na základě rizika?

Rozdíl mezi „nedotčeno“ a „ignorováno“ je v důkazech.

Stav VEX „nedotčeno“ musí být podpořen zdůvodněním, například že zranitelná komponenta není přítomna, zranitelná verze není nasazena, zranitelná cesta kódu se nevykonává, zranitelná konfigurace je vypnuta nebo kompenzační opatření brání zneužití. Stav „v šetření“ musí mít časově omezené navazující kroky, nikoli se stát hřbitovem backlogu. Stav „opraveno“ má odkazovat na záplatu, zmírnění, aktualizaci verze, výsledek testu a záznam o nasazení. Stav „dotčeno“ má vstoupit do ošetření rizik, plánování nápravy, oznámení dodavateli, komunikace se zákazníky a tam, kde je to relevantní, do pracovního postupu posouzení incidentu nebo porušení zabezpečení.

Model správy Clarysec pro rozhodování o stavu VEX

Každé bezpečnostní oznámení CSAF a každé prohlášení VEX musí být považováno za řízený záznam v rámci ISMS, nikoli za izolovaný inženýrský artefakt. Pracovní postup může být provozován v platformě GRC, nástroji pro řízení zranitelností, ticketovacím systému, pracovním postupu správy zdrojového kódu nebo v důkazním sešitu Clarysec. Podstatné je, aby stav, důkazy, schválení a ošetření rizik zůstaly propojené.

Tabulka vypadá jednoduše, ale mění prostředí opatření. Prohlášení „nedotčeno“ se stává dílčím rizikovým rozhodnutím pro konkrétní produkt a prostředí. Stav „opraveno“ propojuje řízení zranitelností s řízením změn a testováním. Stav „dotčeno“ spouští ošetření, eskalaci a případné oznámení. Stav „v šetření“ dává vedení viditelné, časově omezené riziko.

Zenith Blueprint posiluje tento přístup v kroku 13 k plánování ošetření rizik a Prohlášení o použitelnosti. Vysvětluje, že rozhodnutí o opatřeních mají být odůvodněna ošetřením rizik, právními nebo smluvními požadavky, relevancí rozsahu a organizačním kontextem:

„V listu SoA označte každé opatření jako ‚Ano‘ (použitelné) nebo ‚Ne‘ (nepoužitelné). Uveďte odůvodnění/poznámky.“

U VEX se stav „nedotčeno“ řídí stejnou disciplínou. Nejde o neformální uzavření ticketu. Jde o odůvodněné rozhodnutí, které musí obstát při přezkumu.

Krok 19 v Zenith Blueprint se věnuje technickému řízení zranitelností:

„Sledujte nové bezpečnostní chyby (prostřednictvím upozornění dodavatelů, CVE feedů apod.) pro svůj software a hardware. Posuďte, které jsou relevantní (používáme tento software? jak kritická je chyba?) a neprodleně aplikujte opravy nebo zmírňující opatření.“

CSAF pomáhá přijímat strukturovaná bezpečnostní oznámení. SBOM pomáhá určit přítomnost komponent. VEX pomáhá dokumentovat zneužitelnost a stav. ISMS řídí rozhodnutí.

Důkazy v politikách před příchodem kritického bezpečnostního oznámení

Program VEX selže, pokud první kritické bezpečnostní oznámení dorazí dříve, než existují role, kritéria a požadavky na důkazy. Politiky již musí definovat příjem zranitelností, eskalaci, záznamy, povinnosti dodavatelů, ošetření výjimek a uchování důkazů.

Pro SME stanoví Politika řízení zranitelností a záplat – SME povinnost monitorování:

„Monitoruje systémy z hlediska zranitelností a dostupných záplat s využitím upozornění dodavatelů, bezpečnostních oznámení z oblasti informací o hrozbách a oznámení operačního systému“

Toto ustanovení z části Role a odpovědnosti, článek politiky 4.2.1, se přímo vztahuje na příjem CSAF. Bezpečnostní oznámení CSAF jsou oznámení dodavatelů nebo ekosystému o zranitelnostech, která musí být monitorována, korelována a triážována.

Stejná politika pro SME stanoví očekávání týkající se připravenosti na audit:

„Udržujte přesné záznamy o aplikovaných záplatách, nevyřešených problémech a výjimkách, aby byla zajištěna připravenost na audit“

Z části Cíle, článek politiky 3.4, vyplývá, kde se VEX stává více než technickým souborem. Pokud tým nezáplatuje, protože produkt je „nedotčen“, tato výjimka vyžaduje důkazy, schválení a dohledatelnost.

Pro podniková prostředí je Politika řízení zranitelností a záplat výslovná:

„Monitorujte upozornění na hrozby (např. CVE, CISA KEV, bulletiny dodavatelů) a eskalujte kritické zranitelnosti.“

Z části Role a odpovědnosti, článek politiky 4.5.1, toto ustanovení podporuje strukturovaný příjmový kanál pro CSAF, CVE, bulletiny dodavatelů a informace o exploitech. Zároveň vyžaduje eskalaci, pokud je stav VEX u kritického produktu „dotčeno“ nebo „v šetření“.

Podniková politika také uvádí:

„Všechny kritické a vysoce rizikové zranitelnosti musí být zaznamenány v Registru rizik ISMS a monitorovány do doby nápravy nebo pokrytí schválenou výjimkou.“

Toto ustanovení z části Požadavky na správu a řízení, článek politiky 5.3, je kotvou souladu. Prohlášení VEX „nedotčeno“ u kritické CVE je obhajitelné pouze tehdy, je-li považováno za schválenou výjimku s důkazy. Prohlášení VEX „opraveno“ uzavírá smyčku pouze tehdy, je-li náprava ověřena.

Skórování rizik také potřebuje kontext. Stejná politika odkazuje na:

„Posouzení rizik (na základě CVSS, kritičnosti aktiva, informací o hrozbách)“

Z části Ošetření rizik a výjimky, článek politiky 7.2.2, toto podporuje kombinovaný model triáže. Samotné CVSS nestačí. Středně závažná zranitelnost aktivně zneužívaná v kritické komponentě identity může být naléhavější než problém s kritickým CVSS v nedosažitelném kódu.

Politiky aplikací a bezpečného vývoje rozšiřují stejnou disciplínu do vývoje a k dodavatelům. Politika požadavků na zabezpečení aplikací – SME vyžaduje, aby týmy sledovaly:

„známé zranitelnosti a stav nápravy.“

Z části Požadavky na implementaci politiky, článek politiky 6.4.2.3, se toto přesně mapuje na stavy VEX. Stejná politika vyžaduje, aby dohody:

„specifikovaly povinnosti týkající se oznamování zranitelností, reakčních dob a záplatování.“

Z části Požadavky na správu a řízení, článek politiky 5.3.2, se z toho stává praktické dodavatelské ustanovení: poskytovat včasná bezpečnostní oznámení, identifikovat dotčené verze, vydávat stav VEX tam, kde je to možné, definovat lhůty nápravy a podporovat oznámení zákazníkům.

Pro podnikový bezpečný vývoj očekává Politika bezpečného vývoje:

„Skenování známých zranitelností (CVE, OSS Index apod.)“

Z části Požadavky na správu a řízení, článek politiky 5.4.3, to dává vývojovému týmu definovaný mechanismus pro přiřazování bezpečnostních oznámení ke komponentám a spuštění analýzy VEX.

Když se zranitelnost stane incidentem nebo potenciální právní záležitostí, disciplína důkazů je zásadní. Politika sběru důkazů a forenzního šetření – SME uvádí:

„Pro každý incident musí být veden jednoduchý záznam o řetězci nakládání s důkazy (např. soubor Excel nebo šablona dokumentu).“

Z části Požadavky na správu a řízení, článek politiky 5.3.1, toto vymezuje hranici mezi rutinní triáží VEX a nakládáním s důkazy na úrovni incidentu. Pokud existuje podezření na zneužití, logy, záznamy bezpečnostních oznámení, analytické poznámky, komunikace a forenzní artefakty potřebují dohledatelnost.

Mapování VEX a CSAF na ISO 27001, NIS2, DORA, GDPR a CRA

Nejsilnější programy VEX nejsou samostatnými projekty bezpečnostního engineeringu. Jsou mapovány do systému opatření, který organizace již používá.

Podle ISO/IEC 27001:2022 musí ISMS zohlednit zainteresované strany, právní a smluvní povinnosti, rozhraní a závislosti s jinými organizacemi. Tato logika rozsahu je pro VEX zásadní, protože bezpečnostní oznámení dodavatelů, závazky vůči zákazníkům, open-source komponenty a outsourcované služby ovlivňují rozhodování o zranitelnostech.

Mezi nejrelevantnější opatření přílohy A patří 5.19 Bezpečnost informací ve vztazích s dodavateli, 5.20 Řešení bezpečnosti informací ve smlouvách s dodavateli, 5.21 Řízení bezpečnosti informací v dodavatelském řetězci ICT, 5.22 Monitorování, přezkum a řízení změn služeb dodavatelů, 5.28 Sběr důkazů a 8.8 Řízení technických zranitelností. Opatření bezpečného vývoje 8.25 až 8.29 jsou relevantní také tam, kde organizace vyvíjí software nebo digitální produkty.

NIS2 zvyšuje tlak na správu a řízení. Article 21 vyžaduje vhodná technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování, vývoje a údržby, řízení a oznamování zranitelností, účinnosti kontrol, kybernetické hygieny, kryptografie, bezpečnosti HR, řízení přístupu, správy aktiv a autentizace. Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření řízení rizik kybernetické bezpečnosti a vykonávaly nad nimi dohled. Díky tomu jsou metriky VEX vhodné pro reporting řídicím orgánům.

DORA se od 17. ledna 2025 vztahuje na finanční subjekty v rozsahu působnosti. Vyžaduje rámec řízení rizik v oblasti ICT, identifikaci a klasifikaci ICT aktiv, zranitelností, závislostí a služeb třetích stran v ICT, řízení incidentů, testování odolnosti, řízení rizik třetích stran a dohled vedení. Pro finanční subjekty jsou záznamy VEX zvlášť užitečné, když musí být bezpečnostní oznámení dodavatele navázáno na kritické nebo důležité funkce, smluvní povinnosti a klasifikaci incidentu.

GDPR vstupuje do hry, když by zneužití mohlo ovlivnit osobní údaje. Zranitelné rozhraní API, knihovna nebo služba, která by mohla vystavit záznamy zákazníků, vyžaduje posouzení podle kritérií důvěrnosti, integrity, dostupnosti a oznamování porušení zabezpečení. Závěr VEX „nedotčeno“ může podpořit rozhodnutí neoznamovat, ale pouze tehdy, pokud organizace dokáže doložit, proč nedošlo k porušení zabezpečení osobních údajů.

Cyber Resilience Act přidává produktovou správu. Jak se povinnosti CRA postupně zavádějí, výrobci a další hospodářské subjekty potřebují opakovatelné procesy řízení zranitelností, bezpečnostních aktualizací, koordinovaného oznamování a důkazů. CSAF může strukturovat bezpečnostní oznámení. VEX může vyjasnit, které produkty a verze jsou dotčeny, opraveny nebo nedotčeny.

Co přidává průvodce Clarysec napříč rámci souladu

Zenith Controls je cenný tím, že mapuje technickou práci na auditní očekávání a překrývající se rámce. Pro VEX a CSAF jsou nejdůležitější tři oblasti: zabezpečení dodavatelského řetězce ICT, technické řízení zranitelností a sběr důkazů.

Pro zabezpečení dodavatelského řetězce ICT Zenith Controls identifikuje opatření 5.21 normy ISO/IEC 27002:2022 jako „Řízení bezpečnosti informací v dodavatelském řetězci ICT“. Vysvětluje, že 5.21 rozšiřuje opatření vztahů s dodavateli 5.19 a 5.20 na rizika specifická pro ICT, včetně nezabezpečených softwarových komponent a knihoven třetích stran nebo open-source knihoven. Propojuje se s bezpečným inženýrstvím, bezpečným kódováním, bezpečnostním testováním, řízením přístupu, sběrem důkazů, životním cyklem bezpečného vývoje a outsourcovaným vývojem.

Právě zde CSAF a VEX působí. Bezpečnostní oznámení dodavatele není jen zpráva od dodavatele. Je to důkaz o praxi kybernetické bezpečnosti dodavatele. Prohlášení VEX dodavatele není jen pohodlný doplněk. Může podpořit pořizování, náležitou péči, monitorování a rozhodování zákazníka o rizicích.

Pro technické řízení zranitelností Zenith Controls identifikuje opatření 8.8 jako „Řízení technických zranitelností“. Klasifikuje opatření jako preventivní, podporující důvěrnost, integritu a dostupnost, a navázané na řízení hrozeb a zranitelností. Zároveň uvádí, že řízení zranitelností se propojuje s ochranou před škodlivým kódem, řízením konfigurace, řízením změn, informacemi o hrozbách a monitorováním.

Obzvlášť užitečná pasáž Zenith Controls pro správu VEX zní:

„Účinné řízení zranitelností stanovuje priority na základě reálných hrozeb. Informace o hrozbách ukazují, které zranitelnosti jsou aktivně zneužívány, a tím usměrňují prioritizaci záplat.“

To je rozdíl mezi prostým párováním SBOM a triáží VEX založenou na rizicích. Samotná přítomnost nestačí. Rozhodnutí musí utvářet zneužitelnost, kritičnost aktiva, expozice a aktivita hrozeb.

U důkazů Zenith Controls identifikuje opatření 5.28 „Sběr důkazů“ jako nápravné a navázané na detekci a reakci. Propojuje 5.28 s reakcí na incidenty, protokolováním, monitorováním a hlášením událostí. Zároveň mapuje nakládání s důkazy na ISO/IEC 27037:2012 pro identifikaci, sběr, získání a uchování digitálních důkazů.

Pokud je zranitelnost pouze teoretická, rutinní záznamy VEX mohou stačit. Pokud existuje podezření na zneužití, organizace musí přejít do režimu nakládání s důkazy incidentu. Logy, komunikace s dodavatelem, oznámení zákazníkům, záznamy o záplatách a forenzní artefakty potřebují integritu, uchování a dohledatelnost.

Praktický důkazní balíček VEX od upozornění po uzavření

Vraťme se k fintech platformě Anyi. Přichází bezpečnostní oznámení CSAF ke kritické zranitelnosti v lib-common-utils, která se podle SBOM nachází v platební bráně. Disciplinovaná reakce vytvoří jeden důkazní balíček, nikoli roztříštěné zprávy na Slacku a screenshoty.

Krok 1: Vytvořte záznam o příjmu bezpečnostního oznámení

Otevřete případ zranitelnosti v evidenci důkazů ISMS. Přiložte bezpečnostní oznámení CSAF, referenci CVE, bulletin dodavatele, shodu ze SBOM a seznam dotčených aktiv. Přiřaďte vlastníka zranitelnosti a vlastníka podnikového systému. Propojte platební službu s dopadem na zákazníky, osobní údaje, finanční zpracování a provozní kritičnost.

Základ v politice: Politika řízení zranitelností a záplat vyžaduje monitorování bezpečnostních oznámení a eskalaci kritických zranitelností. Základ v ISO: opatření přílohy A 8.8. Základ v NIS2: řízení zranitelností a bezpečná údržba. Základ v DORA: identifikace zranitelností ICT a připravenost na incidenty.

Krok 2: Nastavte předběžný stav na v šetření

Počáteční stav by měl často být „v šetření“, zejména u kritických bezpečnostních oznámení. Nastavte lhůtu pro rozhodnutí, například 24 hodin u externě vystavených nebo kritických služeb. Zaznamenejte dočasná opatření, například zvýšené monitorování, dočasná omezení funkcí nebo pravidla WAF. Tím zabráníte tomu, aby kritické bezpečnostní oznámení zmizelo v neřízeném backlogu.

Krok 3: Proveďte analýzu zneužitelnosti

Vývojový tým musí odpovědět na praktické otázky:

• Je zranitelná verze přítomna v produkčním prostředí?
• Je zranitelná funkce importována, volána nebo dosažitelná?
• Je zranitelná konfigurace povolena?
• Je komponenta vystavena nedůvěryhodnému vstupu?
• Je před dosažením zranitelné cesty vyžadována autentizace?
• Jsou kompenzační opatření účinná?
• Existuje aktivní zneužívání nebo důvěryhodné informace o hrozbách?
• Mohlo by zneužití ovlivnit osobní údaje, finanční transakce nebo dostupnost služby?

V případě Anyi statická analýza potvrzuje, že komponenta je přítomna, ale platební brána zranitelnou funkci nevolá. V produkčním prostředí neexistuje žádná cesta spuštění. Tým připraví prohlášení VEX „nedotčeno“ s podpůrnými důkazy.

Pokud by analýza ukázala, že autentizovaná administrátorská úloha může dosáhnout zranitelné funkce, správný stav by byl „dotčeno“, nikoli „nedotčeno“. Tým by následně vytvořil plán ošetření rizika, otevřel ticket změny, aplikoval záplatu nebo zmírnění a aktualizoval stav na „opraveno“ až po ověření.

Krok 4: Propojte případ s Registrem rizik a záznamem dodavatele

Kritické a vysoce rizikové případy musí být zapsány do Registru rizik ISMS, pokud nejsou uzavřeny schválenou a důkazně podloženou výjimkou. Bezpečnostní oznámení dodavatelů musí být také propojena s registrem dodavatelů, smluvními povinnostmi a záznamy monitorování.

To podporuje krok 23 Zenith Blueprint, který organizacím ukládá sestavit seznam dodavatelů, klasifikovat je podle přístupu a provozního řízení, zakotvit bezpečnostní očekávání ve smlouvách a definovat postupy monitorování změn u dodavatelů.

Krok 5: Ověřte opravu nebo schvalte výjimku

U stavu „opraveno“ přiložte verzi záplaty, záznam o změně, výsledek CI/CD pipeline, sken závislostí, digest obrazu kontejneru, důkaz o nasazení a regresní test. U stavu „nedotčeno“ přiložte analýzu cesty kódu, důkazy o konfiguraci, důkazy o verzi, důkazy o kompenzačním opatření a schválení.

Pokud zákazníci používají verze provozované u sebe nebo by zranitelnost mohla ovlivnit externí uživatele, koordinujte komunikaci. Politika koordinovaného oznamování zranitelností poskytuje model:

„Pokud by potvrzená zranitelnost mohla ovlivnit zákazníky nebo uživatele služeb, komunikační tým pod vedením VRT připraví bezpečnostní oznámení. Oznámení musí obsahovat přehled problému bez zveřejnění detailů exploitu, dotčené produkty nebo verze, pokyny ke zmírnění nebo instrukce ke stažení záplaty a kontaktní informace podpory.“

Z části Požadavky na implementaci, článek politiky 6.8, se toto přímo mapuje na disciplínu publikace CSAF.

Krok 6: Uchovejte důkazy, pokud existuje podezření na zneužití

Pokud logy ukazují pokusy o zneužití, přejděte od řízení zranitelnosti k reakci na incidenty a sběru důkazů. Zahajte záznam o řetězci nakládání s důkazy, uchovejte logy, zaznamenejte dotazy SIEM, exportujte relevantní události, v případě potřeby pořiďte snapshot dotčených systémů a zdokumentujte, kdo s každým artefaktem nakládal. Propojte případ incidentu se záznamem VEX.

Na co se budou ptát auditoři a regulační orgány

Auditoři netestují správu VEX a CSAF všichni stejným způsobem. Jeden důkazní balíček musí obstát z více pohledů.

Zenith Controls obsahuje metodické pokyny k auditu, které této tabulce odpovídají. U zabezpečení dodavatelského řetězce ICT auditoři používající ISO/IEC 19011 a ISO/IEC 27007 zkoumají nákupní politiky, šablony RFP a procesy řízení dodavatelů, aby ověřili požadavky na bezpečnost specifické pro ICT. Vzorkují smlouvy z hlediska doložek k bezpečnému vývoji, oznamování zranitelností a autentičnosti softwaru.

U technického řízení zranitelností auditoři přezkoumávají politiku řízení zranitelností, frekvenci skenování, pokrytí aktiv, prioritizaci podle rizika, lhůty nápravy a odpovědnosti. U sběru důkazů testují, zda byl u skutečných incidentů dodržen řetězec nakládání s důkazy, bezpečné uložení a uchování.

Proto by správa VEX nikdy neměla končit u stavového štítku. Štítek je shrnutí. Důkazní stopa je opatření.

Metriky pro vedení, díky nimž je VEX připraven pro řídicí orgán

ISO/IEC 27001:2022 vyžaduje hodnocení výkonnosti, interní audit a přezkoumání vedením. NIS2 vyžaduje dohled vedení. DORA vyžaduje správu rizik ICT. VEX a CSAF vytvářejí metriky, které převádějí inženýrskou práci do viditelnosti rizik pro vrcholové vedení.

Užitečné metriky pro přezkoumání vedením zahrnují:

• Počet kritických bezpečnostních oznámení CSAF přijatých v tomto čtvrtletí
• Procento shod s komponentami SBOM
• Počet a stáří stavů VEX podle kategorií dotčeno, nedotčeno, opraveno a v šetření
• Případy „v šetření“ po lhůtě
• Bezpečnostní oznámení dodavatelů bez dostatečných údajů o dotčených verzích
• Kritické zranitelnosti přijaté jako schválené výjimky
• Doba od příjmu bezpečnostního oznámení po rozhodnutí VEX
• Doba od rozhodnutí „dotčeno“ po nápravu
• Počet případů s potenciálním dopadem na osobní údaje
• Počet vydaných bezpečnostních oznámení zákazníkům

Tyto metriky pomáhají vedení klást lepší otázky. Kteří dodavatelé neposkytují použitelné údaje o zranitelnostech? Které produkty mají nejdelší doby nápravy? Které týmy nechávají šetření otevřená? Které zranitelnosti mohou ovlivnit osobní údaje nebo kritické funkce?

Běžné chybné vzorce, které je třeba odstranit

Prvním selháním je zaměňovat shodu ze SBOM za analýzu zneužitelnosti. Shoda komponenty je signál, nikoli závěr.

Druhým selháním je používat „nedotčeno“ bez zdůvodnění. Auditoři se zeptají proč. Byla cesta kódu nedosažitelná? Byla zranitelná funkce vypnuta? Byla verze jiná? Byla komponenta používána pouze při sestavení? Schválila závěr produktová bezpečnost?

Třetím selháním je nechat stav „v šetření“ otevřený. Tento stav je užitečný pouze s vlastníkem, lhůtou a dočasnými opatřeními.

Čtvrtým selháním je oddělovat řízení dodavatelů od řízení zranitelností. Smlouvy s dodavateli musí vyžadovat včasné oznamování zranitelností, reakční doby, povinnosti záplatování, obsah bezpečnostních oznámení a podporu důkazů.

Pátým selháním je ignorovat osobní údaje a komunikaci se zákazníky. Zranitelnost, která by mohla vystavit osobní údaje, vyžaduje posouzení podle GDPR. Potvrzená produktová zranitelnost, která by mohla ovlivnit zákazníky, vyžaduje disciplínu koordinovaného oznamování. Závislost finanční služby může vyžadovat analýzu incidentu podle DORA.

Šestým selháním je slabé uchování důkazů. Zenith Blueprint v kroku 23, opatření 5.28, upozorňuje, že důkazy jsou často opomíjeny:

„to, co dokážete prokázat, je stejně důležité jako to, co se skutečně stalo“

Tato věta vystihuje realitu roku 2026. Bezpečnostní týmy zranitelnosti nejen opravují. Prokazují, že rozhodnutí byla včasná, založená na rizicích a řízená.

Další kroky k auditovatelným důkazům o zranitelnostech

Pokud vaše organizace již má SBOM, dalším krokem vyspělosti není další tabulka evidence. Je jím správa stavu zranitelností, bezpečnostních oznámení dodavatelů a důkazů o oznamování.

Začněte čtyřmi kroky:

1. Přidejte příjem CSAF a VEX do svého postupu řízení zranitelností.
2. Definujte schvalovací kritéria pro stavy dotčeno, nedotčeno, opraveno a v šetření.
3. Propojte záznamy VEX se svým Registrem rizik ISMS, registrem dodavatelů, evidencí aktiv, repozitářem SBOM a procesem incidentů.
4. Otestujte proces na jednom nedávném kritickém bezpečnostním oznámení a vytvořte důkazní balíček připravený pro audit.

Clarysec vám může pomoci s rychlou implementací pomocí Zenith Blueprint, Zenith Controls a příslušné sady politik, včetně Politiky řízení zranitelností a záplat, Politiky řízení zranitelností a záplat – SME, Politiky požadavků na zabezpečení aplikací – SME, Politiky bezpečného vývoje, Politiky sběru důkazů a forenzního šetření – SME a Politiky koordinovaného oznamování zranitelností.

Vítězná otázka roku 2026 nezní „Máme SBOM?“ Zní: „Dokážeme u každého závažného bezpečnostního oznámení přesně prokázat, jak jsme určili stav zranitelnosti, ošetřili riziko a komunikovali výsledek?“

Objednejte si posouzení Clarysec nebo si vyžádejte příslušný balíček politik, abyste z VEX a CSAF udělali důkazy o zranitelnostech připravené pro audit dříve, než další kritické bezpečnostní oznámení dorazí k řídicímu orgánu.