Proč etičtí hackeři často chybují při hodnocení zranitelností

S hodnocením zranitelností pomocí standardu CVSS jste se na těchto stránkách mohli setkat již několikrát. Etičtí hackeři jej používají pro stanovení závažnosti zranitelnosti, kterou v hodnoceném systému nalezli, a firmy jej pak následně používají pro prioritizaci oprav.

Všichni jaksi předpokládají, že CVSS skóre je objektivní, konzistentní a že stejné zranitelnosti povedou u různých hodnotitelů ke stejnému nebo alespoň velmi podobnému výsledku. Jenže ono to tak jednoduché není.

V praxi se totiž ukazuje, že etický hacker, který dokáže zranitelnost najít a exploitovat, často nemusí být schopen přesně určit její povahu, správně ji pojmenovat a teprve následně zvolit odpovídající CVSS skóre. To je důležité. Problém totiž nemusí vzniknout až při samotném bodování. Může vzniknout už o krok dřív, při stanovení toho, co bylo vlastně nalezeno. A když je špatně diagnóza, skóre už ji většinou jen poslušně následuje. Problém má tedy hned tři vrstvy: klasifikační, kompetenční a metodickou. Pojďme se na ně podívat blíž.

Klasifikační problém: tester někdy neví, co vlastně našel

První problém nastává ve chvíli, kdy tester sice zranitelnost najde, dokáže ji demonstrovat, ale nepřesně určí její podstatu.

To je častější, než se zdá. Technický projev chyby totiž nemusí být totéž co její bezpečnostní význam. To, že aplikace něco umožní změnit, zapsat, zobrazit nebo obejít, ještě samo o sobě neříká, zda jde o nedostatečnou validaci vstupu, chybějící kontrolu integrity, chybu v řízení přístupu, porušení obchodní logiky, informační únik, nebo skutečné obejití autorizace.

Právě tady začíná první potíž. Tester často správně popíše, co se stalo, ale méně přesně určí, proč se to z hlediska bezpečnosti stalo a jaký typ zranitelnosti to vlastně představuje. Jinými slovy, umí nález vyvolat, ale nemusí ho umět správně diagnostikovat.

Rozdíl není akademická hra se slovíčky. Pokud tester špatně pojmenuje zranitelnost, obvykle ji začne špatně i hodnotit. Z chybné klasifikace vznikne chybný CVSS vektor, z něj chybné skóre a z něj nakonec chybná priorita opravy. Firma pak neřeší jen nepřesné číslo, ale celý řetězec špatně pochopeného nálezu.

Problém je v tom, že názvy zranitelností mají v reportech zvláštní váhu. „Authorization bypass“, „privilege escalation“, „sensitive data exposure“ nebo „business logic flaw“ nejsou jen štítky pro hezčí tabulku. Jsou to interpretační rámce. Říkají, co se podle testera stalo, jakou bezpečnostní vlastnost systém porušil a jak má organizace nález chápat.

Když je tento rámec zvolen špatně, posune se celé hodnocení. Jinak se hodnotí chyba, která umožní obejít řízení přístupu, jinak chyba, která přijme nevalidní vstup, a jinak chyba, která poruší očekávaný tok obchodní logiky. Podobný technický projev může mít různý bezpečnostní význam. A právě ten musí tester nejprve správně určit.

Tester tedy někdy neudělá chybu až ve skóre. Udělá ji už v diagnóze.

Kompetenční problém: tester ≠ hodnotitel

Etický hacker je odborník na hledání a exploitaci zranitelností. To ale automaticky neznamená, že je odborník na jejich analytické hodnocení. Není. A hlavní příčiny jsou následující:

• Tester si neprostudoval dokumentaci. CVSS 4.0 má desítky stran definic a k tomu ještě příklady použití. Většina testerů ale dokumentaci nečte celou a často jede podle intuice. To vede k tomu, že metodika je aplikována nepřesně nebo přímo špatně.
• Tester si splete technický projev chyby s jejím bezpečnostním významem. To, že aplikace umožní určitou akci, ještě automaticky neříká, zda jde o chybu validace, řízení přístupu, integrity dat, obchodní logiky nebo důvěrnosti informací. Bez přesného určení typu zranitelnosti se pak špatně stanovuje i CVSS vektor.
• Nikdo testerem stanovené skóre nevaliduje. V mnoha firmách probíhá proces tak, že tester najde zranitelnost, uvede ji do reportu a k ní doplní odpovídající CVSS skóre. Vše bez kontroly, peer review a zpětné vazby. Protože testerovi se věří. Přece kdo jiný než tester by měl skóre stanovit, že?
• Tester nedostává zpětnou vazbu. Bez zpětné vazby není možné zlepšovat konzistenci, sjednotit interpretace, naučit se nuance CVSS 4.0 a sladit se s ostatními testery.

Tester tak často ani neví, že hodnotí špatně. A chyby se opakují a kumulují. CVSS se pak v praxi snadno mění ze standardizovaného hodnocení v kvalifikovaný subjektivní odhad. Stanovení CVSS skóre totiž není o hackingu, ale o interpretaci definic, které sepsal FIRST. A to je úplně jiná disciplína než exploitace.

