Dobre praktyki bezpieczeństwa łańcucha dostaw oprogramowania

Źródło

• Wymagać silnego uwierzytelniania. Stosować uwierzytelnianie wieloskładnikowe na każdym koncie hostingu kodu.
• Chronić gałąź główną. Wymagać przeglądu przed scaleniem i nie pozwalać nikomu na bezpośrednie wypychanie zmian do gałęzi wydania.
• Trzymać sekrety poza kodem. Skanować pod ich kątem przy każdym pushu i rotować wszystko, co zostało ujawnione.
• Traktować pliki workflow jak kod. Zmiana w pipeline'ie może dotrzeć do sekretów, dlatego należy wymagać przeglądu tych plików przez właścicieli.

Zależności

• Commitować lockfile i instalować z niego. Używać npm ci i jego odpowiedników, aby buildy nie pobierały przypadkiem nowych wersji. Lockfile ma swoje ograniczenia, ale to dobry punkt wyjścia.
• Dodać okres oczekiwania na nowe wersje. Złośliwe wydania są często wykrywane wkrótce po pojawieniu się, więc niewdrażanie wersji w dniu jej publikacji daje na to szansę.
• Ograniczać skrypty instalacyjne. Wyłączać je tam, gdzie to możliwe. Skrypty uruchamiane przy instalacji to sposób, w jaki rozprzestrzeniają się robaki npm.
• Weryfikować nowe zależności. Sprawdzać nazwę pod kątem typosquattingu oraz przyglądać się utrzymaniu i popularności. OpenSSF Scorecard automatyzuje część tej pracy.
• Chronić wewnętrzne nazwy pakietów. Używać zakresów (scopes) i konfiguracji rejestrów, aby pakiet publiczny nie mógł zająć miejsca wewnętrznego przez dependency confusion.
• Usuwać to, co niepotrzebne. Każda zależność to kolejna rzecz do monitorowania.

Build i CI/CD

• Przypinać GitHub Actions do pełnego hasha commita. Tagi można przesuwać, co pokazało przejęcie tj-actions.
• Ograniczać uprawnienia każdego zadania. Dawać tokenowi workflow najmniejsze potrzebne uprawnienia i używać krótkotrwałych poświadczeń zamiast długotrwałych sekretów.
• Ograniczać ruch wychodzący. Build potrzebuje pakietów ze znanych źródeł i publikuje w znanych miejscach. Po zablokowaniu całej reszty skradzione sekrety nie mają dokąd trafić. Zob. polityka ruchu wychodzącego w GitHub Actions.
• Uruchamiać każde zadanie w świeżym, odizolowanym środowisku. Nic nie powinno przechodzić z jednego zadania do następnego, a już zwłaszcza z pull requesta od zewnętrznego współtwórcy.
• Traktować cache jako dane wejściowe. Zatruty cache przetrwa między buildami, a to, co przywraca, łatwo przeoczyć. Zob. cache GitHub Actions.

Pełną listę zawiera checklista bezpieczeństwa pipeline'u CI/CD. Zob. też porównanie bezpieczeństwa runnerów.

Wydanie

• Generować SBOM dla każdego wydania, z buildu. Przechowywać go razem z artefaktem. Zob. dobre praktyki SBOM.
• Podpisywać artefakty i publikować dane o pochodzeniu. Odbiorcy mogą wtedy sprawdzić, skąd pochodzi wydanie. Poziomy określa SLSA.
• Budować wydania wyłącznie w CI. Za wydaniem z laptopa nie stoi żaden wiarygodny zapis.
• Używać jednego artefaktu od testów po produkcję. Promować to, co przetestowano, zamiast budować ponownie, aby zapis pozostał prawdziwy.

Po wydaniu

