Prioritizace zranitelností: jak rozhodnout, co opravit nejdřív

Proč samotná závažnost nestačí

Výchozí postup je seřadit nálezy podle CVSS a postupovat od kritických dolů. Působí to objektivně, a přesto to selhává ze tří důvodů:

• CVSS měří závažnost, ne riziko. Popisuje, jak zlá by zranitelnost byla, kdyby byla zneužita. Neříká, zda ji někdo zneužívá, ani zda má ve vašem produktu význam.
• Příliš velká část seznamu je naléhavá. Mnoho zveřejněných CVE má vysoké nebo kritické skóre, takže fronta seřazená podle CVSS dá nahoru stovky nálezů a nenabídne žádný způsob, jak mezi nimi vybírat.
• Seznam je jen tak dobrý jako inventář. Skener, který čte lockfile, hlásí vývojové závislosti, které se nikdy nedodávají, a přehlíží balíčky, které build stáhl mimo správce balíčků. Obojí zkresluje pořadí dřív, než vůbec začne.

Prioritizace doplňuje chybějící otázky: je zranitelnost zneužívána, jak pravděpodobné je, že bude, a co se stane vám, pokud ano. Řazení ale jen uspořádá seznam, který má před sebou, proto nejdřív omezte šum: nálezy u komponent, které nedodáváte, duplicity a nálezy bez vlastníka.

Signály

Signál	Na jakou otázku odpovídá	Zdroj
CVSS	Jak závažná je při zneužití? Skóre 0 až 10.	FIRST (standard); skóre zveřejňují NVD a dodavatelé
EPSS	Jak pravděpodobné je zneužití během příštích 30 dní? Pravděpodobnost od 0 do 1.	FIRST, aktualizováno denně, zdarma
CISA KEV	Je už aktivně zneužívána?	Katalog Known Exploited Vulnerabilities od CISA
SSVC	Co máte vzhledem ke zneužití, dopadu a vašemu poslání udělat: sledovat (track), věnovat pozornost (attend), nebo jednat (act)?	Rozhodovací stromy CERT/CC a CISA
Váš kontext	Dodává se zranitelná verze? Je vystavená? Jak důležitý je produkt? Existuje oprava?	Váš inventář, architektura a evidence aktiv

Veřejné signály popisují zranitelnost. Vaše riziko popisuje jen váš kontext, a právě ten většina týmů získává z nejméně spolehlivého zdroje.

Praktická metoda prioritizace

Většina programů skončí u nějaké verze těchto úrovní. Lhůty nastavte podle toho, co požaduje vaše politika a vaši zákazníci.

1. Opravit hned: známé zneužívané, v softwaru, který dodáváte. Cokoli na seznamu KEV nebo s jinými důkazy o zneužití, co je přítomné ve vydaném buildu. Pro srovnání: směrnice CISA BOD 26-04 dává federálním úřadům USA na položku KEV ve veřejně vystaveném systému pouhé 3 dny.
2. Opravit jako další: pravděpodobně zneužitelné a závažné. Vysoké skóre EPSS v kombinaci s vysokým nebo kritickým CVSS u dodávané a vystavené komponenty. Zvolte práh EPSS, který dá frontu, jakou váš tým skutečně zvládne vyřídit.
3. Opravovat průběžně: vše ostatní, co se dodává. Seskupte to do pravidelných upgradů závislostí, místo abyste každý nález řešili jako incident.
4. Zdokumentovat: netýká se. Zranitelný balíček je přítomen, ale zranitelný kód se nepoužívá, nebo se komponenta nedodává. Zaznamenejte zdůvodnění jako prohlášení VEX, aby se stejný nález nevracel k posouzení a aby zákazníci, kteří se zeptají, viděli proč.

Pak pořadí průběžně přehodnocujte. Zranitelnost, která byla na třetí úrovni, se může přes noc přesunout na první, když je přidána do KEV nebo když její skóre EPSS prudce vzroste.

Zranitelnosti, které se k seřazení nikdy nedostanou

Každá metoda prioritizace řadí nálezy, které má před sebou. Zranitelný balíček, který skener nikdy neviděl, nevytvoří žádný nález, takže nikdy nedostane skóre CVSS, skóre EPSS ani shodu s KEV. Není seřazen nízko. Není seřazen vůbec, a přesto se dodá.

