SBOM: Recept na bezpečnější software

Stavíte dům z cihel od desítek různých dodavatelů, aniž byste znali jejich kvalitu nebo původ. Odvážné? Přesně tak dnes často vzniká software, a bezpečnostní incidenty začínají přesně tam, kde končí přehled. Dnes se podíváme na to, proč je SBOM (software bill of materials) klíčový pro stabilitu a bezpečnost vaší digitální stavby.

Jedna jediná zranitelnost. To je někdy vše, co je potřeba, aby byly útočníkům otevřeny dveře do firemní sítě. Vidět jsme to mohli na konci roku 2021, kdy byla odhalena kritická zero-day zranitelnost, umožňující spustit na postiženém serveru libovolný kód, nazývaná Log4Shell. Byla objevena v jedné z nejrozšířenějších Java knihoven na světě: Log4j.

Když se IT svět zastavil kvůli jedné knihovně

Log4j je, jak název napovídá, open-source nástroj pro logování od společností Apache. Tato knihovna v sobě měla jednu ‘chytrou’ funkci: místo, aby text, který dostala k zapsání, jen pasivně uložila, pokoušela se ho aktivně analyzovat. Pokud text vypadal jako speciální příkaz (konkrétně JNDI lookup), knihovna ho vykonala. Úmysl byl samozřejmě dobrý, ale jak se říká – dobrými úmysly je dlážděná cesta do pekla. Útočníkovi stačilo využít libovolné textové pole ve webové aplikaci, vložit do něj magický řetězec

a Log4j se rázem připojil na server útočníka, stáhl jeho škodlivý kód a spustil ho.

Na škále CVSS (Common Vulnerability Scoring System) dostal Log4Shell 10.0 z 10.0 – nejvyšší možné skóre. Znamená to, že zneužití zranitelnosti bylo natolik triviální, že to zvládne i začátečník, není potřeba autentizace vůči serveru, a ještě navíc umožňuje kompletní převzetí kontroly nad cílem. Mnoho bezpečnostních expertů tuto zranitelnost považovalo a považuje za nejkritičtější a nejvážnější zranitelnost vůbec. Její zneužití bylo tak snadné, že první zprávy o ní přišly z komunity hry Minecraft. Útočníci psali škodlivý řetězec do herního chatu, a když ho serverový log zaznamenal, servery byly kompromitovány. Během pár hodin už se pokoušeli zranitelnost využít i kyberzločinci.

Problém nebyla zranitelnost samotná, nýbrž její neviditelnost. Log4j byl všude. Výzkum provedený společnostmi Wiz a EY ukázal, že 93 % cloudových enterprise prostředí bylo zranitelných vůči Log4shell, a deset dní po zveřejnění zranitelnosti bylo v průměru opraveno pouze 45 % zranitelných workloadů. Každý ředitel bezpečnosti v každé IT firmě na světě se otočil na svůj tým a položil jedinou otázku: „Používáme Log4j?“ Jenomže málokdo dokázal odpovědět. Často šlo o tranzitivní závislosti – kód používal knihovnu X, ta ke své funkci používala knihovnu Y, a ta ke svému logování používala zranitelnou verzi Log4j. Bezpečnostní týmy strávily dny a týdny zoufalým skenováním serverů a ručním prohledáváním zdrojových kódů, aby zjistily, zda někde hluboko v útrobách jejich systémů není tikající bomba. Tímhle vším se nesnažím říct, že by se přišlo na to, že je software zranitelný. To jsme věděli. Co jsme nevěděli je, že firmy mnohdy vůbec netuší, z čeho je jejich software postaven.

Hrdina jménem SBOM

Open Source Security and Risk Analysis (OSSRA) analýza od firmy Synopsis v roce 2024 odhalila, že 96 % komerčních softwarových projektů obsahuje open-source komponenty. Co je ještě významnější – v analyzovaných projektech tvořil open-source kód v průměru 77 % celého zdrojového kódu. Jinými slovy: téměř každý software používá cizí knihovny a ty mnohdy v softwaru převažují oproti vlastnímu kódu. Proto v moment, kdy přijde od panikařícího ředitele bezpečnosti otázka, zda se v našem softwaru nachází knihovna X, je dobré být připravený. Trn z paty nám v tomto dokáže vytrhnout seznam komponent softwaru, pro nějž používáme anglickou zkratku SBOM.

SBOM je trochu jako seznam ingrediencí na obalu potravin. Když si kupujete sušenku, dočtete se, že obsahuje mouku, cukr a vejce. Co je ale ještě důležitější, říká vám také, že obsahuje stopy arašídů. Pokud máte na arašídy smrtelnou alergii, je to pro vás ta nejdůležitější informace na celém obalu.

