Vyjde kritická zranitelnost, bezpečnostní upozornění se rozšíří a do hodiny se někdo ve firemním chatu zeptá: týká se nás to? Log4Shell tuto otázku proslavil. CVE-2021-44228 se týkalo Log4j Core od verze 2.0-beta9 do 2.15.0, knihovny, která ležela několik úrovní hluboko ve stromu závislostí nespočtu produktů v Javě, a většina týmů musela pracně zjišťovat, kde všude je.

Otázka zní jednoduše. Ve skutečnosti jde o tři otázky:

  1. Je zranitelná komponenta v něčem, co sestavujeme nebo dodáváme?
  2. Pokud ano, dá se v našem produktu zneužít?
  3. Odkdy a ve kterých vydáních?

Většina procesů odpoví na první dvě. Třetí je ta, na kterou se zákazníci, auditoři a regulátoři zeptají hned potom, a dodatečně se na ni odpovídá nejhůř.

Krok 1: Zjistěte, zda tam komponenta je

Firmy se k odpovědi obvykle dostanou jedním ze čtyř způsobů, zhruba v pořadí podle vyspělosti.

Zeptat se a hledat. Někdo napíše do Slacku, inženýři prohledají své repozitáře a lockfily podle názvu balíčku a odpovědi se sbírají v tabulce. Stále jde o nejběžnější metodu. Je pomalá, závisí na tom, kdo odpoví, a přehlédne vše, co není deklarováno v souboru: závislosti závislostí, vendorované knihovny, základní image, nástroje instalované během buildu.

Zkontrolovat dashboardy skenerů. Skenery závislostí označí CVE v každém repozitáři během několika hodin. To je rychlejší, ale skener hlásí stav kódu, který má dnes před sebou, obvykle výchozí větve. Neřekne vám, která vydání vaši zákazníci provozují, ani co build před třemi měsíci skutečně stáhl.

Dotázat se inventáře SBOM. Týmy, které vedou softwarový kusovník pro každé vydání, mohou položit jednu otázku napříč všemi: které produkty a verze obsahují dotčené verze tohoto balíčku? Je to první metoda, která odpovídá za software, který jste dodali, nejen za software v repozitáři.

Párovat průběžně. Když se SBOM průběžně monitorují proti datům o zranitelnostech, seznam dotčených produktů existuje dřív, než se kdokoli zeptá. Vlákno v chatu začíná odpovědí, ne otázkou.

Kvalita každé metody závisí na tom, co inventář skutečně obsahuje. Obvyklá slepá místa jsou:

  • Tranzitivní závislosti. Zranitelný balíček jste málokdy přidali sami. Přichází o tři nebo čtyři úrovně níž.
  • Cokoli, co manifest nedeklaruje. Balíčky instalované skripty buildu, nástroje přes npx, kroky v Dockerfilu, obnovené cache a vendorovaný kód v C a C++.
  • Stará vydání. Větev, která se už nesestavuje, nelze znovu naskenovat, ale produkt z ní sestavený může být stále v provozu.

Krok 2: Rozhodněte, zda na tom záleží

Komponenta může být přítomna, aniž by představovala skutečné riziko, takže dalším krokem je triáž:

  • Verze a konfigurace. Spadá verze přesně do dotčeného rozsahu? Je zranitelná funkce zkompilována a zapnuta?
  • Dosažitelnost. Volá váš kód zranitelnou funkci vůbec?
  • Expozice. Je komponenta dosažitelná ze sítě nebo z nedůvěryhodného vstupu, nebo se používá jen během buildu?
  • Zmírňující opatření. Existuje sandboxing, omezení sítě nebo konfigurace, která zneužití zablokuje?
  • Signály zneužívání. CVSS udává závažnost, EPSS odhaduje pravděpodobnost, že CVE bude v příštích 30 dnech zneužito, a katalog Known Exploited Vulnerabilities od CISA uvádí ty, které už jsou v praxi zneužívány. Společně rozhodují, na co se podívat nejdřív.

Krok 3: Zaznamenejte rozhodnutí

