Jak snížit šum ve správě zranitelností

Odkud šum zranitelností pochází

Vezměte jeden backlog a roztřiďte ho podle toho, odkud každý nález pochází. Čísla níže jsou ilustrativní, nejde o benchmark, ale kategorie jsou právě ty, na které týmy narazí, když projdou vzorek vlastního backlogu.

Zdroj nálezu	Z 1 000 nálezů (ilustrativně)	Krok, který ho odstraní
Komponenty, které nedodáváte: položky v lockfilu a manifestu, vrstvy builderu, vývojové a testovací nástroje	300	1. Opravte inventář
Stejná CVE hlášená několika nástroji nebo jednou za každý repozitář	250	2. Počítejte každý nález jednou
Chybné shody: kolize názvů CPE, backporty distribucí	80	1. Opravte inventář
Skutečné nálezy, které ve vašem produktu nelze zneužít	150	4. Přidejte kontext zneužitelnosti
Skutečné nálezy, pro které zatím neexistuje oprava	70	5. Rozhodnutí podle politiky s datem platnosti
Nálezy bez vlastníka	50	5. Předání vlastníkovi
Zbývá seřadit a opravit	100	Prioritizace

Jedno rozlišení usnadní zbytek stránky. Některé z těchto nálezů jsou falešně pozitivní: nález je chybný, protože komponenta tam není nebo verze není dotčena. Jiné jsou šum: nález je správný, ale nemění to, co tento týden uděláte. Vyžadují různá řešení, a když se zamění, týmy nakonec potlačují skutečné nálezy nebo se přou o chybné.

Falešně pozitivní nález: nález je chybný	Šum: správný, ale ne naléhavý
Komponenta není v tom, co dodáváte	Zranitelný kód nelze ve vašem produktu dosáhnout ani spustit
Shoda je chybná: kolize CPE nebo backportovaná oprava, kterou číslo verze skrývá	Oprava zatím neexistuje nebo je produkt interní a není vystavený
Řešení: opravit inventář a párování	Řešení: kontext, zaznamenané rozhodnutí a vlastník

Krok 1. Sjednoťte inventář s tím, co dodáváte

Toto je největší jednotlivá páka, protože každý další krok chyby inventáře násobí. Komponenta, která je uvedená, ale nikdy se nedodává, vytváří nález v každém skeneru, každém repozitáři a každém vydání.

• Zaznamenávejte z buildu. Sestavujte inventář z toho, co release build skutečně použil, ne z manifestů nebo ze skenu hotového artefaktu. SBOM z doby buildu obsahuje to, co job stáhl, včetně toho, co žádný lockfile neuvádí.
• Identifikujte komponenty pomocí PURL. Package URL jako pkg:npm/[email protected] přesně pojmenuje ekosystém, balíček a verzi. Párování s upozorněními klíčovanými podle PURL, jako jsou ekosystémová upozornění v OSV, odstraňuje chybné shody, které vznikají odhadováním CPE z názvu produktu.
• Pro balíčky OS používejte párování, které zohledňuje distribuci. Debian a další distribuce backportují bezpečnostní opravy do verze, kterou dodaly, místo aby ji povýšily, takže číslo verze může vypadat starší než upstreamová oprava. Párujte s vlastním bezpečnostním trackerem distribuce, ne s upstreamovými rozsahy verzí.
• Sledujte úplnost. Vězte, kdy inventář něco nemohl vidět, místo abyste předpokládali, že je úplný. Chybějící komponenta je horší než hlučná: nevytvoří vůbec žádný nález.

Praktický příklad. Lockfile služby v Node.js obsahuje [email protected], knihovnu pro párování glob vzorů, na které závisejí testovací a buildovací nástroje. Sken lockfilu hlásí CVE-2024-4067, denial of service přes regulární výraz, opravený ve verzi 4.0.8. Release job instaluje pouze produkční závislosti, pomocí npm ci --omit=dev, takže micromatch se do buildu, který se dodává, nikdy nedostane. Záznam tohoto buildu ho neobsahuje a nález se do backlogu nikdy nedostane. CVE je skutečná; pro tento produkt je nález falešně pozitivní.

Krok 2. Počítejte každý nález jednou

Stejná CVE přichází z nástroje SCA, ze skeneru kontejnerů i z platformy SBOM, a ještě jednou za každý repozitář, který knihovnu používá. Deduplikujte podle jednoho klíče: package URL, verze a CVE. Například pkg:npm/[email protected] s CVE-2024-45296 je jeden nález, ať ho hlásí kolik nástrojů chce.

• Počítejte jeden nález na dodávaný artefakt, ne jeden na skener.
• Agregujte napříč buildy a repozitáři, aby CVE ve sdílené knihovně bylo jedno rozhodnutí uplatněné všude, ne čtyřicet ticketů.
• Konsolidujte překrývající se skenery. Jednoduché pravidlo: nálezy v závislostech z jednoho zdroje SCA nebo SBOM, nálezy v image z jednoho skeneru kontejnerů, nálezy ve vašem vlastním kódu z jednoho nástroje SAST. Pokud dva nástroje hlásí stejný signál, ponechte ten, který má blíž k tomu, co se dodává (SAST vs SCA).

