Co je bezpečnost softwarového dodavatelského řetězce?

Co je softwarový dodavatelský řetězec?

Softwarový dodavatelský řetězec tvoří všichni a všechno, co se podílí na cestě softwaru z editoru vývojáře do produkce. Představte si ho ve čtyřech fázích, z nichž každá má svá rizika.

Fáze	Co do ní patří	Co se může pokazit
Zdrojový kód	Váš kód, repozitáře a účty vývojářů	Ukradené přihlašovací údaje, škodlivé commity, uniklé tajné klíče
Závislosti	Open source balíčky, základní image, kód třetích stran	Zranitelné verze, škodlivá vydání, typosquatting
Build	Runnery CI, GitHub Actions, nástroje pro build, cache	Kompromitované actions, otrávené cache, ukradené tajné klíče z pipeline
Vydání	Artefakty, registry, nasazení, aktualizace	Podvržené artefakty, upravené aktualizace, žádný záznam o tom, co bylo vydáno

Proč na tom záleží právě teď

Většinu toho, co dodáváte, jste nenapsali. Moderní aplikace je převážně open source a každá přímá závislost přináší další, které nikdo z vašeho týmu nevybral. Tyto balíčky běží se stejným přístupem jako váš vlastní kód a jejich instalační skripty mohou běžet uvnitř vaší pipeline CI, vedle vašich tajných klíčů.

Posledních několik let ukazuje, jak se toho využívá:

• SolarWinds: build byl kompromitován, takže z čistého zdrojového kódu vzniklo otrávené vydání.
• Log4Shell: chyba v jedné knihovně pro logování zasáhla produkty, které ani nevěděly, že ji používají.
• xz utils: důvěryhodný přispěvatel propašoval zadní vrátka do projektu, který je součástí linuxových distribucí.
• tj-actions: unesená GitHub Action spouštěla kód útočníka v pipeline, které ji používaly, s tajnými klíči na dosah.
• Shai-Hulud: červ se šířil přes balíčky npm a kradl tokeny ze strojů a jobů CI, které je instalovaly.

Jak tyto útoky krok za krokem fungují, popisuje stránka co je útok na dodavatelský řetězec.

Jak bezpečnost softwarového dodavatelského řetězce funguje

Program potřebuje čtyři věci. Všechno ostatní jsou detaily.

1. Vězte, co dodáváte. Udržujte přesnou SBOM pro každé vydání, z buildu, který ho vytvořil, včetně tranzitivních závislostí.
2. Kontrolujte, co se dostane dovnitř. Připínejte verze, používejte lockfile, omezte, odkud mohou buildy stahovat, a prověřujte nové balíčky.
3. Chraňte build. Izolujte joby, omezte tajné klíče, připínejte actions na commit a omezte odchozí provoz, aby kompromitovaný balíček nemohl vaše tokeny nikam odeslat. Viz bezpečnost runnerů a proč bezpečnost dodavatelského řetězce patří do CI.
4. Dál sledujte, co bylo vydáno. Nové zranitelnosti se týkají i softwaru, který už je v produkci. Monitorujte ho, dohledejte, kterých vydání se týkají, a sledujte každou opravu až do nového vydání.

Podrobný kontrolní seznam najdete v článku osvědčené postupy pro bezpečnost softwarového dodavatelského řetězce.

Rámce a předpisy

Název	Co to je	Nejvhodnější pro
SLSA	Úrovně integrity buildu a původu (provenance)	Zabezpečení způsobu, jakým se software sestavuje
NIST SSDF	Postupy bezpečného vývoje, SP 800-218	Ucelený program bezpečného vývoje
NIST SP 800-161	Řízení rizik kybernetické bezpečnosti v dodavatelském řetězci	Řízení rizik v celé organizaci
OpenSSF Scorecard	Automatizované kontroly stavu open source projektů	Prověřování závislostí
Cyber Resilience Act	Právní předpis EU pro produkty s digitálními prvky	Prodej v EU. Viz co je CRA

Jaké nástroje se používají?

Žádný jednotlivý produkt nepokryje vše. Kategorie se dělí na nástroje SCA, nástroje SBOM, bezpečnost CI/CD a runnerů, balíčkové firewally, správu bezpečnostního stavu aplikací (ASPM) a binární analýzu. Co který nástroj dělá a kdo ho prodává, najdete ve srovnání nástrojů pro bezpečnost softwarového dodavatelského řetězce a v přehledu kolik stojí.

Kde začít

1. Vygenerujte SBOM pro svůj nejdůležitější produkt z jeho buildu v CI a přečtěte si ji.
2. Zapněte upozornění na zranitelnosti závislostí a rozhodněte, kdo za ně odpovídá.
3. Připněte své GitHub Actions na commit a zkontrolujte tajné klíče, ke kterým mají vaše workflow přístup.
4. Omezte odchozí provoz z vašich buildů na hostitele, které skutečně potřebují.
5. Nastavte monitorování toho, co jste vydali, nejen toho, co právě sestavujete.

Jak k tomu přistupuje CRACI

CRACI začíná u buildu, protože build je jediné místo, které vidí všechno. Nahrazuje vaše runnery hostované na GitHubu rychlejšími a levnějšími runnery, které zaznamenávají každý balíček, který každý job stáhne, v každé hloubce stromu a včetně balíčků obnovených z cache CI. Egress policy blokuje spojení, která váš build nepotřebuje, takže vás chrání i před útokem, který ještě nikdo neviděl. CRACI pak dál kontroluje, co bylo vydáno, oproti novým zranitelnostem a sleduje každou z nich od triáže až po opravené vydání. Viz bezpečnost softwarového dodavatelského řetězce s CRACI.

Bezpečnost softwarového dodavatelského řetězce: časté dotazy

Co je bezpečnost softwarového dodavatelského řetězce?

Je to ochrana všeho, co jde do vašeho softwaru dříve, než se dostane k uživatelům: open source závislostí, build systémů, nástrojů v pipeline a vydání.

Jaký je příklad útoku na softwarový dodavatelský řetězec?

Při útoku na SolarWinds byl kompromitován build, takže zákazníci dostali otrávenou aktualizaci od důvěryhodného dodavatele. Při útocích Shai-Hulud se červ šířil přes balíčky npm a kradl tokeny ze strojů, které je instalovaly.

Jaký je rozdíl mezi bezpečností dodavatelského řetězce a bezpečností aplikací?

Bezpečnost aplikací se zabývá chybami v kódu, který píšete. Bezpečnost dodavatelského řetězce se zabývá tím, co jste nenapsali, a tím, jak se váš software sestavuje a vydává. Program potřebuje obojí.

Stačí SBOM pro bezpečnost dodavatelského řetězce?

Ne. SBOM vám řekne, co dodáváte, a to je základ. Musíte také kontrolovat, co se dostane dovnitř, chránit build a dál monitorovat, co jste vydali.

Jaké jsou hlavní rámce?

SLSA pro integritu buildu, NIST SSDF pro postupy bezpečného vývoje a NIST SP 800-161 pro řízení rizik dodavatelského řetězce. V EU stanoví Cyber Resilience Act právní požadavky na produkty s digitálními prvky.

Kdo za bezpečnost softwarového dodavatelského řetězce odpovídá?

Obvykle spadá pod bezpečnost aplikací nebo produktů, ve spolupráci s platformními a DevOps týmy, které provozují pipeline. Opravy pak putují k vývojovým týmům, které jednotlivé služby vlastní.