Životní cyklus správy zranitelností pro dodavatele softwaru

Co je životní cyklus správy zranitelností?

Životní cyklus správy zranitelností je opakovatelný proces, kterým se dodavatel produktu řídí při řešení zranitelnosti v softwaru, který dodává: přijmout ji nebo ji najít, ověřit ji, zjistit, co je dotčeno, opravit ji, vydat opravu a informovat zákazníky. V organizaci dodavatele ho obvykle vede tým pro reakci na bezpečnostní incidenty produktů (PSIRT) a opravy dělají vývojové týmy.

Tato stránka se věnuje straně dodavatele. IT správa zranitelností, tedy skenování a záplatování serverů a notebooků, které organizace provozuje, sdílí slovník, ale ne ty těžké části. Dodavatel musí odpovídat za každé podporované vydání v rukou zákazníků a musí zveřejnit, co zjistil.

Fáze životního cyklu

1. Přijetí nebo odhalení. Zranitelnosti přicházejí od externích výzkumníků přes váš program zveřejňování zranitelností, od zákazníků, od koordinátorů, jako jsou národní týmy CSIRT, i z vlastního monitorování: nové CVE v open source závislosti, nález skeneru nebo interní test. Každou zaevidujte s identifikátorem a externím oznamovatelům potvrďte přijetí.
2. Ověření a triáž. Reprodukujte problém nebo potvrďte shodu závislosti, rozhodněte, zda jde o zranitelnost ve vašem produktu, a ohodnoťte její závažnost a naléhavost. Co se netýká, uzavřete s odůvodněním, které později můžete doložit. Pořadí zbývajících nálezů pomáhají určit signály prioritizace, jako je EPSS a katalog CISA KEV.
3. Posouzení dotčených produktů a verzí. Najděte každý produkt, vydání a podporovanou větev, která obsahuje zranitelný kód nebo komponentu, a každé nasazení u zákazníka, které některé z nich provozuje. Tento krok určuje rozsah opravy i bezpečnostního upozornění.
4. Náprava. Tým, který kód vlastní, vyvine a otestuje opravu: aktualizovanou závislost, změnu kódu nebo zmírňující opatření, například změnu konfigurace, když oprava zatím není možná.
5. Vydání opravy. Dodejte aktualizované verze pro každou dotčenou podporovanou větev, a to kanálem, kterému zákazníci mohou důvěřovat.
6. Upozornění a zveřejnění. Zveřejněte bezpečnostní upozornění, které uvádí, co je dotčeno, jak je to závažné a co dělat, přidělte nebo uveďte ID CVE a uveďte oznamovatele. Strojově čitelné formáty, jako je CSAF a VEX, umožňují zákazníkům zpracovávat upozornění automaticky.
7. Monitorování a poučení. Sledujte zneužívání a nové informace, aktualizujte bezpečnostní upozornění a vracejte kořenovou příčinu zpět do vývoje, aby se stejná třída chyb znovu nedostala do vydání.

ISO/IEC 30111 a ISO/IEC 29147

Tento životní cyklus pro dodavatele popisují dvě mezinárodní normy. Dělí ho na hranici organizace:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Název	Procesy řešení zranitelností	Zveřejňování zranitelností
Pokrývá	Co se děje uvnitř: ověřování, prošetřování, prioritizaci a nápravu	Rozhraní: přijímání hlášení a zveřejňování bezpečnostních upozornění
Klíčový obsah	Politika a organizace, odpovědnosti týmu PSIRT, fáze řešení, aspekty dodavatelského řetězce	Role zúčastněných stran, zpracování hlášení, obsah bezpečnostních upozornění, koordinace, politika zveřejňování
Pro koho	Dodavatelé, kteří řeší nahlášené zranitelnosti	Dodavatelé, kteří přijímají hlášení a zveřejňují zranitelnosti

Normy jsou navrženy tak, aby se používaly společně. ISO/IEC 30111 uvádí šest fází řešení: přípravu, přijetí, ověření, vývoj nápravy, vydání a fázi po vydání. Požaduje také monitorování procesu, důvěrnost informací o zranitelnostech a pozornost k dodavatelskému řetězci, protože mnoho zranitelností se nachází v komponentách, které jste nenapsali. Obě normy jsou aktuálními vydáními, potvrzenými při posledních revizích ISO, a jsou označeny k revizi.

