Łańcuch dostaw
Czym jest bezpieczeństwo łańcucha dostaw oprogramowania?
Bezpieczeństwo łańcucha dostaw oprogramowania to praktyka ochrony wszystkiego, co trafia do Państwa oprogramowania, zanim dotrze ono do użytkowników: pakietów open source, systemu buildu, narzędzi w pipeline'ie i samego wydania. Napastnicy coraz częściej atakują te elementy zamiast Państwa aplikacji, ponieważ jeden przejęty pakiet lub krok buildu dociera do każdego produktu, który z niego korzysta.
Zaktualizowano
Czym jest łańcuch dostaw oprogramowania?
Łańcuch dostaw oprogramowania to wszyscy i wszystko, co bierze udział w drodze oprogramowania z edytora programisty na produkcję. Można go podzielić na cztery etapy, z których każdy ma własne ryzyka.
| Etap | Co obejmuje | Co może pójść nie tak |
|---|---|---|
| Źródło | Państwa kod, repozytoria i konta programistów | Skradzione poświadczenia, złośliwe commity, wyciek sekretów |
| Zależności | Pakiety open source, obrazy bazowe, kod zewnętrzny | Podatne wersje, złośliwe wydania, typosquatting |
| Build | Runnery CI, GitHub Actions, narzędzia buildu, cache | Przejęte akcje, zatrute cache, skradzione sekrety pipeline'u |
| Wydanie | Artefakty, rejestry, wdrożenia, aktualizacje | Podmienione artefakty, zmanipulowane aktualizacje, brak zapisu tego, co dostarczono |
Dlaczego to ważne właśnie teraz
Większości tego, co Państwo dostarczają, nie napisali Państwo sami. Współczesna aplikacja to w większości open source, a każda zależność bezpośrednia wprowadza kolejne, których nikt w Państwa zespole nie wybrał. Te pakiety działają z takimi samymi uprawnieniami jak Państwa kod, a ich skrypty instalacyjne mogą działać w Państwa pipeline'ie CI, tuż obok sekretów.
Wydarzenia ostatnich lat pokazują, jak się to wykorzystuje:
- SolarWinds: przejęto build, więc czysty kod źródłowy dał zatrute wydanie.
- Log4Shell: błąd w jednej bibliotece logowania dotarł do produktów, które nawet nie wiedziały, że jej używają.
- xz utils: zaufany współtwórca przemycił tylną furtkę do projektu obecnego w dystrybucjach Linuksa.
- tj-actions: przejęta akcja GitHub uruchamiała kod napastnika w korzystających z niej pipeline'ach, w zasięgu sekretów.
- Shai-Hulud: robak rozprzestrzeniał się przez pakiety npm, kradnąc tokeny z maszyn i zadań CI, które je zainstalowały.
Jak te ataki przebiegają krok po kroku, wyjaśnia strona czym jest atak na łańcuch dostaw.
Jak działa bezpieczeństwo łańcucha dostaw oprogramowania
Program potrzebuje czterech rzeczy. Cała reszta to szczegóły.
- Wiedzieć, co jest dostarczane. Prowadzić dokładny SBOM dla każdego wydania, z buildu, który je wytworzył, łącznie z zależnościami przechodnimi.
- Kontrolować, co wchodzi. Przypinać wersje, używać lockfile, ograniczać źródła, z których buildy mogą pobierać, i weryfikować nowe pakiety.
- Chronić build. Izolować zadania, ograniczać sekrety, przypinać akcje do commitów i ograniczać ruch wychodzący, aby przejęty pakiet nie mógł nigdzie wysłać Państwa tokenów. Zob. bezpieczeństwo runnerów oraz dlaczego bezpieczeństwo łańcucha dostaw należy do CI.
- Nadal obserwować to, co dostarczono. Nowe podatności dotyczą oprogramowania, które już działa na produkcji. Należy je monitorować, ustalać, których wydań to dotyczy, i prowadzić każdą poprawkę aż do nowego wydania.
Szczegółową checklistę znajdą Państwo na stronie dobre praktyki bezpieczeństwa łańcucha dostaw oprogramowania.
Frameworki i regulacje
| Nazwa | Czym jest | Najlepsze do |
|---|---|---|
| SLSA | Poziomy integralności buildu i pochodzenia (provenance) | Utwardzania sposobu budowania oprogramowania |
| NIST SSDF | Praktyki bezpiecznego wytwarzania, SP 800-218 | Pełnego programu bezpiecznego wytwarzania |
| NIST SP 800-161 | Zarządzanie ryzykiem cyberbezpieczeństwa w łańcuchu dostaw | Zarządzania ryzykiem w całej organizacji |
| OpenSSF Scorecard | Automatyczne kontrole kondycji projektów open source | Weryfikacji zależności |
| Cyber Resilience Act | Unijne prawo dotyczące produktów z elementami cyfrowymi | Sprzedaży w UE. Zob. czym jest CRA |
Jakie narzędzia wchodzą w grę?
Żaden pojedynczy produkt nie obejmuje tego wszystkiego. Kategoria dzieli się na narzędzia SCA, narzędzia SBOM, bezpieczeństwo CI/CD i runnerów, firewalle pakietów, zarządzanie stanem bezpieczeństwa aplikacji i analizę binarną. Co robi każde z nich i kto je sprzedaje, pokazuje porównanie narzędzi bezpieczeństwa łańcucha dostaw oprogramowania, a ile kosztują, opisujemy osobno.
Od czego zacząć
- Wygenerować SBOM najważniejszego produktu z jego buildu CI i go przeczytać.
- Włączyć alerty o podatnościach w zależnościach i ustalić, kto za nie odpowiada.
- Przypiąć GitHub Actions do commitów i przejrzeć sekrety dostępne dla workflow.
- Ograniczyć ruch wychodzący z buildów do hostów, których faktycznie potrzebują.
- Skonfigurować monitorowanie tego, co dostarczono, a nie tylko tego, co powstaje.
Podejście CRACI
CRACI zaczyna od buildu, ponieważ build to jedyne miejsce, które widzi wszystko. Zastępuje Państwa runnery hostowane przez GitHub szybszymi i tańszymi, które rejestrują każdy pakiet pobrany przez każde zadanie, na każdym poziomie drzewa, łącznie z pakietami przywróconymi z cache CI. Polityka ruchu wychodzącego blokuje połączenia, których build nie potrzebuje, dzięki czemu chroni Państwa nawet przed atakiem, którego nikt wcześniej nie widział. Następnie CRACI nadal sprawdza to, co dostarczono, względem nowych podatności i prowadzi każdą z nich od analizy do naprawionego wydania. Zob. bezpieczeństwo łańcucha dostaw oprogramowania z CRACI.
Bezpieczeństwo łańcucha dostaw oprogramowania: najczęściej zadawane pytania
Czym jest bezpieczeństwo łańcucha dostaw oprogramowania?
To praktyka ochrony wszystkiego, co trafia do Państwa oprogramowania, zanim dotrze ono do użytkowników: zależności open source, systemów buildu, narzędzi pipeline'u i wydań.
Jaki jest przykład ataku na łańcuch dostaw oprogramowania?
W ataku na SolarWinds przejęto build, więc klienci otrzymali zatrutą aktualizację od zaufanego dostawcy. W atakach Shai-Hulud robak rozprzestrzeniał się przez pakiety npm i kradł tokeny z maszyn, które je zainstalowały.
Czym bezpieczeństwo łańcucha dostaw różni się od bezpieczeństwa aplikacji?
Bezpieczeństwo aplikacji dotyczy błędów w pisanym przez Państwa kodzie. Bezpieczeństwo łańcucha dostaw dotyczy tego, czego Państwo nie napisali, oraz sposobu budowania i wydawania oprogramowania. Program potrzebuje obu.
Czy SBOM wystarczy, by zapewnić bezpieczeństwo łańcucha dostaw?
Nie. SBOM mówi, co Państwo dostarczają, i jest podstawą. Trzeba też kontrolować, co wchodzi, chronić build i nadal monitorować to, co wydano.
Jakie są główne frameworki?
SLSA dla integralności buildu, NIST SSDF dla praktyk bezpiecznego wytwarzania i NIST SP 800-161 dla zarządzania ryzykiem w łańcuchu dostaw. W UE Cyber Resilience Act ustanawia wymagania prawne dla produktów z elementami cyfrowymi.
Kto odpowiada za bezpieczeństwo łańcucha dostaw oprogramowania?
Zwykle zespół bezpieczeństwa aplikacji lub produktu, we współpracy z zespołami platformowymi i DevOps prowadzącymi pipeline'y. Poprawki trafiają następnie do zespołów inżynierskich odpowiedzialnych za poszczególne usługi.
Co naprawdę pobierają Państwa buildy
Proszę uruchomić jeden workflow GitHub Actions na CRACI i otrzymać zarejestrowany SBOM buildu wraz z jego śladem sieciowym.
Umów demo