Krok 3. Dodávejte méně

Každá závislost, kterou nedodáváte, je zdrojem nálezů, které nikdy nemusíte řešit.

• Odstraňte nepoužívané závislosti. Většina projektů s sebou nese pár balíčků, které už nic neimportuje.
• Povyšte balíček, který zranitelné balíčky stahuje. Express 4.19.2 připíná [email protected] a [email protected], které nesou CVE-2024-45590 a CVE-2024-45296. Samostatně je bez overrides aktualizovat nelze. Express 4.20.0, vydaný v září 2024, závisí na opravených verzích, takže jeden upgrade vyřeší obě (tranzitivní závislosti).
• Používejte minimální základní image. Slim a distroless image obsahují méně balíčků operačního systému, takže se na ně vztahuje méně upozornění. Skenování kontejnerů popisuje páky specifické pro image.
• Připínejte a aktualizujte uváženě. Lockfily a digesty udržují inventář mezi buildy stabilní.
• Blokujte buildy, které obsahují známou zranitelnou verzi. Kontrolní brána politik, která build zastaví, udrží zranitelnou knihovnu venku dřív, než se z ní stane nález, na který musí někdo provést triáž.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Krok 4. Přidejte kontext zneužitelnosti

To, co zbude po krocích 1 až 3, je skutečné. Kontext rozhoduje, co z toho je naléhavé.

• VEX. Zaznamenejte „not affected“ jednou, s odůvodněním, jako prohlášení VEX, a používejte ho opakovaně napříč vydáními a zákazníky. Když vám zákazníci přepošlou vlastní skeny vašeho produktu, odpoví jim stejné záznamy: viz škálování týmu PSIRT a jak odpovídat zákazníkům po útoku na dodavatelský řetězec, kde najdete šablony odpovědí.
• Dosažitelnost, pokud ji vaše nástroje nabízejí, ukazuje, zda váš kód může zavolat zranitelnou funkci. Pomáhá, v určitých mezích (analýza dosažitelnosti).
• Signály zneužívání. CISA KEV uvádí, že je zranitelnost aktivně zneužívána; EPSS odhaduje, jak pravděpodobné je zneužití v příštích 30 dnech.
• Vystavení. Produkt dostupný z internetu má přednost před interním nástrojem v privátní síti.

Krok 5. Předávejte nálezy vlastníkovi, podle politiky

• Zapište prahové hodnoty jako politiku. Nastavte prahy závažnosti a zneužitelnosti pro každý produkt nebo repozitář v politice, ne jako filtr na dashboardu, který použil jeden člověk.
• Přidělte vlastníky podle repozitáře nebo týmu, aby každý nález měl někoho, kdo rozhoduje.
• O případech „oprava není k dispozici“ rozhodujte explicitně: přijměte riziko s datem platnosti, zmírněte ho, nebo komponentu nahraďte. Nález bez opravy by neměl zůstat otevřený bez rozhodnutí.

Vývojáři ignorují nálezy ze čtyř důvodů: chybí vlastník, kontext, termín, nebo jde o špatný kanál. Týmy, se kterými mluvíme, popisují, že vývoj vypínal skenery, protože výstup byl příliš hlučný na to, aby se dal číst. Odstraňte každý z důvodů: vlastník pro každý repozitář, připojený kontext z kroku 4, termín podle politiky a doručení tam, kde tým už pracuje.

Snižování šumu vs skrývání rizika

Menší backlog je lepší jen tehdy, když se zmenšil ze správných důvodů.

• Potlačení bez důvodu a data platnosti je skrytý dluh. Vrátí se při auditu nebo incidentu a nikdo už si nebude pamatovat proč.
• Prahy závažnosti chybné nálezy skrývají, místo aby je odstranily. „Nic pod CVSS 7“ nechá zmizet falešně pozitivní nález s CVSS 6 a ten s CVSS 9 ponechá na místě.
• Každé rozhodnutí neopravovat potřebuje záznam. Žádají o něj zákazníci i předpisy, jako je unijní Cyber Resilience Act, který od výrobců očekává řešení zranitelností po celou dobu podpory produktu.

Jak to měřit

• Nálezy na dodané vydání, ne na sken.
• Podíl nálezů, se kterými se něco udělalo: opravené, zmírněné nebo rozhodnuté.
• Uzavřené jako not affected se záznamem VEX oproti potlačeným bez něj.
• Doba od buildu k vlastníkovi: jak dlouho nový nález čeká, než ho někdo převezme.
• Míra duplicit napříč nástroji.

Vzorek 50 nálezů, který zvládnete za jedno odpoledne. Vyberte náhodně 50 otevřených nálezů. U každého zaznamenejte, zda se komponenta dodává ve vydání, zda stejný nález hlásí jiný nástroj nebo repozitář, zda je shoda správná, zda je zneužitelný ve vašem produktu, zda existuje oprava a kdo je vlastníkem. Počty vám řeknou, kterým krokem začít. Stejný vzorek spusťte znovu o čtvrtletí později. Pro tato čísla neuvádíme oborové benchmarky, protože žádný primární zdroj žádný nepodporuje.

