Zarządzanie ryzykiem łańcucha dostaw oprogramowania

Zarządzanie ryzykiem a bezpieczeństwo

Bezpieczeństwo łańcucha dostaw oprogramowania to zestaw kontroli technicznych: SBOM-y, przypięte zależności, ograniczone buildy. Zarządzanie ryzykiem jest ponad nimi. Pyta, od których dostawców i komponentów zależy Państwa firma, co się stanie, gdy któryś zawiedzie, i czy wysiłek włożono we właściwe miejsce.

Jakie są ryzyka?

Ryzyko	Przykład	Główna kontrola
Podatne komponenty	Błąd w szeroko używanej bibliotece	SBOM-y i ciągłe monitorowanie
Złośliwe komponenty	Przejęty pakiet lub typosquatting	Weryfikacja, opóźnione wdrażanie, limity ruchu wychodzącego
Porzucone projekty	Zależność z jednym opiekunem, który zajął się czymś innym	Kontrole kondycji i plan zastąpienia
Ryzyko licencyjne	Komponent copyleft w produkcie własnościowym	Polityka licencyjna
Przejęcie buildu	Przejęta akcja GitHub dociera do Państwa sekretów	Przypinanie, izolacja, najmniejsze uprawnienia
Ryzyko dostawcy	Produkt lub aktualizacja dostawcy zostaje przejęta	Ocena, umowy, SBOM-y od dostawców
Ryzyko regulacyjne	Klient lub prawo wymaga dowodów, których nie są Państwo w stanie przedstawić	Zapisy prowadzone dla każdego wydania

Proces w sześciu krokach

1. Zbudować inwentarz. Wypisać wytwarzane produkty i kupowane oprogramowanie. Dla tego, co Państwo budują, prowadzić SBOM na każde wydanie. Nie da się ocenić tego, czego nie widać.
2. Uszeregować według znaczenia. Biblioteka w usłudze płatności to nie to samo co biblioteka w narzędziu wewnętrznym. Produkty należy oceniać pod kątem ekspozycji, danych i wpływu na biznes.
3. Ocenić ryzyka. Przyjrzeć się podatnościom, kondycji projektów, licencjom i temu, jak każdy dostawca podchodzi do bezpieczeństwa. Dogłębnie dla najwyższego poziomu, pobieżnie dla całej reszty.
4. Zająć się nimi. Dla każdego ryzyka zdecydować: naprawić, zastąpić, dodać kontrolę lub zaakceptować. Zaakceptowane ryzyko potrzebuje właściciela i daty przeglądu.
5. Monitorować w sposób ciągły. Ryzyko zmienia się bez żadnej zmiany po Państwa stronie, na przykład gdy zostaje opublikowany biuletyn lub odchodzi opiekun projektu. Coroczne przeglądy tego nie wychwytują.
6. Raportować. Przekazywać kierownictwu krótki obraz: największe ryzyka, ekspozycja w czasie i co zaakceptowano. O szczegóły zapytają klienci i audytorzy.

Ocena dostawców

Same kwestionariusze mówią, co dostawca deklaruje. Warto prosić o rzeczy, które pokazują, co faktycznie robi:

• SBOM produktu, z określonym formatem i sposobem otrzymywania aktualizacji
• Jak obsługuje podatności i jak szybko informuje klientów
• Kontakt ds. bezpieczeństwa i politykę ujawniania
• Jak buduje wydania i czy potrafi wykazać, skąd pochodzi wydanie
• Jak długo wersja otrzymuje poprawki bezpieczeństwa
• Certyfikaty i raporty z audytów obejmujące kupowany produkt

Oczekiwania warto wpisać do umów. Znacznie łatwiej wymagać SBOM lub określonego czasu powiadomienia przy podpisaniu niż po incydencie.

Frameworki, którymi warto się kierować

