Checklista bezpieczeństwa pipeline'u CI/CD

Workflow

• Przypinać akcje zewnętrzne do pełnego SHA commita. Według GitHub to obecnie jedyny sposób używania akcji jako niezmiennego wydania. Tag można zmienić tak, aby wskazywał inny kod. W marcu 2025 CISA poinformowała, że każda wersja tj-actions/changed-files była przejęta przez trzy dni.
• Dać GITHUB_TOKEN najmniejsze uprawnienia. Domyślnie tylko odczyt zawartości, a więcej przyznawać dla poszczególnych zadań.
• Nigdy nie pobierać niezaufanego kodu w pull_request_target. Takie workflow działają z sekretami i podwyższonymi uprawnieniami.
• Trzymać niezaufane dane wejściowe z dala od skryptów. Tytuły, nazwy gałęzi i inne wartości kontrolowane przez użytkowników należy przekazywać przez zmienną środowiskową, a nie rozwijać je w poleceniu powłoki.
• Przeglądać zmiany w plikach workflow. Należy wymagać przeglądu właściciela kodu dla .github/workflows.

Sekrety

• Preferować poświadczenia krótkotrwałe. Dzięki OpenID Connect zadania otrzymują od dostawcy chmury krótkotrwałe tokeny o ograniczonym zakresie zamiast długotrwałych kluczy przechowywanych jako sekrety.
• Ograniczać sekrety do środowisk. Poświadczenia produkcyjne należy umieścić w środowisku z wymaganymi recenzentami.
• Rotować po incydencie. Po przejęciu tj-actions CISA zaleciła traktowanie ujawnionych sekretów jako przejętych i ich natychmiastową rotację.

Runnery

• Używać runnerów efemerycznych. Nowa maszyna dla każdego zadania nie zostawia niczego dla następnego.
• Nie używać runnerów self-hosted w repozytoriach publicznych. GitHub podaje, że prawie nigdy nie należy ich tam używać, ponieważ każdy może otworzyć pull request do repozytorium.
• Izolować zadania. Jedno zadanie nie powinno móc odczytać przestrzeni roboczej ani poświadczeń innego.

Sieć

• Kontrolować ruch wychodzący. Należy zezwolić na źródła pakietów i usługi potrzebne zadaniu, a resztę blokować, aby przejęta zależność nie mogła wysłać sekretów na zewnątrz. Jak polityka ruchu wychodzącego zatrzymuje eksfiltrację
• Rejestrować połączenia. Należy przechowywać ślad tego, z czym łączyło się każde zadanie, aby móc to później zbadać.

Zależności

• Commitować lockfile. Buildy powinny za każdym razem rozwiązywać te same wersje.
• Przeglądać nowe zależności. Należy sprawdzić, co dodaje pull request, zanim zostanie scalony.
• Blokować buildy na podstawie znalezisk. Build pobierający pakiet ze znaną krytyczną podatnością należy zablokować, zanim artefakt zostanie dostarczony.

Dowody z buildu

• Rejestrować SBOM tego, co pobrał build. Późniejszy skan plików opisuje to, co zadeklarowano, a nie to, czego użył build.
• Podpisywać pochodzenie. Każdy artefakt należy powiązać z buildem, który go wytworzył, aby móc później sprawdzić, czy to, co działa, jest tym, co zbudowano.
• Monitorować to, co dostarczono. Wydane buildy należy sprawdzać ponownie, gdy publikowane są nowe podatności.

Które narzędzia obejmują które punkty

Skanery obejmują punkty dotyczące zależności, narzędzia do utwardzania pipeline'u punkty dotyczące workflow, a agenci na runnerze lub bezpieczny runner punkty dotyczące sieci i dowodów. CRACI jest runnerem: egzekwuje politykę ruchu wychodzącego, która w razie awarii blokuje ruch (fail closed), rejestruje SBOM tego, co pobrało każde zadanie, pozwala bramkom polityk blokować build na podstawie znalezisk i zwraca przez API SBOM-y, ślady sieciowe i dane o pochodzeniu. Nie skanuje kodu ani workflow. To, które narzędzie co obejmuje, pokazuje porównanie narzędzi bezpieczeństwa CI/CD.

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

Czym jest bezpieczeństwo pipeline'u CI/CD?

To ochrona systemów, które budują i dostarczają Państwa oprogramowanie: definicji workflow, używanych przez nie sekretów, wykonujących je runnerów, pobieranych zależności i wytwarzanych artefaktów. Przejęty pipeline może dostarczyć złośliwy kod pod Państwa nazwą bez dotykania kodu źródłowego.

Dlaczego należy przypinać GitHub Actions do SHA commita?

Tagi można zmienić tak, aby wskazywały inny kod. GitHub podaje, że przypięcie akcji do pełnego SHA commita to obecnie jedyny sposób używania akcji jako niezmiennego wydania. W marcu 2025 CISA poinformowała, że każda wersja tj-actions/changed-files była przejęta przez trzy dni.

Jakie uprawnienia powinien mieć GITHUB_TOKEN?

Minimalne, jakich potrzebuje każde zadanie. Domyślnie należy ustawić dostęp tylko do odczytu zawartości repozytorium, a więcej przyznawać dla poszczególnych zadań, tylko tam, gdzie zadanie tego potrzebuje.

Czy kontrola ruchu wychodzącego jest potrzebna w CI?

Jeśli Państwa zadania mają dostęp do sekretów i uruchamiają kod zewnętrzny, tak. Większość zadań musi łączyć się tylko ze znanym zestawem rejestrów pakietów i usług. Polityka ruchu wychodzącego blokuje wszystko inne, więc przejęta zależność nie może wysłać sekretów na serwer napastnika.