Řízení rizik softwarového dodavatelského řetězce

Řízení rizik vs. bezpečnost

Bezpečnost softwarového dodavatelského řetězce je soubor technických kontrol: SBOM, připnuté závislosti, omezené buildy. Řízení rizik stojí nad nimi. Ptá se, na kterých dodavatelích a komponentách vaše firma závisí, co se stane, když některý z nich selže, a zda jste své úsilí vynaložili na správném místě.

Jaká rizika existují?

Riziko	Příklad	Hlavní kontrola
Zranitelné komponenty	Chyba v široce používané knihovně	SBOM a průběžné monitorování
Škodlivé komponenty	Unesený balíček nebo typosquatting	Prověřování, odložené přijetí, omezení odchozího provozu
Opuštěné projekty	Závislost s jediným správcem, který už se věnuje jinému	Kontroly stavu projektu a plán náhrady
Licenční riziko	Komponenta s copyleftem v proprietárním produktu	Licenční politika
Kompromitace buildu	Unesená GitHub Action se dostane k vašim tajným klíčům	Připínání, izolace, nejnižší oprávnění
Riziko dodavatele	Produkt nebo aktualizace dodavatele je kompromitována	Posouzení, smlouvy, SBOM od dodavatelů
Regulatorní riziko	Zákazník nebo zákon vyžaduje důkazy, které nedokážete předložit	Záznamy vedené pro každé vydání

Postup v šesti krocích

1. Sestavte inventář. Sepište produkty, které vyrábíte, a software, který kupujete. U toho, co vyvíjíte, uchovávejte SBOM pro každé vydání. Co nevidíte, nemůžete posoudit.
2. Seřaďte podle důležitosti. Knihovna ve vaší platební službě není totéž co knihovna v interním nástroji. Hodnoťte produkty podle expozice, dat a dopadu na byznys.
3. Posuďte rizika. Podívejte se na zranitelnosti, stav projektů, licence a na to, jak jednotliví dodavatelé přistupují k bezpečnosti. U nejvyšší úrovně to dělejte do hloubky, u všeho ostatního zběžně.
4. Ošetřete je. U každého rizika rozhodněte, zda je opravíte, nahradíte, přidáte kontrolu, nebo je přijmete. Přijaté riziko potřebuje vlastníka a datum revize.
5. Monitorujte průběžně. Riziko se mění, i když na vaší straně nic nezměníte, například když vyjde bezpečnostní upozornění nebo odejde správce projektu. Roční revize to přehlédnou.
6. Reportujte. Dejte vedení stručný přehled: hlavní rizika, expozici v čase a co bylo přijato. Podrobnosti si vyžádají zákazníci a auditoři.

Posuzování dodavatelů

Samotné dotazníky vám řeknou, co dodavatel tvrdí. Žádejte věci, které ukazují, co skutečně dělá:

• SBOM produktu s uvedeným formátem a způsobem, jak získávat aktualizace
• Jak řeší zranitelnosti a jak rychle informuje zákazníky
• Bezpečnostní kontakt a politiku zveřejňování
• Jak sestavuje vydání a zda dokáže ukázat, odkud vydání pochází
• Jak dlouho verze dostává bezpečnostní opravy
• Certifikace a auditní zprávy, které pokrývají produkt, který kupujete

Zapracujte očekávání do smluv. Vyžadovat SBOM nebo lhůtu pro oznámení při podpisu je mnohem snazší než po incidentu.

Rámce, kterými se řídit

• NIST SP 800-161 je hlavní referencí pro řízení kybernetických rizik dodavatelského řetězce, neboli C-SCRM. Funguje na všech úrovních organizace a začleňuje riziko dodavatelského řetězce do širšího řízení rizik.
• NIST SSDF pokrývá postupy bezpečného vývoje, což z něj dělá dobrý základ pro to, co požadujete po dodavatelích i po sobě.
• SLSA vám dává společný jazyk pro to, jak důvěryhodný build je.
• ISO/IEC 27001:2022 obsahuje kontroly pro bezpečnost dodavatelského řetězce ICT (Annex A 5.21) a technické zranitelnosti (8.8). SBOM nevyžaduje, ale SBOM jsou pro tyto kontroly dobrým důkazem.
• NIS2 v článku 21(2)(d) uvádí bezpečnost dodavatelského řetězce jako povinné opatření pro subjekty, na které se vztahuje.

Co SBOM v rámci každého z nich dokazují, kontrolu po kontrole, viz SBOM jako důkaz pro ISO 27001, SOC 2 a NIS2.

Jak to měřit

Vyberte několik ukazatelů, které vedou k rozhodnutím:

• Podíl produktů se SBOM pro aktuální vydání
• Doba do odpovědi na otázku „jsme zasaženi?“ u nové kritické zranitelnosti
• Okno expozice: jak dlouho byla zranitelná verze v produkci
• Podíl dodavatelů nejvyšší úrovně posouzených za poslední rok
• Počet přijatých rizik po datu jejich revize

Kde pomáhá CRACI

CRACI dává programu řízení rizik data, která mu u softwaru, který vyvíjíte, obvykle chybějí. Zaznamenává, co každý build v GitHub Actions stáhl, včetně deklarovaných licencí, do SBOM, které můžete uchovávat pro každé vydání a sdílet v CycloneDX nebo SPDX. Monitoruje to, co bylo dodáno, ukazuje, které buildy obsahovaly zranitelný balíček, abyste viděli období, kdy jste byli zasaženi, a umí vynucovat licenční politiku a blokovat buildy pomocí policy gates. Viz bezpečnost softwarového dodavatelského řetězce s CRACI a srovnání nástrojů.

Posuzování dodavatelů a registr rizik zůstávají ve vašich nástrojích pro governance a u vašeho týmu.

Řízení rizik softwarového dodavatelského řetězce: časté dotazy

Co je řízení rizik softwarového dodavatelského řetězce?

Je to způsob, jakým organizace identifikuje, posuzuje a snižuje riziko ze softwaru, který sama nenapsala, včetně open source balíčků, komerčních produktů, dodavatelů SaaS a nástrojů pro build.

Co je C-SCRM?

C-SCRM znamená cybersecurity supply chain risk management, tedy řízení kybernetických rizik dodavatelského řetězce, jak jej nazývá NIST. Hlavním vodítkem je NIST SP 800-161, který popisuje, jak nacházet, vyhodnocovat a snižovat kybernetická rizika v celém dodavatelském řetězci na všech úrovních organizace.

Jaká jsou největší rizika softwarového dodavatelského řetězce?

Zranitelné a škodlivé open source komponenty, kompromitované build systémy a nástroje CI, opuštěné projekty, licenční problémy a dodavatelé, u nichž dojde k průniku.

Jak se liší od řízení rizik třetích stran?

Řízení rizik třetích stran obvykle posuzuje dodavatele jako firmy. Řízení rizik softwarového dodavatelského řetězce jde až na úroveň komponent a procesů buildu, včetně open source projektů, za nimiž žádný dodavatel nestojí.

Kdo za něj odpovídá?

Obvykle program nastavuje vedení bezpečnosti nebo řízení rizik, produktová bezpečnost odpovídá za to, co firma vyvíjí, a nákup nebo správa dodavatelů za to, co kupuje. Inženýrské týmy opravují, co se najde.