Kde se uplatní CRACI

CRACI pracuje na krocích 1 a 2, na bráně buildu v kroku 3 a na částech kroků 4 a 5, u softwaru sestavovaného v GitHub Actions.

• Inventář. CRACI nahrazuje vaše runnery hostované na GitHubu a zaznamenává balíčky, které každý job skutečně stáhl, s PURL pro každou komponentu a stavem úplnosti pro každou SBOM. Každá komponenta v SBOM od CRACI byla v buildu. Tato přesnost se týká komponent SBOM; spárovaná CVE se přesto nemusí vašeho produktu týkat. K tomu slouží VEX a CRACI VEX podporuje.
• Jeden nález, mnoho buildů. Nálezy se agregují napříč buildy a repozitáři a monitorované SBOM se průběžně znovu vyhodnocují, jakmile jsou zveřejněny nové zranitelnosti.
• Brány. Kontrolní brány politik mohou build kvůli nálezům zastavit v reálném čase, včetně buildu, který obsahuje konkrétní CVE.
• Triáž a předávání. Bezpečnostní týmy provádějí triáž nálezů v CRACI a předávají každý z nich týmu, který opravu vlastní.
• Upozornění. CRACI upozorňuje příslušné osoby na zranitelnost a její závažnost.

CRACI nenabízí analýzu dosažitelnosti, SAST ani dashboardy MTTR. Celou funkci popisuje stránka sledování zranitelností, nebo zjistěte, co vaše buildy skutečně obsahují.

Kdy CRACI není řešením

• Většina vašeho šumu jsou nálezy SAST ve vašem vlastním kódu. To je problém ladění SAST.
• Váš backlog tvoří převážně skutečné, zneužitelné nálezy v dodávaném kódu. To je problém kapacity na nápravu, ne problém šumu.
• Potřebujete runtime kontext z produkčních workloadů. Na to odpoví CNAPP nebo nástroj pro runtime bezpečnost.

Širší plán najdete v článku co automatizovat, když počty CVE dál rostou, a aktuální čísla na stránce trendy ve zveřejňování CVE.

Snižování šumu zranitelností: časté dotazy

Jak snížit počet upozornění na zranitelnosti?

Omezte je u zdroje, v tomto pořadí: sjednoťte inventář s tím, co dodáváte, deduplikujte nálezy podle package URL, verze a CVE, dodávejte méně závislostí, přidejte kontext zneužitelnosti jako VEX, KEV a EPSS a to, co zbude, předejte vlastníkovi podle zapsané politiky. Teprve pak prioritizujte.

Proč náš skener hlásí tisíce zranitelností a které z nich jsou důležité?

Obvykle proto, že hlásí komponenty, které nedodáváte, hlásí stejnou CVE jednou za každý nástroj a repozitář a některé shody odhadne špatně. Důležité jsou ty v komponentách, které vaše vydání skutečně obsahuje, které jsou ve vašem produktu zneužitelné a o kterých je známo nebo je pravděpodobné, že budou zneužity.

Jak deduplikovat nálezy z několika bezpečnostních nástrojů?

Klíčujte každý nález podle package URL, verze a CVE a počítejte jeden nález na dodávaný artefakt. Agregujte napříč repozitáři, aby sdílená knihovna byla jedno rozhodnutí. Pak každý druh signálu svěřte jednomu nástroji, aby dva skenery přestaly hlásit totéž.

Máme potlačovat zranitelnosti, pro které neexistuje oprava?

Ne potichu. Rozhodněte se explicitně: přijměte riziko se zapsaným důvodem a datem platnosti, zmírněte ho, nebo komponentu nahraďte. Až se oprava objeví, rozhodnutí přehodnoťte. Potlačení bez důvodu a data platnosti je skrytý dluh.

Je zranitelnost, kterou nikdo rok neopravil, stále šum?

Ne nutně. Stáří nic neříká o riziku. Pokud se dodává a je zneužitelná, potřebuje rozhodnutí a vlastníka. Pokud se vašeho produktu netýká, zaznamenejte to jako prohlášení VEX, aby se přestala vracet. V obou případech by neměla zůstat otevřená bez rozhodnutí.

Jak zajistit, aby vývojáři bezpečnostní nálezy neignorovali?

Dejte každému nálezu vlastníka, kontext potřebný k jednání, termín podle zapsané politiky a doručte ho tam, kde tým už pracuje. Nejdřív odstraňte šum: vývojáři přestanou číst kanál, ve kterém většina nálezů nehraje roli.

Jaký je dobrý počet otevřených zranitelností?

Spolehlivý benchmark neexistuje a samotný počet je špatné měřítko. Sledujte nálezy na dodané vydání, podíl nálezů, se kterými se něco udělalo, podíl uzavřených se zaznamenaným důvodem a jak dlouho zůstávají známé zneužívané zranitelnosti v dodávaném softwaru otevřené.