Stejný tvar mají i další rámce. FIRST PSIRT Services Framework člení práci na odhalování zranitelností, triáž a analýzu, nápravu a zveřejnění a IEC 62443-4-1 zahrnuje správu bezpečnostních aktualizací a vad do svého životního cyklu bezpečného vývoje průmyslových produktů.

Role

• Tým PSIRT nebo tým produktové bezpečnosti: vlastní proces, přijímá hlášení, provádí triáž, koordinuje opravy a zveřejňuje bezpečnostní upozornění. Viz CRACI pro týmy PSIRT a čím se PSIRT liší od CSIRT.
• Produktové a vývojové týmy: vlastní kód, vyvíjejí a testují opravy a dodávají vydání.
• Release management: rozhoduje, které podporované větve dostanou opravu a kdy.
• Zákaznická podpora a komunikace: řeší dotazy zákazníků a publikum bezpečnostního upozornění.
• Právní oddělení: radí ohledně zveřejňování, smluv a oznámení vůči regulátorům.
• Externí strany: oznamovatelé, koordinátoři, jako je CERT/CC nebo národní CSIRT, upstreamoví správci dotčených komponent a zákazníci, kteří musí opravu nasadit.

Lhůty a SLA

Žádná jednotná povinná lhůta neexistuje. Většina dodavatelů si stanovuje interní cíle podle závažnosti a ty externí zveřejňuje ve své politice zveřejňování. Typická struktura:

• Potvrzení externího hlášení během několika pracovních dní.
• Triáž během dní, aby oznamovatel i tým, který kód vlastní, věděli, jak na tom jsou.
• Náprava v termínu podle závažnosti a zneužívání, nejkratším u kritických nálezů a všeho, o čem je známo, že je zneužíváno.
• Zveřejnění, jakmile je oprava k dispozici, nebo v dohodnutém termínu, pokud se oprava zpozdí.

Vnější hranici určuje tlak zvenčí. Výzkumníci často stanovují termín zveřejnění (Google Project Zero dává dodavatelům 90 dní) a regulace přidává vlastní: EU Cyber Resilience Act vyžaduje, aby výrobci odstraňovali zranitelnosti „bez zbytečného odkladu“, a stanovuje lhůty pro hlášení aktivně zneužívaných zranitelností (viz co CRA požaduje). Když je zranitelnost už zneužívána, jako u zero-day, běží každá fáze v nejkratším termínu.

Kde se životní cyklus láme

Většina zdržení nevzniká při psaní opravy. Pramení z toho, že nevíte, co jste dodali.

• Nevíte, která vydání komponentu obsahují. V knihovně se objeví nové CVE. Která loňská vydání ji obsahují a kteří zákazníci je provozují? Bez záznamu pro každé vydání týmy znovu sestavují staré tagy nebo ručně prohledávají repozitáře a seznam dotčených verzí v bezpečnostním upozornění je jen odhad.
• Tranzitivní závislosti. Mnoho zranitelných balíčků jste si nevybrali. Přicházejí jako tranzitivní závislosti o několik úrovní níž, takže je prohledání vašich manifestů mine.
• Šum z vývojových závislostí. Skenery, které čtou lockfily, hlásí testovací frameworky a nástroje pro build, které se nikdy nedodávají. Každý takový nález stojí čas na triáž a zasypává nálezy, na kterých záleží.
• Komponenty mimo správce balíčků. Binárky stažené skripty buildu, základní image a komponenty dodavatelů se v lockfilu vůbec neobjeví.
• Nejasné vlastnictví. Nález, který žádný tým nevlastní, čeká. Triáž je hotová, až když má oprava vlastníka.
• Opravy, které nevydrží. Zranitelná verze se vrátí přes jinou závislost nebo starou větev, protože nic nebrání tomu, aby se dostala do dalšího buildu.

Malé týmy narazí na tato místa jako první, protože každé z nich se opakuje u každého CVE. Automatizace správy zranitelností popisuje, co a v jakém pořadí automatizovat, a jak omezit šum ze zranitelností se zabývá vývojovými závislostmi, duplicitami a nálezy bez vlastníka, které zasypávají ty důležité.

Metriky