Stává se to častěji, než by se zdálo, protože většina skenerů zjišťuje obsah vašeho softwaru ze souborů: z lockfilu, z manifestů nebo z výstupu buildu. Cokoli, co build stáhne a co žádný lockfile neuvádí, je skrytá závislost a nástroje založené na souborech ji přehlédnou:

• Instalační hooky. Kód stažený skripty npm preinstall a postinstall, cesta, kterou použil červ Shai-Hulud.
• Skripty buildu. Například build skripty v Rustu, které během buildu stahují kód.
• Základní image. Základní image kontejnerového buildu a jeho vrstvy operačního systému.
• Cache. Balíčky obnovené z cache CI místo instalace z lockfilu.

Dodatečné skenování výstupu mezeru neuzavře. Hotový binární soubor, zejména zkompilovaný kód, jako je Rust, nechává skener hádat, co do něj vstoupilo. A protože buildy nejsou ve výchozím stavu reprodukovatelné, nový build stejného commitu později nezaručuje stejné závislosti.

SBOM z doby buildu začíná z opačného konce. CRACI spouští vaše joby GitHub Actions a vidí provoz přicházející do každého buildu, takže zaznamená každý balíček, který job skutečně stáhl, včetně skrytých závislostí. Každá SBOM nese stav úplnosti, který říká, kdy něco nebylo možné vidět. V praxi CRACI našlo zranitelné balíčky, které Snyk a Aikido nenahlásily, protože jejich skenům komponenty chyběly. Právě takové nálezy metoda prioritizace nikdy nedostane příležitost seřadit.

Kontext: část, kterou za vás skenery neohodnotí

Dodává se zranitelná verze skutečně?

Tato otázka odstraní nejvíce šumu. Testovací framework v lockfilu, balíček připnutý ve větvi, ze které se nikdy nevydává, fáze kontejneru, která se zahodí: nic z toho se k zákazníkům nedostane. SBOM zaznamenaná během buildu odpovídá na tuto otázku podle toho, co build vydání skutečně použil, ne podle toho, co deklaruje repozitář.

Která vydání ji obsahují a odkdy?

Nález v produktu, který dodáváte zákazníkům a kde je zasaženo každé vydání od loňského jara, má přednost před stejným nálezem v interním nástroji. Znalost doby expozice vám také říká, co zveřejnit.

Je zranitelný kód dosažitelný?

Analýza dosažitelnosti sleduje, zda váš kód může zavolat zranitelnou funkci v závislosti. Nabízí ji několik nástrojů SCA a účinně posouvá nedosažitelné nálezy níž v seznamu. Berte ji jako jeden ze vstupů: vidí jen cesty kódem, které analýza dokáže sledovat, a dosažitelná funkce není totéž co zneužitelná.

Je vystavená a existuje oprava?

Služba dostupná z internetu má přednost před dávkovým jobem v privátní síti. Zranitelnost s opravenou verzí je levnější uzavřít než takovou, která vyžaduje zmírňující opatření. Obojí mění pořadí, ne to, zda se zranitelnost vyřeší.

Správa zranitelností založená na riziku

Správa zranitelností založená na riziku je název stejné myšlenky na úrovni programu: řadit podle důkazů o zneužití, pravděpodobnosti, závažnosti a obchodního kontextu, měřit, jak rychle se uzavírají nejrizikovější nálezy, a přijmout, že nálezy s nízkým rizikem mohou zůstat otevřené. Mění se s tím i metriky. Místo celkového počtu otevřených zranitelností sledujte, kolik známých zneužívaných zranitelností je otevřených v dodávaném softwaru a jak dlouho otevřené zůstávají.

Nástroje pro prioritizaci zranitelností

Většinu řazení dnes provádějí tři druhy nástrojů:

