Bezpochyby jsme už ve stavu, kdy CVE páchá víc škody než užitku. Hodnocení závažnosti je číslo vytažené z klobouku. CVE, kterým byla snížena závažnost (po spoustě dohadů) nebo je autor dokonce odvolal jsou na spoustě míst nadále hodnoceny jako kritické.
Jsem zvědav, kdy k tomu autoři softwaru začnou přistupovat stejně a začnou vydávat nezměněné verze pod novým číslem jenom proto, aby se CVE zbavili.
Asi bych takhle nezobecnoval. Ano, k dilcim excesum obcas dochazi diky tomu jak je CVSS postavene, ale to se da najit asi u vseho. Problem neni ani tak se systemem - jako spise s lidmi co hodnoceni v tech konkretnich pripadech provadi - kdy dane riziko proste a jednoduse nadhodnoti. A to se muze stat u libovolneho zpusobu hodnoceni rizik...
To máš asi pravdu, ale dopad na ty konkrétní vývojáře (viz tato zprávička) je reálný. My třeba používáme pro Python knihovny SafetyCLI a tam náhodně zařazují i letité "zranitelnosti", o kterých autoři toho sw řekli, že to není bug, ale feature (třeba https://data.safetycli.com/v/70612/eda/). Problém je, že když tvůj takhle někdo označí jako kriticky zranitelný, nemáš jak se té nálepky zbavit.
Problém je, že poslední dobou se někteří utrhli ze řetězu a nahlašují kritická CVE na komponenty, které jsou (když to trošku přeženu, ale jen malinko) třeba dvě úrovně hluboko a teoreticky se dají jen špatně použít.
A neexistuje rozumný způsob jak to skóre revidovat přímo u MITRE. Prostě tam pořád svítí 9.8 a zákazníci to vidí.
Jako příklad mi ukazovali třeba https://nvd.nist.gov/vuln/detail/CVE-2024-24258#vulnCurrentDescriptionTitle
Nahlášeno na muPDF knihovnu, ale je to memory leak ve freeglut funkci pro kreslení menu. A skončilo to jako HIGH, protože exploitovatelné po síti (!?), někdo by tu knihovnu přece mohl použít v síťové službě.
Kolegové kvůli tomu napsali i sérii článků, protože to začíná být neudržitelné - existují organizace, co začaly vyžadovat 0 (nula) známých CVE pro dodaný software. Jenže těch CVE se teď objevuje tolik, že takový stav prakticky nejde zařídit.
https://www.redhat.com/en/blog/patch-management-needs-a-revolution-part-2
Jo, to problem je - s tim asi nelze nesouhlasit. Holt kolem bezpecnosti se zaclo motat spousta lidi, co nema moc velke provozni zkusenosti, a tedy i schopnost dopady opravdu vyhodnotit - ale zato se naucilo par buzzwordu a pak to proste strili od boku. Ale co s tim? Nejaky scoring potreba je.
Je to jak se software... proste je to bug v systemu, co by se mel opravit - v danem pripade doresit zmineny system revidovani. A ne to pausalne smest ze stolu stylem je to spatne, proste se vic projevil problem, co driv tak patrny nebyl - ale to opet souvisi s tim, ze se kolem toho dnes mota vic lidi nez driv.
Jinak samozrejme i zakaznik by se nemel orientovat jen podle cisla. To je zas takovyto zjednodusovani (a pripadne alibismus). Realny impact kazde chyby prece musim zhodnotit i ve vztahu ke svemu prostredi a dalsich okolnostech a ne jen se tocit na nejakem cisle. Jsou lidi, co si ani nedokazou opravdu vyhodnotit automatizovane scany, ale ma je potrebu "resit" - i kdyz nevi nic o tom, co vlastne ctou.
Nějaké hodnocení je potřeba, ale to současné je kontraproduktivní – protože je to v podstatě náhodně vygenerované číslo, ke kterému se ale ve spoustě případů přistupuje, jako kdyby mělo nějaký význam.
Dnes je to jen honba za co nejvyšším číslem. Pokud to někdo ohodnotí špatně, žádnou odpovědnost za to nenese – pro něj je to jenom plus, protože si může do CV napsat, že objevil CVE se skórem 12,4. Negativa ale dopadají na všechny okolo, od vývojářů přes distributory po uživatele, protože tam všude se tím musí zabývat, vyhodnotit, že ta CVE se skóre 9,8 u nich není zneužitelná, řešit to jako incident a řešit na to výjimku, protože nějaký automat umí porovnat jenom ta čísla. A tohle všechno řeší ti samí lidé, kteří by místo toho řešili reálnou bezpečnost.
Zas melete blbosti, jake nahodne vygenerovane cislo ??
CVE score ma danou metodologii urcovani (CVSS), a muzete si to klidne vyklikat pres nejaky GUI nastroj, a la: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator (a jak vidite, i ta metodologie se vyviji, kdyz tam je uz verze 3.1)
Zranitelnost tedy bude mit takove skore, jake vyplyne z jeji charakteru - a pokud chcete vyssi, tak holt musite dodat/nalezt i exploit, idealne sitovej. Tezko si muze nekdo jen tak nadhodnotit score pro svuj objev.
A ciselne hodnoceni umoznuje alespon seradit problemy, aby se dalo prioritizovat jejich reseni. Metoda vazeneho prumeru vam nic nerika, ze? A ani thresholding - nekde musi byt hranice co je povazovano za OK a co je pres caru. Jinak by to byla anarchie celkem a nic se nevyresilo. A prave proto, ze automat potrebuje nejakou metriku k rozhodovani - idealne redukovanou na jedno cislo, existuje CVSS.
Odpovednost za CVE nese autor exploitovatelneho reseni. Ma pracovat pecliveji a byt vubec rad, ze mu to nekdo pomaha vylepsovat.
Jo, metodika pro to číslo je. Ale ukažte mi ten síťový exploit pro ten freeglut co jsem linkoval nahoře.
Protože ten má vysoké skóre jen proto, že reporter tvrdí, že to je exploitovatelné po síti bez uživatelské interakce.
Takže číslo se počítá z příznaků, které dostanete v rámci toho hlášení. A teoreticky můžete tyhle příznaky přidat k libovolné knihovně. Vždycky totiž existuje způsob jak ji zakomponovat do síťové služby (ale u grafického menu si to neumím moc představit..).
To jsme ale porad u toho, ze primarni chyba je na strane toho, kdo problem reportuje. Sekundarne je chyba v tom, ze to nejde nejakym procesem snadno opravit, potazmo ze reporter nemusi moc prokazovat pravdivost svych tvrzeni. To jsou porad jen procesni/organizacni veci... co cislo samo o sobe spatne neni.
To jsme ale porad u toho, ze primarni chyba je na strane toho, kdo problem reportuje.
Ano, problém je v tom, že lidé nejsou svatí…
Pokud je systém nastaven tak, že reportující se snaží mít co nejvíce co nejvyšších čísel, přičemž nenese žádnou zodpovědnost za to, pokud něco reportuje špatně, jak to asi může dopadnout?
To mate jako s poctem commitu. Tam se take casto soutezi na pocet, a treba takovy github to podporuje i vizualizaci v profilu vyvojare. Znamena to snad nizsi kvalitu produkovaneho software? :-) Nebo to vypovida o tom, jak kvalitni kod se produkuje? Ano, nas dnesny uspechany svet je hodne postaveny na podobnem "soutezeni".
Samozrejme, ze ruznym zpusobem jde zneuzit ledacos kolem nas. A neplati to zdaleka jen v digitalnim svete. Ale s tou odpovednosti je to sporne - pokud se ukaze, ze nejaky jedinec opakovane reportuje vylozene nesmysly, tak se to o nem drive ci pozdeji dozvite. Mozna jsme jen lini se trosku posnazit a podobnym lidem, co slabiny systemu zneuzivaji ve svuj osobni prospech proste sebrat moznost takove reporty generovat - stejne, jako se problemovym vyvojarum klidne znemozni prispivani do nejakeho projektu...
Ten problem proste ma reseni - zacina to uz u toho mit koule na ty jedince, co reportuji nesmysly verejne ukazovat prstem.
Nevšiml jsem si, že by se počtem commitů někdo chlubil v CV. Ale hlavně – za tím, kdo ty commity posílá, je ještě nějaký správce projektu, který by autora poslal někam, pokud by mu posílal příspěvky rozdělené na commity nesmyslně, jen kvůli počtu.
Jenže za tím, kdo hlásí CVE, už prakticky nikdo není. I když dotyčný nakonec to CVE odvolá, spousta nástrojů to vůbec nezohledňuje. Prostě publikovat CVE je možné bez jakékoli odpovědnosti, ale na druhé straně se CVE používá k rozhodnutím, která mají dost vážné dopady.
pokud se ukaze, ze nejaky jedinec opakovane reportuje vylozene nesmysly, tak se to o nem drive ci pozdeji dozvite
Můžete jmenovat někoho, o kom jste se takhle dozvěděl? A jak se to zohledňuje v CVE, které vydává – mají nižší skóre? Nebo auditovací nástroje CVE od takového člověka ignorují? Nic z toho neplatí, že? Prostě tam není žádná odpovědnost – na jedné straně si může o CVE zažádat kdokoli, kdo jde zrovna kolem, skóre to dostane tak vysoké, jak tam nakliká. Pak to probublá procesem, který tomu dodá zdání důležitosti, a na konci se kvůli tomu musí dělat odstávka nějakého důležitého systému, protože to CVE vypadlo z nějakého automatizovaného auditu – a už nikdo neřeší, že kdyby v daném systému byla ta chyba opravdu zneužitelná, aplikovaná „oprava“ nic nevyřeší.
Ten problem proste ma reseni - zacina to uz u toho mit koule na ty jedince, co reportuji nesmysly verejne ukazovat prstem.
Vždyť jenom tady na Rootu je to několikátá zprávička o tom, jak bylo někde vytvořeno úplně nesmyslně skórované CVE. Takže v praxi se to děje ještě mnohem častěji. Nadávají na to vývojáři a správci projektů, nadávají na to správci distribučních balíčků – ale nezdá se, že by se něco změnilo. Naopak pořád lidé jako RDa výše tvrdí, že podle toho čísla řadí, co má větší prioritu a čemu už ení potřeba se věnovat.
Mimochodem, on to ani nemusí být od někoho záměr reportovat to špatně. Ono to může být jednoduše tak, že poctivě zakliká to, na co se ho kalkulátor SCSS zeptá. Je to exploitovatelné po síti? No můžete zaručit, že tu knihovnu nepoužije někdo v aplikaci komunikující po síti pro data přicházející ze sítě? No nemůžete. Takže je to exploitovatelné po síti – každá knihovna prakticky automaticky. A tak dále. Že jediná síťová komunikace je zjišťování, zda není dostupná nová verze aplikace? Že kdyby vám autor té aplikace chtěl podstrčit škodlivý kód, šoupne ho do další verze té aplikace a nebude to dělat složitě exploitováním přes číslo verze? Nezájem, skóre 9,8, další.
TL;DR... preskocil jste to podstatne - zabyvat se tim dohledanim jedince, co score v konkretnim pripade nadhodnoti. Chapu, je to moc prace. A holt se tu projevuje typicka vlastnost - tedy lenost. Kverulovat, ze CVSS je spatne je vyrazne jednodussi. A pritom ani nepredkladate lepsi reseni - navzdory delce textu.
preskocil jste to podstatne - zabyvat se tim dohledanim jedince, co score v konkretnim pripade nadhodnoti. Chapu, je to moc prace. A holt se tu projevuje typicka vlastnost - tedy lenost. Kverulovat, ze CVSS je spatne je vyrazne jednodussi.
A jak konkrétně můžeme přesvědčit zákazníka, aby se zabýval tím, jestli to skóre není nadhodnocené? Zákazníkovi jeho automatizovaný nástroj vyhodí, že je tam "závažná bezpečnostní chyba" a zákazník začne ječet, že se to musí opravit. Můžete mu stokrát vysvětlovat, že ta chyba vůbec není závažná (a nezřídka ani bezpečnostní, občas ani chyba), ale pro něj to je posvátné číslo od Autority a trvá na tom, že to tak prostě je a basta.
Základní problém je v tom, že nareportovat CVE může v podstatě kdokoli, vyplnit si tam může co chce a "závažná bezpečnostní chyba" je na světě. Naopak, zpochybnit skóre nebo samotnou podstatu té "bezpečnostní chyby" je náročné, na dlouhé lokte a většinou je nakonec jednodušší backportovat i úplně zbytečné opravy, než to martyrium podstupovat pořád dokola. Vzhledem k nezadržitelně rostoucímu počtu bagatelních CVE se ten problém stále prohlubuje. Čehož pak příslušné instituce zneužívají a poukazují na to, jak systém krásně funguje, protože zpochybněných CVE je vlastně strašně málo.
Kvalitě software to nepomáhá vůbec, naopak, protože čím dál větší část času vývojářů je spotřebovávána na backportování zbytečných "oprav" a administrativu s tím spojenou místo toho, aby mohli dělat něco užitečného.
Tak ono ty automaticke nastroje vraci i spoustu jinych nesmyslu, zvlast ty co pracuji jen s hlavickami/bannery sluzeb a nejsou oprene o agenta, co bezi primo na testovanem systemu. Pokud to zakaznik neni schopen spravne interpretovat, nemel by se takovym materialem ohanet. Ja vim, ze to obcas delaji...
Ten problem se prohlubuje ale i proto, ze se v IT nektere veci proste odjakziva flakaji. Jde souhlasit, ze backportovani oprav je zbytecne - ale nektere problemy vyvojari vytvari defacto sami svym pristupem k tomu vyvoji - kdy se s kadenci palby z kulometu meni veci zpusobem, ze starsi aplikaci s novejsi knihovnou uz nezprovoznite. Nebylo by lepsi delat veci tak, aby jsme se slozitemu backportovani co mozna nejvic mohli vyhnout? Tedy pristupovat k vyvoji zodpovedneji a ne se pri vydani nove verze tvarit, ze nekompabilita je problem na druhe strane?
Chybu proste nejde hledat jen v samotnem CVSS. Vyvoj software sam o sobe casto opomiji jednu zakladni vec - a to je dlouhodoba udrzitelnost.
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í.
Vy schválně nečtete ty argumenty? To číslo je "polonáhodné", protože se počítá z nevalidovaných vstupů.
- Počet CVE za posledních 20 let narostl dvacetinásobně (odhadem od oka z grafu).
- Legislativa taky. Common criteria před dvaceti lety nevyžadovalo nulový aktivní počet CVE (bez ohledu na severity), aby certifikovalo release.
- Zákazníci vázaní zákony o bezpečnosti IT tu certifikaci musí vyžadovat.
Všimněte si, že kombinací těch podmínek dostanete stav, kdy na závažnosti naprosto nezáleží. Prostě nesmí existovat známá chyba.
Tak kdyz nam za poslednich 20 let vyrazne narostl objem software, co nas obklopuje, logicky narostl i pocet chyb v nem. A nektere zpusoby vyvoje tomu taky nepridavaji - viz ruzne agilni metody, co ve finale produkuji software spichnuty horkou jehlou a ve finale nekdy i fakticky deravy (s tim, ze zabezpeceni se casem dodela). Ted aktualne portal stavebnika, kdy v ostre verzi ani poradne neosetrili pristupova prava a urady tam vidi i co nemaji... aka muzou rusit a upravovat podani, do kterych by hrabat vubec nemeli. V minulosti stejnym zpusobem vzniknul i slavny alternativni eshop k dalnicnim znamkam. Za podobne veci CVSS fakt nemuze, priciny jsou i jinde - v metodach, jak se dnes veci delaji. Bezpecnost musi byt integralni soucasti navrhu aplikace a pocitat se s ni musi od prvopocatku... a ne ze se to "pak nekdy" dodela.
V minulosti stejnym zpusobem vzniknul i slavny alternativni eshop k dalnicnim znamkam.
Hele, Danny, tohle se přece vždycky vyřeší jedním odstavcem:
„Moc všechny prosím o fér hodnocení situace. Bavíme se tu o lidech, kteří dvě noci nespali, aby ukázali, že jim záleží na používání našich společných peněz. Ti samí lidé do tří ráno jeden druhého budili, aby kontrolovali, že data jsou již v bezpečí,“
Vidíš ne? Vyřešeno, všechno je v pořádku, nikdo nebyl vyhozen (z těch manažerů) takže o dva roky později se stejnou metodou může dělat třeba systém přihlášek na střední školy...
ne ze se to "pak nekdy" dodela
Jenže tohle je metodika vývoje těch aplikací. Musí se "to" stihnout do nějakého termínu. Teprve potom, co je znám termín, se zjišťuje to "to". Až se to zjistí, tak týden před termínem přijde požadavek, který to celé překopá. A potom v pondělí to spadne, protože se tam přihlásí 5% lidí. A přijde Filip, který nám všem vysvětlí, že je to vlastně naše chyba, že to "to" vlastně určitě vůbec nepotřebujeme v pondělí.
No ono by někdy stačilo mít alespoň zadání. Ale o tom jsme se tady s Filipem hádali před x měsíci.
CVSS je tu s nami temer 20 let, ale pan popirac holokaustu na bude vykladat co to je za nesmysl a nahodny cislo - tak jisteeee :D
Třeba e-mail tu s námi (nebo našimi předchůdci) byl docela dlouho (možná i víc než 20 let), než se začaly masivně zneužívat slabiny jeho návrhu. A nevěřil byste, jak dlouho se spokojeně používat třeba takový telnet, aniž by bylo potřeba řešit skutečnost, že komunikace není ani trochu zabezpečená.
Je to vlastně takový tragikomický paradox, že systém zabývající se bezpečnostními chybami byl navržen bez jakéhokoli snahy o obranu proti triviálními DoS (DDoS) útoku.
Ne, to neni nahodne cislo, pokud se bavime o CVSS.
Ono jinak historie pamatuje i opacne pripady - kdy se riziko bagatelizovalo a realny dopad chyby byl nakonec vetsi.
To je proste o lidech. A doba je holt uz takova, ze pro kdejakou ptakovinu se i vymysli specialni pojmenovani s vlastnim webikem.
nepodceňuj to.
Ve vzduchu je útok, kdy útočník může cíleně odstavit aktualizaci produkce vytvořením abnormálního množství zranitelností k použitým závislostem. Důsledky mohou být vážné až fatální. Už se objevily i první pokusy o vydírání jinak budou tvořit CVE.
CVE se dnes přebírají bez jen tak a automaty jedou na plné obrátky.
Zrovna Qualys je jeden z těch nástrojů, který se prezentuje jako velký guru, přitom je extrémně nespolehlivý a není odolný proti podobným útokům.
Ano, k dilcim excesum obcas dochazi
Takhle to možná vypadá z pohledu člověka, který nemá globální obrázek o současném stavu a vychází jen z těch pár případů, které někoho naštvaly natolik, aby o nich napsal článek.
Ještě tak před pěti lety bylo standardem, že report obsahoval aspoň myšlenku toho, jak by se chyba dala aspoň teoreticky využít. Dnes už se něčím takovým neobtěžuje skoro nikdo. Naopak, běžným standardem je, že se strojově prohledávajá historie na commity určitého typu a k nim se automaticky generují šablonové CVE, aniž by se někdo zabýval tím, jestli existuje aspoň teoreticky nějaký scénář, jak by z toho mohl být problém.
A ani úplně nesmysly už dávno nejsou excesem, ale spíš normou. Systém je ale nastavený tak, že vytvořit CVE je "zadarmo" a bez jakékoli kontroly, zatímco zpochybnit skóre nebo samu podstatu je náročné a odrazující. Párkrát to zkusíte a zjistíte, že je většinou jednodušší prostě opravovat/backportovat i úplné nesmysly, než to podstupovat. Jenže to právě vede k těm úžasným statistikám, jak mizivé procento CVE je úspěšně zpochybněno (nebo se o to někdo aspoň pokusil).
Ten systém je prohnilý od základu a jedinou možností, jak z něj udělat něco užitečného, je založit ho na úplně jiných principech.
No, takze priznavate, ze pricinou neni system CVSS, ale zpusob jakym se projevuje lidska lenost... :-) Napiseme script, zautomatizujeme to... a pak budeme brecet, ze jsme nekde neco, co predpoklada alespon elementarni pouziti mozku "rozbili".
Argument z backporty tu uz zaznel. Tak at se zacne i software delat tak, aby se nemuselo krecovite backportovat. Kdyz uz chceme mluvit o prohnilosti systemu, tak zacnete tady. Metody vyvoje software stylem, ze prakticky co rok, to nova a zpetne nekompatibilni verze veci, co se masove pouziva udrzitelny taky asi moc neni, ze?
No, takze priznavate, ze pricinou neni system CVSS, ale zpusob jakym se projevuje lidska lenost
Je-li ten systém navržen tak, že patologickému chování jedinců nejen nebrání, ale ve skutečnosti ho vlastně aktivně podporuje, je navržen špatně. Založit takový systém na presumpci viny byla chyba, ale nikdo, kdo je na tom systému zainteresován, to řešit nechce, protože je to pro ně z různých důvodů výhodné. Vadí to jen obětem, ale ty do toho jednak nemají co mluvit, jednak když se ozvou, jedinci jako vy (bez představy, jak to v praxi funguje a k čemu to vede) je ukřičí.
Ona je hezká teorie, že stačí prohlásit, že číslo je vycucané z prstu, protože to reportoval ignorant, který tam vyplnil nesmysly. Ale jak ukazuje (zdaleka nejen) tento příklad, v praxi to nefunguje, protože pak riskujete, že se bude všude možně psát "projekt X nepoužívejte, jsou tam neopravené superzávažné bezpečnostní chyby" a veřejnost bude slepě věřit Autoritám, ne vám, i kdyby každému, kdo tomu aspoň trochu rozumí a podívá se, bylo naprosto zjevné, že máte pravdu.
Ano, část problému je i v tom, že nezasvěcená veřejnost (které je drtivá většina) si opravdu myslí, že když to má CVE id a nějaké skóre, tak nějaká Autorita garantuje, že to opravdu je bezpečnostní chyba a má udávanou závažnost. To je prostě lidská přirozenost, že v oblastech, kterým sami nerozumějí, spoléhají na garance uznávanými autoritami. A nenalhávejme si, prosím, že v tomto případě Autoritě nevyhovuje ten stav, kdy jí veřejnost slepě důvěřuje coby takovému garantovi, aniž by musela hnout prstem pro to, aby ta důvěra byla aspoň trochu oprávněná.
Ale historie pamatuje i opacne pripady - zvlast u uzavrenych reseni se casto setkavame s tim, ze tvurce chyby v lepsim pripade jen bagatelizuje, v horsim zamlcuje zcela. On ten nezavisly bic na vyvojare je proste potreba take. Jak uz pisu vise, nutnost doplnit nejake opravne mechanismy do hodnoceni by od veci urcite nebylo - ale presumce neviny je extrem z druhe strany. To si troufnu tvrdit, ze vam na to vyvojari budou plosne kaslat... protoze opravovat bugy v existujicim kodu je vetsi nuda nez vymyslet nove ptakoviny.
CVSS se samozrejme vyviji, coz je patrne i na jeho verzich - coz je na strankach FIRSTu (ktrery za tim stoji) samozrejme videt. Tvrzeni, ze jim stav vyhovuje a nic s nim delate nemini je take prinejmensim lzive. Navic je to vcelku otevrena organizace, to neni zadny ku-klux-klan, najdete tam i par subjektu z CR. CVSS je proste vysledek nejakeho konsensu vcelku siroke komunity.
Nedávno jsem se setkal s něčím podobným. Máme na githubu i branche, které nejsou určené pro produkci nejsou ani testovací, nedělají se z nich releasy, občas to ani není kompletní projekt. Možná naše chyba, že jsme je nechali veřejně, ale je tam nějaké procento kódu, které občas někdo hledá.
Před pár měsíci nám začali ve velkém reportovat problémy právě z těchto kódů. Vzniklo spoustu CVE, kde bylo uvedeno "all version affected, critical vulnerability, ...". S těmi nahlašovateli se často nedalo moc mluvit, nenechali si vysvetlit, že reportují nesmysly z nikdy nevydaného a nepoužitého kódu apod. Jak píše kolega - jen strojovým prohledáváním vytvořit co nejvíce CVE.
No a pak o tom vydat někde na hacker news článek, jak je projekt děravý