Metrika	Co ukazuje
Doba do potvrzení	Zda se oznamovatelé dočkají odpovědi, kdy jim to vaše politika slibuje
Doba do triáže	Jak dlouho nález čeká, než někdo ví, zda na něm záleží
Doba do nápravy podle závažnosti	Jak rychle se opravy dodávají, měřeno od přijetí po dostupné vydání
Doba do bezpečnostního upozornění	Jak dlouho zákazníci po opravě čekají na informace
Podíl v rámci cíle	Zda se dodržují interní SLA, zejména u kritických a zneužívaných nálezů
Backlog podle stáří	Nálezy, které uvízly, a kde
Podíl nedotčených	Kolik úsilí při triáži padne na nálezy, které se netýkají

Měřte každou fázi zvlášť. Dlouhá doba do nápravy se často ukáže jako dlouhá doba hledání dotčených vydání.

Postavte životní cyklus na záznamu toho, co jste dodali

Každá fáze po triáži závisí na tom, že víte, co je v každém vydání. CRACI spouští vaše buildy z GitHub Actions na vlastních runnerech 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 CI a závislostí, které neuvádí žádný lockfile. Každá SBOM nese stav úplnosti a exportuje se jako CycloneDX nebo SPDX.

CRACI průběžně znovu vyhodnocuje monitorované SBOM a agreguje je napříč buildy a repozitáři. Lze přidat i SBOM od dodavatelů, aby se nakoupené komponenty monitorovaly spolu s vašimi vlastními. Když se objeví nové CVE, historie buildů ukáže, které minulé buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní, takže víte, v jakém období jste byli zasaženi, a inventář ukazuje, které verze softwaru jsou nasazeny ve kterých produktech. Bezpečnostní týmy provádějí triáž nálezů v CRACI a posílají je týmům, které vlastní opravu, CRACI podporuje VEX a kontrolní brány politik (policy gates) mohou blokovat buildy, které obsahují konkrétní CVE, aby opravená zranitelnost zůstala venku. Viz sledování zranitelností.

Životní cyklus správy zranitelností: časté dotazy

Jaké jsou fáze životního cyklu správy zranitelností?

Pro dodavatele produktu: přijmout nebo odhalit zranitelnost, ověřit ji a provést triáž, najít dotčené produkty a verze, vyvinout nápravu, vydat opravu, zveřejnit bezpečnostní upozornění a pak monitorovat a poučit se. ISO/IEC 30111 uvádí fáze příprava, přijetí, ověření, vývoj nápravy, vydání a fáze po vydání.

Co je ISO/IEC 30111?

ISO/IEC 30111:2019 je mezinárodní norma pro procesy řešení zranitelností. Dává dodavatelům požadavky a doporučení pro zpracování a nápravu nahlášených zranitelností v jejich produktech a službách, od politiky a role týmu PSIRT po fáze řešení a aspekty dodavatelského řetězce.

Jaký je rozdíl mezi ISO/IEC 30111 a ISO/IEC 29147?

ISO/IEC 29147 pokrývá vnější část: přijímání hlášení a zveřejňování bezpečnostních upozornění. ISO/IEC 30111 pokrývá vnitřní řešení mezi tím: ověřování, prošetřování, prioritizaci a opravu. Obě normy se mají používat společně. Stranu normy 29147 popisuje koordinované zveřejňování zranitelností.

Co je triáž zranitelností?

Triáž je krok, ve kterém bezpečnostní tým potvrdí, že nahlášená nebo odhalená zranitelnost je skutečná, posoudí, jak je pro váš produkt závažná a naléhavá, a předá ji týmu, který vlastní opravu. Dobrá triáž také uzavře nálezy, které se netýkají, se zaznamenaným důvodem.

Čím se správa zranitelností produktů liší od IT správy zranitelností?

IT správa zranitelností záplatuje systémy, které organizace provozuje. Správa zranitelností produktů řeší chyby v softwaru, který organizace sestavuje a dodává ostatním, takže přidává kroky, které IT týmy nemají: zjistit, které vydané verze jsou dotčeny, dodat opravu zákazníkům a informovat je o ní v bezpečnostním upozornění.

Jaké metriky by měl proces řešení zranitelností sledovat?

Dobu do potvrzení hlášení, dobu do triáže, dobu do nápravy a dobu do bezpečnostního upozornění, každou podle závažnosti, a dále podíl nálezů, které splňují vaše interní cíle, otevřený backlog podle stáří a počet nálezů uzavřených jako nedotčené.