Bezpieczeństwo CI/CD

Dlaczego pipeline'y są celem

• Trzymają klucze. Poświadczenia chmurowe, tokeny rejestrów i klucze podpisujące przechodzą przez CI.
• Uruchamiają cudzy kod. Każda zależność, skrypt instalacyjny i akcja zewnętrzna wykonują się na runnerze.
• Docierają do produkcji. Wszystko, co wychodzi z pipeline'u, jest uznawane za zaufane, podpisywane i dostarczane. Napastnik w buildzie dociera od razu do wszystkich klientów.
• Mało kto ich pilnuje. Pliki workflow zmieniają się rzadko i są przeglądane mniej dokładnie niż kod aplikacji.

Zarówno przejęcie tj-actions, jak i robak npm Shai-Hulud celowały w sekrety w CI. Jak przebiegają takie ataki, opisuje strona czym jest atak na łańcuch dostaw.

Główne ryzyka bezpieczeństwa CI/CD

Standardowym punktem odniesienia jest OWASP Top 10 CI/CD Security Risks. W podziale według tego, co idzie nie tak:

Obszar	Ryzyka OWASP	Jak to wygląda
Kto może co zmieniać	Niewystarczająca kontrola przepływu, nieodpowiednie zarządzanie tożsamością i dostępem	Kod trafia na produkcję bez przeglądu albo stare konta zachowują dostęp
Co działa w pipeline'ie	Nadużycie łańcucha zależności, poisoned pipeline execution	Złośliwy pakiet lub zmieniony workflow działa z uprawnieniami zadania
Do czego sięga zadanie	Niewystarczające kontrole dostępu oparte na pipeline'ie, niewystarczająca higiena poświadczeń	Jedno zadanie może odczytać każdy sekret, a tokeny żyją latami
Jak to jest skonfigurowane	Niebezpieczna konfiguracja systemu, niekontrolowane korzystanie z usług zewnętrznych	Niezałatane runnery i integracje z większym dostępem, niż potrzebują
Co można udowodnić	Niewłaściwa walidacja integralności artefaktów, niewystarczające logowanie i widoczność	Nikt nie potrafi powiedzieć, co trafiło do wydania ani z czym łączyło się zadanie

Mapowanie każdego ryzyka na kontrole runnera zawiera porównanie bezpieczeństwa runnerów.

Dobre praktyki bezpieczeństwa CI/CD

1. Traktować definicje pipeline'ów jak kod produkcyjny. Wymagać przeglądu plików workflow i trzymać niezaufane pull requesty z dala od sekretów.
2. Ograniczać uprawnienia każdego zadania. Dawać tokenom najmniejsze potrzebne uprawnienia i przedkładać krótkotrwałe poświadczenia nad przechowywane sekrety.
3. Przypinać akcje zewnętrzne do hasha commita. Tagi można przesunąć na inny kod.
4. Izolować zadania. Uruchamiać każde zadanie w świeżym środowisku, aby nic nie przechodziło do kolejnego.
5. Kontrolować ruch wychodzący. Build potrzebuje znanych źródeł i znanych miejsc docelowych. Zablokowanie wszystkiego innego powstrzymuje wyciek skradzionych sekretów. Zob. polityka ruchu wychodzącego w GitHub Actions.
6. Rejestrować, co się wydarzyło. Przechowywać SBOM każdego buildu i log jego aktywności sieciowej, aby móc później odpowiadać na pytania.

Wersję krok po kroku zawiera checklista bezpieczeństwa pipeline'u CI/CD.

Rodzaje narzędzi bezpieczeństwa CI/CD

Rodzaj	Co robi	Przykłady
Bezpieczeństwo runnerów	Izoluje zadania i kontroluje, do czego mają dostęp w trakcie działania	CRACI, StepSecurity
Zarządzanie stanem bezpieczeństwa	Znajduje ryzykowne ustawienia pipeline'ów i repozytoriów	Legit Security, Cycode, Apiiro, OX Security
Skanowanie kodu i zależności	Sprawdza kod, zależności i sekrety przy każdej zmianie	GitHub Advanced Security, Snyk, Semgrep
SBOM i dowody	Rejestruje, co trafiło do każdego wydania	CRACI, Syft, Anchore

Działają na różnych etapach, dlatego większość zespołów je łączy. Skaner sprawdza pliki przed buildem, narzędzia do zarządzania stanem bezpieczeństwa sprawdzają ustawienia, a bezpieczeństwo runnerów działa w trakcie zadania, czyli wtedy, gdy działa złośliwy pakiet. Zob. porównanie narzędzi bezpieczeństwa łańcucha dostaw oprogramowania i porównanie narzędzi DevSecOps.

Gdzie jest miejsce CRACI

CRACI zabezpiecza build w trakcie jego działania. Zastępuje runnery hostowane przez GitHub szybszymi i tańszymi: każde zadanie działa we własnej izolowanej maszynie wirtualnej, polityka ruchu wychodzącego blokuje połączenia zbędne dla buildu, a każdy pakiet pobrany przez zadanie trafia do SBOM. Ponieważ polityka dopuszcza tylko to, czego build potrzebuje, chroni Państwa nawet przed atakiem, którego nikt wcześniej nie widział.

CRACI nie sprawdza konfiguracji workflow, nie skanuje kodu źródłowego ani sekretów i nie podpisuje pochodzenia, więc do tego należy zachować lub dodać inne narzędzia. Obsługiwanym systemem CI jest dziś GitHub Actions, a inne systemy CI są w planach rozwoju.

Bezpieczeństwo CI/CD: najczęściej zadawane pytania

Czym jest bezpieczeństwo CI/CD?

To praktyka ochrony pipeline'ów, które budują, testują i dostarczają oprogramowanie, łącznie z ich poświadczeniami, uruchamianym przez nie kodem i tworzonymi przez nie artefaktami.

Jakie są największe ryzyka bezpieczeństwa CI/CD?

Złośliwe zależności i akcje zewnętrzne, zatrute pipeline'y, tokeny z nadmiernymi uprawnieniami i długotrwałe sekrety oraz brak wglądu w to, co zrobił build. Standardową listą jest OWASP Top 10 CI/CD Security Risks.

Czym jest poisoned pipeline execution?

Napastnik zmienia to, co uruchamia pipeline, na przykład edytując przez pull request plik workflow lub wywoływany przez niego skrypt, tak aby jego kod działał z uprawnieniami pipeline'u.

Jak zabezpieczyć pipeline CI/CD?

Przeglądać zmiany w pipeline'ach, dawać każdemu zadaniu najmniejszy potrzebny dostęp, przypinać akcje zewnętrzne do hasha commita, izolować zadania, ograniczać ruch wychodzący i zachowywać zapis tego, co zrobił każdy build.

Jaka jest różnica między bezpieczeństwem CI/CD a DevSecOps?

DevSecOps to szersza praktyka wbudowywania bezpieczeństwa w sposób tworzenia oprogramowania. Bezpieczeństwo CI/CD skupia się na samym pipeline'ie, na którym opierają się też narzędzia DevSecOps.

Czy GitHub Actions wymaga dodatkowych zabezpieczeń?

GitHub zapewnia mechanizmy kontroli, takie jak uprawnienia tokenów i skanowanie sekretów, ale trzeba je skonfigurować, a runnery hostowane domyślnie nie ograniczają ruchu wychodzącego. Większość zespołów dodaje przypinanie, reguły przeglądu i kontrole runnerów.