• Monitorować to, co dostarczono. Nadal sprawdzać SBOM-y wspieranych wydań względem nowych podatności.
• Priorytetyzować nie tylko na podstawie CVSS. Korzystać z CISA KEV, EPSS i kontekstu. Zob. jak priorytetyzować podatności.
• Wiedzieć, jak długo trwała ekspozycja. Historia buildów pokazuje, które wydania zawierały dany pakiet i od kiedy.
• Mieć plan, zanim będzie potrzebny. Ustalić, kto analizuje, kto naprawia i kto rozmawia z klientami. Zob. cykl życia zarządzania podatnościami.
• Ćwiczyć na realnym scenariuszu. Zadać pytanie, ile czasu zajęłoby znalezienie każdego wydania z danym pakietem. Jeśli odpowiedź brzmi „kilka dni”, od tego należy zacząć.

Co zrobić najpierw

Kiedy	Co zrobić
W tym tygodniu	Uwierzytelnianie wieloskładnikowe, lockfile w CI, przypięte GitHub Actions, tokeny workflow z najmniejszymi uprawnieniami
W tym miesiącu	SBOM z każdego buildu wydania, alerty o zależnościach z przypisanym właścicielem, skanowanie sekretów
W tym kwartale	Reguły ruchu wychodzącego dla buildów, monitorowanie dostarczonych wydań, przetestowany plan reagowania
Następnie	Podpisane dane o pochodzeniu, formalny przegląd pokrycia SLSA lub NIST SSDF, SBOM-y dostawców

Które z tych praktyk obsługuje CRACI

CRACI obejmuje build i wszystko, co po nim. Jako runner GitHub Actions uruchamia każde zadanie we własnej, odizolowanej maszynie wirtualnej, rejestruje w SBOM każdy pakiet pobrany przez zadanie, oznacza pakiety przywrócone z cache CI i egzekwuje politykę ruchu wychodzącego, która blokuje połączenia zbędne dla buildu. Następnie nadal sprawdza to, co dostarczono, pokazuje, które buildy zawierały podatny pakiet, i może blokować buildy za pomocą bramek polityk.

Reszta należy do Państwa innych narzędzi: CRACI nie skanuje kodu źródłowego ani sekretów, nie wykrywa nowych złośliwych pakietów na podstawie zachowania i nie podpisuje SBOM-ów ani danych o pochodzeniu. Co wypełnia każdą z tych luk, pokazuje porównanie narzędzi bezpieczeństwa łańcucha dostaw oprogramowania.

Dobre praktyki bezpieczeństwa łańcucha dostaw: najczęściej zadawane pytania

Jak zabezpieczyć łańcuch dostaw oprogramowania?

Wiedzieć, co jest dostarczane, dzięki SBOM z każdego buildu wydania, kontrolować, co wchodzi, za pomocą lockfile i weryfikacji, chronić build przez ograniczanie sekretów i ruchu wychodzącego oraz nadal monitorować to, co wydano.

Co powinien zrobić najpierw mały zespół?

Włączyć uwierzytelnianie wieloskładnikowe, instalować z lockfile w CI, przypiąć GitHub Actions do hashy commitów i dać tokenom workflow najmniejsze potrzebne uprawnienia. Te kroki zajmują kilka dni i zamykają typowe ścieżki ataku.

Jak zapobiegać złośliwym pakietom?

Żaden pojedynczy krok tego nie zapewni. Warto opóźniać wdrażanie nowych wersji, ograniczać skrypty instalacyjne i weryfikować nowe zależności. Ograniczenie ruchu wychodzącego z buildów zmniejsza szkody, jeśli złośliwy pakiet się przedostanie.

Dlaczego przypinać GitHub Actions do hasha commita?

Ponieważ tag wersji można przesunąć na inny kod. Pełny hash commita zawsze odnosi się do tego samego kodu, więc przejęty tag nie dotrze do Państwa pipeline'u.

Jak często należy przeglądać łańcuch dostaw?

Monitorowanie powinno być ciągłe. Politykę zależności, uprawnienia workflow i plan reagowania warto przeglądać co najmniej raz w roku oraz po każdym incydencie w Państwa stosie technologicznym.