Výsledek se zaznamenává pro každý produkt a verzi, stále častěji jako prohlášení VEX (Vulnerability Exploitability eXchange). Minimální požadavky na VEX od CISA definují čtyři stavy: not affected, affected, fixed a under investigation. Prohlášení „not affected“ musí uvést důvod, například že zranitelný kód není přítomen nebo na něj útočník nedosáhne.

Tento záznam napájí vše, co následuje: opravu a vydání, která ji nesou, bezpečnostní upozornění pro zákazníky a jakoukoli zprávu, kterou očekává regulátor. Podle unijního Cyber Resilience Act například musí výrobce odeslat včasné varování o aktivně zneužívané zranitelnosti ve svém produktu do 24 hodin od okamžiku, kdy se o ní dozvěděl.

Krok 4: Určete dobu expozice

Otázka „týká se nás to?“ má druhou polovinu, která se často přeskakuje: jak dlouho se nás to týkalo?

Zranitelnost existovala dávno před zveřejněním CVE. Log4Shell byl v Log4j od verze 2.0-beta9, vydané roky předtím, než ho kdokoli zveřejnil. Vaše expozice začala dnem, kdy build poprvé stáhl zranitelnou verzi, a skončila dnem, kdy byl nahrazen poslední build, který ji obsahoval. Tuto dobu potřebujete k tomu, abyste:

  • řekli zákazníkům, kterých z vydání, která provozují, se to týká, nejen toho posledního
  • vymezili vyšetřování incidentu na správné období, pokud mohla být zranitelnost zneužita
  • ukázali auditorovi nebo regulátorovi, kdy se problém dostal do produktu a kdy byla dodána oprava

Skenování dnešního kódu vám to nedá. Současný lockfile říká, co repozitář chce teď, ne co nainstaloval každý minulý build. Jediným spolehlivým zdrojem je záznam každého buildu, pořízený během jeho běhu a uchovaný i potom.

Jak na to odpovídá CRACI

CRACI spouští vaše joby GitHub Actions na vlastních runnerech a zaznamenává každý balíček, který každý build skutečně stáhne, přímý i tranzitivní, včetně balíčků instalovaných skripty a obnovených z cache. SBOM každého buildu se uchovává, takže když vyjde CVE, historie už existuje.

Když přijde nové CVE, odpověď už je k dispozici: každý minulý build a jeho SBOM, které z nich obsahovaly zranitelnou závislost, přímou či tranzitivní, a období, kdy se vás to týkalo. Žádná tabulka, žádné opakované skenování, žádná rekonstrukce z lockfilů. První build, který ji obsahoval, a build, který ji odstranil, vám dají dobu expozice, tak daleko do minulosti, jak sahá vaše doba uchovávání (ve výchozím stavu 180 dní, vlastní doba uchovávání v tarifu Enterprise).

Jakmile to víte, může policy gate blokovat buildy, které toto CVE obsahují, aby pozdější aktualizace závislostí nebo obnovená cache nemohly zranitelnou verzi potichu vrátit do vydání.

Odtud má zbytek procesu na čem stavět:

  • CRACI průběžně monitoruje SBOM, takže nová CVE se párují s vašimi buildy, aniž by se kdokoli ptal.
  • Bezpečnostní týmy provádějí triáž nálezů a předávají je týmům, které vlastní opravu, a CRACI podporuje VEX pro záznam výsledku.
  • Inventář CRACI ukazuje, které verze softwaru jsou nasazeny ve kterých produktech.
  • Pro CRA připravuje CRACI obsah včasného varování, oznámení a závěrečné zprávy; podává je člověk z vaší firmy přes Single Reporting Platform (jednotná platforma pro podávání zpráv).

Jakmile to víte, informujte zákazníky: článek jak odpovídat zákazníkům po útoku na dodavatelský řetězec obsahuje šablony pro první prohlášení i pro každý výsledek. Pokud otázky přicházejí po stovkách, přečtěte si o škálování týmu PSIRT.

Rezervujte si demo a podívejte se na historii buildů jednoho z vašich vlastních repozitářů.