Odpověď na názor

Má to vlastnosti náhodně vygenerované čísla. Že je na to generování náhodného čísla metodologie na tom nic nemění – na generování UUID je také metodologie.

A ciselne hodnoceni umoznuje alespon seradit problemy, aby se dalo prioritizovat jejich reseni.
Ale to je právě špatně! Protože to číslo má jen velmi volnou souvislost s tím, jak je ta která chyba vážná. Asi se nestane, že RCE s exploitem bude mít skóre 1,2, ale to, že skóre 9,8 získávají věci, které je v drtivé většině případů nemožné zneužít, je skoro na denním pořádku.

Právě proto, že se někdo pokouší podle toho něco řadit, říkám, že je to náhodné číslo. Protože tak by se k tomu mělo přistupovat. Dokud podle toho někdo bude něco řadit a zároveň se výrazně nezmění způsob, jakým se to skóre určuje, je potřeba to opakovat, že je to náhodné číslo.

nekde musi byt hranice co je povazovano za OK a co je pres caru
Tak tu hranici stanovte. Jsem zvědav, jak to uděláte – když jsou případy se skórem 9,8, které není potřeba vůbec řešit, a vedle toho máte třeba skóre 7,5, které řešit musíte. To ta čára bude dost klikatá.

A prave proto, ze automat potrebuje nejakou metriku k rozhodovani - idealne redukovanou na jedno cislo, existuje CVSS.
A právě proto říkám, že to skóre nemá lepší vypovídací hodnotu, než náhodné číslo. Ano, mít jedno číslo, které by vypovídalo o závažnosti chyby, by bylo hezké. Aby se podle něj mohly rozhodovat automaty. Nebo „bezpečáci“. Ale takové číslo dneska nemáme, CVSS je v tomto směru prakticky nepoužitelné.

Mimochodem, až nějaké takové použitelné skóre do budoucna vznikne, rozhodně to nebude jediné číslo, ale minimálně dvě čísla – jedno bude reprezentovat závažnost chyby, druhé pravděpodobnost jejího zneužití. Protože je rozdíl, jestli aplikace vezme vstup od vzdáleného uživatele a spustí ho jako strojový kód, nebo jestli je knihovna, která obvykle nezpracovává vstup ze sítě, která volá jinou knihovnu, která také obvykle nezpracovává vstup ze sítě, ta volá třetí knihovnu, která také nezpracovává vstup ze sítě – a tady v té třetí knihovně je chyba, která umožní spustit vstup jako kód. Dneska takovéhle dvě chyby dostanou úplně stejné skóre, protože přece u těch knihoven nelze zcela vyloučit, že je nějaký program využívá tak, že se mu podaří skrze ty tři knihovny propasírovat vstup od uživatele až k té třetí zranitelné knihovně.

a jak vidite, i ta metodologie se vyviji, kdyz tam je uz verze 3.1
Ve skutečnosti už existuje verze 4.0.

Metoda vazeneho prumeru vam nic nerika, ze?
A vám zase nic neříká garbage in, garbage out, že?

Odpovednost za CVE nese autor exploitovatelneho reseni. Ma pracovat pecliveji a byt vubec rad, ze mu to nekdo pomaha vylepsovat.
Ne, autoři fakt nejsou rádi za falešná hlášení chyb. Ničemu nepomáhají, akorát odvádí autory od skutečného vylepšování.