Že nejde jen o teoretickou námitku, ukazuje i studie publikovaná na arXiv. Autoři zkoumali CVSS hodnocení u 196 uživatelů a ve follow-up průzkumu s 59 účastníky zjistili, že 68 % respondentů dalo stejným zranitelnostem odlišná severity ratings. Jinými slovy: i když lidé hodnotí tytéž zranitelnosti podle stejného standardu, výsledky se mohou významně lišit.

To je pro praxi docela nepříjemná zpráva. Pokud se podle CVSS skóre prioritizují opravy, pak nekonzistentní skórování neznamená jen akademický problém. Znamená to, že se může opravovat něco jiného, než co by se opravovat mělo.

Metodický problém: CVSS skóre není metrické měření

I kdyby byl tester perfektně vyškolený, konzistentní a jeho výstupy byly pravidelně validovány, CVSS má problém v samotné povaze skórování.

CVSS pracuje s hodnotami jako Low, High, Present, None, Physical, Local nebo Network. Tyto hodnoty nejsou měřením v běžném metrickém smyslu. Neříkají, o kolik je jedna varianta horší než druhá. Říkají pouze, do jaké kategorie daná vlastnost zranitelnosti spadá.

CVSS tyto kategorie převádí na číselné hodnoty a následně je kombinuje ve výpočtu. To samo o sobě není problém, pokud výsledek chápeme jako konvenční skóre. Problém nastává ve chvíli, kdy se výsledné číslo začne interpretovat jako přesné měření rizika. Skóre 7.5 není o 50 % horší než skóre 5.0. Je to výsledek skórovacího modelu, nikoli měření v metrickém slova smyslu.

Jinak řečeno: CVSS může být užitečný jazyk pro popis technické závažnosti zranitelnosti. Není to ale měřicí přístroj. A už vůbec to není výpočet očekávané ztráty, pravděpodobnosti útoku nebo skutečného dopadu na konkrétní organizaci.

CVSS je tedy vhodné chápat jako heuristiku, nikoli jako metriku. Pomáhá strukturovat úvahu o zranitelnosti, ale nevyrábí objektivní pravdu. Číslo na konci vzorce vypadá přesvědčivě, ale pořád je závislé na interpretaci vstupních hodnot a na konstrukci samotného modelu.

Poznámka: Pro prioritizaci oprav bývá vhodnější EPSS než samotné CVSS, protože se snaží zachytit i pravděpodobnost reálného zneužití. Jenže ani EPSS není samospasitelný. U nových zranitelností, třeba ve webové aplikaci, mu často chybějí vstupní data, a tak nepomůže ani on.

Závěr

I kdyby měl tester perfektně nastudovanou dokumentaci FIRST, jeho výstupy byly validovány a byl dokonce ve shodě s ostatními hodnotiteli, výsledné skóre bude pořád jen pseudo-kvantitativní.

Etický hacker není automaticky dobrý hodnotitel CVSS. A někdy není ani dobrý analytik povahy zranitelnosti. Bez přesné klasifikace nálezu, validace a zpětné vazby je jeho CVSS skóre často nesprávné nebo alespoň nekonzistentní. A bohužel i při správné aplikaci definic je CVSS matematicky a interpretačně problematické, pokud se jeho výsledek používá jako přesné měření rizika.

CVSS 4.0 je krok správným směrem. Je přesnější, logičtější a lépe strukturované než 3.1. Lépe odděluje technické vlastnosti zranitelnosti, hrozbu, prostředí a doplňkové informace. Ale pořád platí: lidé ho často neumí používat, procesy ho často nevalidují, skóre není objektivní měření a už vůbec ne kvantitativní vyjádření rizika.

CVSS má v řízení zranitelností své místo, a může být jedním ze vstupů do rozhodování, nikoli rozhodnutím samotným.

LITERATURA

FIRST. Common Vulnerability Scoring System version 4.0: Specification Document. 2023. Online. Dostupné z: https://www.first.org/cvss/v4.0/specification-document. [cit. 2026-04-10].

FIRST. Common Vulnerability Scoring System version 4.0: User Guide. 2023. Online. Dostupné z: https://www.first.org/cvss/v4.0/user-guide. [cit. 2026-04-10].

FIRST. Common Vulnerability Scoring System version 4.0: Examples. 2023. Online. Dostupné z: https://www.first.org/cvss/v4.0/examples. [cit. 2026-04-10].

WUNDER, Julia; KURTZ, Andreas; EICHENMÜLLER, Christian; GASSMANN, Freya a BENENSON, Zinaida. Shedding Light on CVSS Scoring Inconsistencies: A User-Centric Study on Evaluating Widespread Security Vulnerabilities. arXiv, 2023. Online. Dostupné z: https://arxiv.org/abs/2308.15259. [cit. 2026-04-10].

ZHANG, Mengyuan; ZHANG, Yinqian; XU, Min a kol. Identifying CVSS Score Discrepancies in the NVD. 2023. Online. Dostupné z: https://mengyuanzhang.github.io/papers/inconsistency-nvd-cloudcom23.pdf. [cit. 2026-04-10].

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CVSS: A Look at the Current State of Vulnerability Scoring. Gaithersburg: NIST, 2022. Online. Dostupné z: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8409.pdf. [cit. 2026-04-10].

Pokud se vám líbí naše články, tak zvažte podporu naši práce – Naskenujte QR kód a přispějte libovolnou částkou.

Děkujeme!

Štítky: vulnerability management