Log4Shell byla pro svět softwaru masivní alergie na arašídy. Firmy, které měly k dispozici aktuální SBOM, byly v obrovské výhodě. Místo panického skenování a ručního hledání jim stačil jeden prostý dotaz: „Který z našich produktů má v sobě log4j-core ve verzi nižší než 2.15.0?“ Během minut, ne-li rychleji, měli jasný seznam systémů, které je třeba urychleně opravit. Ostatní trávili advent prohledáváním kódu.

Co přesně SBOM je?

Formálně řečeno, SBOM je strukturovaný, strojově čitelný seznam všech komponent, knihoven a modulů, které jsou obsaženy v daném softwarovém produktu.

Je důležité říct, že se jedná o datový soubor, nejčastěji typu JSON, ve standardizovaném formátu, typicky SPDX nebo CycloneDX, který mohou automatizovaně číst a analyzovat bezpečnostní nástroje (např. OWASP Dependency-Track). Z toho tedy také vyplývá, že SBOM se negeneruje ručně. Používají se na to automatizované nástroje – Syft, Tern, CycloneDX aj.

Generování SBOMu by mělo být automatickou součástí vašeho CI/CD procesu. Pokaždé, když sestavíte novou verzi, vygeneruje se i nový SBOM, který je možné také rovnou z pipeline nahrát do bezpečnostního nástroje.

Důležitost SBOMu roste

Možná si říkáte, že je to jen zase další otravná byrokracie. SBOM ale řeší hned tři klíčové oblasti moderního vývoje softwaru.

1. Řízení zranitelností

   Jak ukázal Log4Shell, rychlost je vším. Když je oznámena nová kritická zranitelnost (CVE), závodíte s útočníky. SBOM vám dává okamžitý přehled a mění vaši reakční dobu z dnů/týdnů na minuty. Umožňuje vám proaktivně identifikovat rizika ještě předtím, než jsou zneužita.

2. Řízení licencí

   Ani open-source není zadarmo bez pravidel. Každá knihovna má nějakou licenci. Některé licence mohou vyžadovat, abyste při jejich použití ve svém produktu také zveřejnili svůj vlastní zdrojový kód. Použití takové knihovny bez vědomí právního oddělení může vést k drahým soudním sporům nebo ztrátě duševního vlastnictví. SBOM v tomto dělá naprostý pořádek.

3. Transparentnost a legislativa

   Ať chceme nebo ne, trh se mění, nároky rostou. Po vlně velkých útoků, z nichž nejvýznamnější (kromě Log4Shell) byl supply-chain útok na firmu SolarWinds v roce 2020, už zákazníci a regulátoři nechtějí věřit slibům. Chtějí důkazy.

• USA (Executive Order 14028): Vláda USA po útoku na SolarWinds vydala nařízení, které vyžaduje, aby každý software prodávaný federálním agenturám byl dodávaný spolu s SBOMem. A jelikož americká vláda je jedním z největších zákazníků na světě, tento krok v podstatě nutí celý trh začít SBOM řešit.
• EU (Cyber Resilience Act): Tato nová evropská regulace, která vešla v platnost v prosinci 2024 a jež plné účinnosti nabude 11. prosince 2027, míří přímo na výrobce softwaru a hardwaru. V podstatě říká, že pokud chcete prodávat svůj produkt s digitálními prvky na trhu EU, musíte prokázat, že je bezpečný. Klíčovou součástí tohoto důkazu je povinnost SBOMy vytvářet, poskytovat a aktivně hlásit zranitelnosti.
• ČR (NIS2/ZoKB): U nás nově od 1. listopadu platí novelizovaný Zákon o kybernetické bezpečnosti, reflektující směrnici NIS2, která míří primárně na provozovatele kritických služeb (banky, nemocnice, energetika). Přímo jim nařizuje řídit rizika svého dodavatelského řetězce, což v praxi znamená, že tyto velké subjekty nyní musí aktivně zjišťovat, jak bezpečný je software, který nakupují.

Zkrátka vzniká a sílí regulační tlak, který nutí firmy SBOM vytvářet a distribuovat. Rychle se přesouváme z kategorie “konkurenční výhoda” do kategorie “povinná výbava” a podmínka pro vstup na trh.

SBOM je jen první krok

Mít SBOM je skvělé. Trochu jako mít inventární seznam skladu. Ten seznam vám ale sám o sobě neřekne, že jedna z položek v regálu 46A právě začala hořet.

Vytvoření SBOMu je jen první krok. Ten druhý, náročnější, je mít procesy pro jeho aktivní správu a monitorování. A i s tím pomáháme našim zákazníkům my. Nestačí totiž SBOM jednou vygenerovat. Musí být součástí celého životního cyklu vývoje. Musí být automaticky analyzován a neustále porovnáván s globálními databázemi zranitelností a licencí.

V Edhouse pomáháme firmám nejen vědět, z čeho je jejich software postaven, ale zajistit, aby byl bezpečný, v souladu s licencemi a připravený na budoucnost.