• NIST SP 800-161 to główne źródło w zakresie zarządzania ryzykiem cyberbezpieczeństwa w łańcuchu dostaw (C-SCRM). Działa na każdym poziomie organizacji i włącza ryzyko łańcucha dostaw do szerszego zarządzania ryzykiem.
• NIST SSDF obejmuje praktyki bezpiecznego wytwarzania, co czyni go dobrą podstawą wymagań wobec dostawców i wobec siebie.
• SLSA daje wspólny język do opisu tego, na ile build jest godny zaufania.
• ISO/IEC 27001:2022 zawiera kontrole dotyczące bezpieczeństwa łańcucha dostaw ICT (załącznik A 5.21) i podatności technicznych (8.8). Nie wymaga SBOM, ale SBOM-y są dobrym dowodem dla tych kontroli.
• NIS2 wymienia bezpieczeństwo łańcucha dostaw jako wymagany środek dla podmiotów objętych dyrektywą, w art. 21 ust. 2 lit. d.

Jak to mierzyć

Warto wybrać kilka miar, które prowadzą do decyzji:

• Odsetek produktów z SBOM dla bieżącego wydania
• Czas odpowiedzi na pytanie „czy to nas dotyczy?” przy nowej krytycznej podatności
• Okno ekspozycji: jak długo podatna wersja działała na produkcji
• Odsetek dostawców najwyższego poziomu ocenionych w ostatnim roku
• Liczba zaakceptowanych ryzyk po terminie przeglądu

W czym pomaga CRACI

CRACI dostarcza programowi zarządzania ryzykiem dane, których zwykle brakuje dla budowanego oprogramowania. Rejestruje, co pobrał każdy build GitHub Actions, łącznie z deklarowanymi licencjami, w SBOM-ach, które można przechowywać dla każdego wydania i udostępniać w formacie CycloneDX lub SPDX. Monitoruje to, co dostarczono, pokazuje, które buildy zawierały podatny pakiet, dzięki czemu widać okres narażenia, a także może egzekwować politykę licencyjną i blokować buildy za pomocą bramek polityk. Zob. bezpieczeństwo łańcucha dostaw oprogramowania z CRACI oraz porównanie narzędzi.

Ocena dostawców i rejestr ryzyk pozostają w Państwa narzędziach do ładu korporacyjnego i w rękach Państwa zespołu.

Zarządzanie ryzykiem łańcucha dostaw oprogramowania: najczęściej zadawane pytania

Czym jest zarządzanie ryzykiem łańcucha dostaw oprogramowania?

To sposób, w jaki organizacja rozpoznaje, ocenia i ogranicza ryzyko związane z oprogramowaniem, którego sama nie napisała, w tym z pakietami open source, produktami komercyjnymi, dostawcami SaaS i narzędziami buildu.

Czym jest C-SCRM?

C-SCRM to skrót od cybersecurity supply chain risk management, czyli zarządzania ryzykiem cyberbezpieczeństwa w łańcuchu dostaw. Tego terminu używa NIST. Główne wytyczne to NIST SP 800-161, które opisują, jak znajdować, oceniać i ograniczać ryzyko cybernetyczne w całym łańcuchu dostaw na każdym poziomie organizacji.

Jakie są największe ryzyka w łańcuchu dostaw oprogramowania?

Podatne i złośliwe komponenty open source, przejęte systemy buildu i narzędzia CI, porzucone projekty, problemy licencyjne oraz dostawcy, którzy padli ofiarą włamania.

Czym różni się to od zarządzania ryzykiem stron trzecich?

Zarządzanie ryzykiem stron trzecich zwykle traktuje dostawców jako firmy. Zarządzanie ryzykiem łańcucha dostaw oprogramowania schodzi do poziomu komponentów i procesów buildu, w tym projektów open source, za którymi nie stoi żaden dostawca.

Kto za to odpowiada?

Zazwyczaj kierownictwo ds. bezpieczeństwa lub ryzyka ustala program, zespół bezpieczeństwa produktu odpowiada za to, co firma buduje, a dział zakupów lub zarządzania dostawcami za to, co kupuje. Zespoły inżynierskie naprawiają to, co zostanie znalezione.