• Platformy pro správu zranitelností infrastruktury, jako jsou Tenable, Qualys a Rapid7, hodnotí hosty, koncová zařízení a cloudová aktiva vlastním hodnocením rizika postaveným na informacích o zneužívání.
• Nástroje SCA a pro bezpečnost aplikací, jako jsou Snyk, Endor Labs a Semgrep, řadí nálezy v závislostech, několik z nich s analýzou dosažitelnosti.
• Open source nástroje, jako je Grype, který ke svým nálezům uvádí data EPSS a KEV, a Dependency-Track, který průběžně analyzuje SBOM.

Srovnání nástrojů pro správu zranitelností je prochází jeden po druhém.

Jak CRACI podporuje prioritizaci

CRACI začíná tam, kde se řazení nejčastěji pokazí: u inventáře. Spouští vaše joby GitHub Actions a zaznamenává balíčky, které každý job skutečně stáhl, včetně tranzitivních závislostí, balíčků obnovených z cache a skrytých závislostí, které žádný lockfile neuvádí.

• Nálezy pro to, co se dodalo. Monitorované SBOM se průběžně znovu vyhodnocují a pohledy na úrovni organizace agregují nálezy napříč buildy a repozitáři. Každý balíček ukazuje svá bezpečnostní upozornění se závažností a balíčky, které ho stahují.
• Doba expozice. Historie buildů ukazuje, které minulé buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní, takže víte, která vydání byla zasažena a jak dlouho.
• Triáž a směrování. Bezpečnostní týmy provádějí triáž nálezů a každý posílají týmu, který vlastní opravu. CRACI podporuje VEX pro zaznamenání, že se zranitelnost vašeho produktu netýká.
• Brány. Policy gates mohou build při nálezech zablokovat, včetně buildu, který obsahuje konkrétní CVE.

CRACI nenabízí analýzu dosažitelnosti. Pokud je to signál, který potřebujete nejvíc, zvolte jeden z nástrojů SCA, které ji nabízejí. Celou funkci popisuje sledování zranitelností.

Prioritizace zranitelností: časté dotazy

Co je prioritizace zranitelností?

Prioritizace zranitelností je rozhodování o tom, které známé zranitelnosti opravit nejdřív, které mohou počkat a které se vás vůbec netýkají. Řadí nálezy podle toho, jak pravděpodobné je jejich zneužití a jakou škodu by způsobilo ve vašem prostředí, ne jen podle závažnosti.

Jak prioritizovat zranitelnosti?

Začněte přesným inventářem, abyste řadili zranitelnosti v softwaru, který se skutečně dodává. Na první místo dejte cokoli ze seznamu Known Exploited Vulnerabilities od CISA, pak seřaďte zbytek podle pravděpodobnosti zneužití (EPSS) a závažnosti (CVSS), upravené podle vašeho kontextu: expozice, důležitosti produktu a toho, zda existuje oprava. Ty, které se vás netýkají, zaznamenejte jako prohlášení VEX.

Stačí CVSS k prioritizaci zranitelností?

Ne. CVSS měří, jak závažná zranitelnost je, ne jak pravděpodobné je její zneužití ani jak moc záleží právě vám. Řazení jen podle CVSS označí velkou část backlogu jako vysokou nebo kritickou a většina těchto zranitelností nikdy zneužita není.

Co je správa zranitelností založená na riziku?

Správa zranitelností založená na riziku řadí a opravuje zranitelnosti podle rizika, které představují pro vaši organizaci, a kombinuje přitom důkazy o zneužití, pravděpodobnost, závažnost a obchodní kontext, místo aby je procházela podle skóre CVSS nebo stáří.

Jaký je rozdíl mezi EPSS a KEV?

EPSS je předpověď: odhadovaná pravděpodobnost, že CVE bude zneužita během příštích 30 dní. KEV je záznam: katalog CISA se zranitelnostmi, u kterých existují důkazy o skutečném zneužívání. Položka KEV je fakt; skóre EPSS je pravděpodobnost. Nejdřív použijte KEV a podle EPSS seřaďte vše ostatní.

Nahrazuje analýza dosažitelnosti prioritizaci?

Ne, je to jen další vstup. Dosažitelnost ověřuje, zda váš kód může zavolat zranitelnou funkci v závislosti. Odstraní nálezy, které nelze spustit, ale neříká nic o pravděpodobnosti zneužití a pokrývá jen kód, který analýza dokáže sledovat.