Ranking narzędzi do CI/CD z funkcjami security: które pipeline’y najłatwiej utwardzić

Kontekst: po co w ogóle ranking „bezpiecznych” narzędzi CI/CD

Pipeline CI/CD jest dziś jednym z najcenniejszych celów dla atakującego. To najkrótsza droga od repozytorium do produkcji, zazwyczaj z uprawnieniami pozwalającymi na zmianę artefaktów, konfiguracji, a czasem nawet infrastruktury. Każdy błąd w konfiguracji pipeline’u skutkuje tym, że ktoś może „wstrzyknąć” do produkcji obcy kod bez dotykania samej aplikacji.

Wiele organizacji przez lata koncentrowało się na zabezpieczeniu aplikacji i infrastruktury, traktując narzędzia CI/CD jako neutralne tło. Efekt jest taki, że na poziomie buildów często działają konta z uprawnieniami „boga”, sekrety są przechowywane w plaintext, a logi pipeline’ów zawierają dokładnie to, czego potrzebuje atakujący, aby zbudować sobie trwały dostęp do środowiska.

Rosnąca powierzchnia ataku wynika z kilku zjawisk: rozproszone zespoły, coraz bardziej dynamiczny provisioning infrastruktury (IaC), setki jobów dziennie na runnerach oraz szerokie użycie zewnętrznych marketplace’ów z akcjami, pluginami i template’ami pipeline’ów. Każde takie rozszerzenie może okazać się nowym wektorem ataku, jeśli narzędzie CI/CD nie oferuje sensownego modelu uprawnień, izolacji i kontroli nad tym, co dokładnie jest wykonywane.

Typowe incydenty związane z CI/CD kręcą się wokół kilku powtarzalnych motywów: kradzieży tokenów dostępu przechowywanych jako zmienne, złośliwych zależności (dependency confusion, supply chain), przejętych pluginów oraz pipeline’ów pozwalających na zdalne wykonywanie kodu zbyt szerokimi uprawnieniami. W wielu znanych przypadkach atak na CI/CD był prostszy niż atak na samą aplikację, bo narzędzie było skonfigurowane „na skróty” dla wygody developerów.

Sam fakt, że narzędzie CI/CD ma wbudowane skanery SAST czy SCA, nie rozwiązuje problemu. Jeżeli pipeline może być dowolnie modyfikowany przez osoby bez odpowiedniej kontroli, a runner ma dostęp do wszystkich sekretów i wszystkich środowisk, to skanery są jedynie cienką warstwą dekoracji. Kluczowe jest to, jak wygląda architektura, model uprawnień, izolacja jobów i zarządzanie sekretami. Dopiero na tym fundamencie opłaca się dokładać mechanizmy security scanningu.

Celem rankingu narzędzi do CI/CD z funkcjami security nie jest wskazanie „jednego najlepszego rozwiązania” dla wszystkich, ale określenie, które platformy zapewniają relatywnie bezpieczny stan przy rozsądnym wysiłku konfiguracyjnym. Innymi słowy: gdzie domyślne zachowanie i ergonomia hardeningu wspiera zespół, zamiast zmuszać go do budowania dziesiątek własnych obejść, skryptów i integracji.

Perspektywa audytora bezpieczeństwa jest w tym kontekście inna niż perspektywa developera. Testuje się przede wszystkim: konfigurację domyślną, łatwość wdrożenia minimalnych standardów (RBAC, izolacja runnerów, secrets management), przejrzystość logów oraz dostępność gotowych mechanizmów security by default. Jeśli do osiągnięcia sensownego poziomu bezpieczeństwa konieczny jest wielomiesięczny projekt, narzędzie przegrywa z takim, które pozwala ustawić podstawy w ciągu kilkunastu godzin pracy inżyniera DevOps.

Jeżeli obecny wybór narzędzi CI/CD w organizacji wynikał wyłącznie z wygody developerów, ceny licencji lub mody rynkowej, istnieje duża szansa, że ukryte ryzyko w pipeline’ach jest poważnie niedoszacowane. Ranking skoncentrowany na bezpieczeństwie pomaga to ryzyko nazwać i usystematyzować.

Metodologia rankingu: jak oceniać bezpieczeństwo narzędzi CI/CD

Ocena bezpieczeństwa narzędzi CI/CD wymaga uporządkowanej metodyki, inaczej łatwo zgubić się w marketingowych hasłach o DevSecOps i „end-to-end security”. Pierwszy punkt kontrolny to wyraźne rozdzielenie funkcji security oferowanych natywnie przez platformę od tego, co trzeba zbudować samodzielnie lub dokupić jako osobny produkt.

Funkcje security w „pudełku” kontra własne dodatki

W analizie narzędzi CI/CD przydatne jest zdefiniowanie dwóch koszyków funkcji:

• funkcje wbudowane – dostępne bez instalacji dodatkowych pluginów, rozszerzeń czy zewnętrznych usług (np. natywne RBAC, zarządzanie sekretami, podstawowe skanowanie artefaktów, protected branches, audit logi),
• funkcje wymagające rozszerzeń – plug-iny, marketplace actions, integracje z zewnętrznymi skanerami, własne skrypty lub „glue code”, które trzeba zbudować i utrzymywać.

Jako audytor jakości bezpieczeństwa pipeline’ów, preferencja jest jasna: im więcej krytycznych elementów bezpieczeństwa jest dostępnych out-of-the-box i dobrze udokumentowanych, tym wyższa ocena. Jeżeli absolutne minimum bezpieczeństwa wymaga instalacji kilkunastu pluginów zewnętrznych, każdy taki plugin staje się osobnym punktem awarii i sygnałem ostrzegawczym.

Równolegle trzeba analizować, jak platforma radzi sobie z integracją istniejącego ekosystemu security. Narzędzia, które mają słabe natywne skanery, ale potrafią wygodnie integrować komercyjne silniki SAST/SCA/DAST i zewnętrzne sejfy (Vault, KMS) mogą koniec końców być bezpieczniejsze niż te, które mają własne, ale zamknięte mechanizmy trudne do rozszerzenia.

SaaS kontra self-hosted, monolityczne platformy kontra „pipeline as code”

Drugi wymiar oceny to model wdrożenia. Narzędzia CI/CD można podzielić na dwie główne grupy: platformy SaaS, gdzie dostawca odpowiada za infrastrukturę i znaczną część parametrów bezpieczeństwa, oraz rozwiązania self-hosted, gdzie cała odpowiedzialność za konfigurację, aktualizacje i hardening spoczywa na zespole wewnętrznym.

Modele SaaS (np. GitHub Actions, GitLab.com, CircleCI, Bitbucket Pipelines) oferują zwykle dość mocny poziom security „fabrycznie”: aktualne oprogramowanie, izolację runnerów w chmurze dostawcy, polityki użycia sekretów i domyślnie włączone mechanizmy audytu. Z kolei narzędzia self-hosted, takie jak Jenkins, GitLab self-managed czy własne instancje GitHub Enterprise, dają ogromną elastyczność i kontrolę, ale wymagają dojrzałego zespołu odpowiedzialnego za ich twardą konfigurację.

Trzeci wymiar to podejście architektoniczne: all-in-one (repozytorium + CI/CD + security w ramach jednej platformy) kontra model „pipeline as code” w oparciu o lekkie silniki (np. Argo Workflows, Drone, Tekton) i osobne narzędzia do security i SCM. Monolityczne platformy są najczęściej łatwiejsze do zrozumienia i audytu, ale mogą cierpieć na złożoność konfiguracji. Modułowe rozwiązania wymagają z kolei znacznie lepszego opanowania architektury, aby nie powstały „szare strefy”, w których nikt nie czuje się właścicielem bezpieczeństwa.

Źródła danych i sposób ważenia kryteriów

Ocena bezpieczeństwa narzędzi CI/CD wymaga połączenia kilku źródeł:

• dokumentacji producenta, w szczególności sekcji dotyczących security, compliance, zarządzania sekretami i modeli uprawnień,
• faktycznych domyślnych konfiguracji nowej instancji / nowego projektu (co jest włączone, a co trzeba dopiero aktywować),
• praktyki wdrożeń w realnych organizacjach, z uwzględnieniem tego, jakie mechanizmy firmy naprawdę włączają, a które zostają na papierze,
• znanych incydentów i luk bezpieczeństwa związanych z danym narzędziem lub jego ekosystemem pluginów.

Ważenie kryteriów jest kluczowe: bezpieczeństwo stoi wyżej niż ergonomia, ale ergonomia ma bezpośredni wpływ na to, czy polityki bezpieczeństwa są utrzymywane. Jeżeli ustawienie minimalnych standardów wymaga walki z narzędziem, zespoły będą skłonne je obchodzić. Narzędzie, które oferuje sensowny kompromis: wysoki poziom bezpieczeństwa przy znośnej złożoności i kosztach, jest wyżej w rankingu niż platforma teoretycznie „najbezpieczniejsza”, ale praktycznie nieużywalna.

Granice rankingu i pojęcie „minimum przyzwoitości”

Trzeba jasno zaznaczyć ograniczenie: każde narzędzie CI/CD można zarówno utwardzić, jak i kompletnie zepsuć. Nawet najbardziej dopracowana platforma SaaS da się skonfigurować w sposób skrajnie niebezpieczny, jeśli zespół zignoruje podstawowe zasady. Ranking nie zwalnia z pracy konfiguracyjnej, ale pozwala ocenić, jak duży wysiłek trzeba włożyć, aby dojść do poziomu „minimum przyzwoitości”.

Minimum przyzwoitości to punkt, w którym narzędzie zapewnia:

• oddzielenie środowisk (dev / test / prod) i możliwość stosowania zasady najmniejszych uprawnień w pipeline’ach,
• bezpieczne zarządzanie sekretami (brak plaintext w repo, maskowanie w logach, integracja z sejfem),
• izolację jobów (kontenery, VM, ephemeral runners),
• sensowny poziom audytu (kto co uruchomił, z jakimi uprawnieniami, jakie artefakty powstały),
• przynajmniej podstawowe wsparcie dla skanowania kodu i artefaktów.

Jeżeli narzędzie jest „bezpieczne” głównie w slajdach marketingowych, a osiągnięcie tego minimum wymaga budowy połowy funkcjonalności od zera, w praktyce będzie generowało stałe sygnały ostrzegawcze. W takim środowisku audytor jakości musi wzmocnić kontrole kompensujące (np. dodatkowe skanowanie infrastruktury, manualne przeglądy pipeline’ów), co podnosi koszty i zmniejsza spójność procesu.

Jeśli w procesie wyboru narzędzia CI/CD kryteria bezpieczeństwa są rozpisane równie szczegółowo jak koszt i wygoda użycia, ranking stanie się narzędziem wspierającym decyzję, a nie tylko teoretycznym porównaniem.

Kluczowe kryteria bezpieczeństwa pipeline’ów – lista kontrolna audytora

Bez względu na wybrane narzędzie, ocena bezpieczeństwa pipeline’u powinna opierać się na tym samym, powtarzalnym zestawie kryteriów. Taka checklista pozwala porównać GitLab CI/CD, GitHub Actions, Azure DevOps, Jenkinsa czy CircleCI w spójny sposób i szybko wychwycić obszary o podwyższonym ryzyku.

Zarządzanie sekretami i tokenami w CI/CD

Pierwszy i najważniejszy obszar to sposób przechowywania i używania sekretów: kluczy API, tokenów dostępu do repozytoriów, haseł do baz danych, kluczy SSH czy danych do rejestrów kontenerowych. W narzędziu CI/CD interesują zwłaszcza następujące punkty kontrolne:

• natywne sejfy i store’y sekretów – czy narzędzie ma własny mechanizm przechowywania sekretów zaszyfrowany w bazie, z rozróżnieniem zakresu (globalne, grupowe, projektowe, środowiskowe),
• maskowanie w logach – czy sekrety są domyślnie maskowane i czy mechanizm jest odporny na proste obejścia (np. łączenie fragmentów sekretu w runtime),
• integracja z zewnętrznymi vaultami – HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault; im lepsza integracja, tym mniej sekretów musi trafić bezpośrednio do narzędzia CI,
• rotacja i zarządzanie cyklem życia – czy da się wymusić okresową rotację tokenów używanych przez pipeline’y oraz czy istnieje centralny widok, gdzie widać, które pipeline’y używają jakich poświadczeń,
• granularność uprawnień sekretów – czy sekret może być ograniczony do konkretnego jobu, środowiska lub gałęzi (np. tylko prod pipeline widzi prod DB password).

Typowy sygnał ostrzegawczy to koncentracja wszystkich sekretów w jednym globalnym store bez rozróżnienia środowisk oraz możliwość ich użycia przez dowolny job. Innym przykładem jest brak maskowania w logach – w takim przypadku każdy log z pipeline’u staje się wrażliwym artefaktem wymagającym tej samej ochrony co sejf z hasłami.

Jeżeli narzędzie CI/CD nie wspiera integracji z zewnętrznymi sejfami i nie oferuje nawet podstawowego maskowania, zespół jest zmuszony do budowania własnych mechanizmów, co podnosi złożoność i ryzyko błędów.

Model uprawnień, RBAC i separacja środowisk

Drugim krytycznym obszarem jest model uprawnień. Chodzi zarówno o to, kto może definiować i modyfikować pipeline’y, jak i o to, z jakimi uprawnieniami pipeline’y są wykonywane. Minimum to:

• RBAC na poziomie użytkowników i grup – role typu viewer, developer, maintainer, admin; możliwość przypisywania ról per projekt / repozytorium,
• kontrola nad modyfikacją pipeline’ów – mechanizmy typu protected branches, wymagane code review dla changesetów w plikach pipeline’ów (np. .gitlab-ci.yml, .github/workflows),
• separacja środowisk – osobne pipeline’y dla dev/test/prod lub przynajmniej osobne stage’e z zabezpieczeniami (manual approval, ograniczone zmienne),
• delegowanie minimalnych uprawnień – możliwość przypisania runnerom i agentom tylko tych uprawnień, które są niezbędne, zamiast domyślnych full admin w chmurze lub klastrze.

Najgroźniejszy wzorzec, który często wychodzi w audytach, to połączenie: każdy developer może dowolnie modyfikować pipeline, runner ma pełne uprawnienia do produkcji, a deploy do produkcji jest w pełni zautomatyzowany bez dodatkowych kontroli. W takim układzie pojedynczy błąd lub złośliwa zmiana w pipeline’ie wystarczy, aby bezgłośnie ominąć całą sekwencję standardowych kontroli bezpieczeństwa.

Izolacja wykonania, runnerzy i infrastruktura buildowa

Kolejny obszar to sposób uruchamiania jobów: gdzie faktycznie wykonuje się kod pipeline’u, jaki ma dostęp do sieci i zasobów oraz jak szybko ten kontekst wykonania znika po zakończeniu zadania. To tutaj zapada decyzja, czy potencjalne przejęcie pipelinu kończy się na pojedynczym kontenerze, czy na całym klastrze produkcyjnym.

Podczas przeglądu konfiguracji runnerów i infrastruktury buildowej warto przejść przez kilka kluczowych punktów:

• ephemeral vs. long‑lived – czy joby są uruchamiane w krótkotrwałych VM/kontenerach (tworzonych na czas jednego pipeline’u lub joba), czy na współdzielonych, długo działających agentach,
• poziom izolacji – kontenery nieuprzywilejowane vs. uprzywilejowane (privileged), osobne nody/VM dla buildów vs. współdzielenie hostów z innymi systemami,
• zasięg sieciowy runnerów – czy runner ma bezpośredni dostęp do produkcyjnych baz danych, klastrów Kubernetes lub VPC, czy działa za pośrednictwem dedykowanych endpointów/deployment gateway,
• kontrola nad obrazami bazowymi – czy obrazy używane przez pipeline są regularnie skanowane, aktualizowane i utrzymywane centralnie, czy każdy zespół buduje „na własną rękę”,
• sprzątanie po jobach – mechanizmy czyszczenia workspace’ów, cache’y i lokalnych artefaktów, aby kolejne joby nie dziedziczyły danych poprzedników.

Sygnał ostrzegawczy to połączenie: długo żyjące, współdzielone agenty z uprawnieniami administratora do klastra lub chmury oraz brak automatycznego czyszczenia środowiska po jobie. W takim układzie każdy pipeline staje się trwałym wektorem lateral movement.

Jeżeli w audycie wychodzi, że runnerzy „widzą wszystko” (całą sieć wewnętrzną, wszystkie klastry, wszystkie bazy), to kolejnym krokiem nie jest kosmetyka pipeline’u, ale przeprojektowanie modelu izolacji i segmentacji sieci.

Źródła kodu, zależności i supply chain

Pipeline CI/CD jest tak bezpieczny, jak źródła kodu i artefaktów, z których korzysta. Coraz częściej krytyczne incydenty wynikają nie z błędnej konfiguracji runnerów, lecz z kompromitacji zależności lub rejestrów.

Przy ocenie tego obszaru punktem kontrolnym są przede wszystkim:

• integracja z systemem kontroli wersji – czy narzędzie CI/CD potrafi egzekwować zasady typu „no direct push to main”, wymagane code review, podpisy commitów,
• polityka użycia zależności – czy pipeline weryfikuje integralność pobieranych pakietów (lockfile, checksumy, SBOM), czy po prostu pobiera „najświeższą” wersję z publicznego registry,
• kontrola nad rejestrami – czy używane są prywatne registry z kontrolą dostępu i skanowaniem obrazów, czy wszystko pobierane jest bezpośrednio z publicznych hubów,
• podpisywanie artefaktów – czy pipeline potrafi podpisywać obrazy kontenerowe, paczki i binaria (np. Sigstore, Cosign) i czy te podpisy są weryfikowane przed wdrożeniem,
• ścieżka promocji artefaktów – czy ten sam, zweryfikowany artefakt przechodzi z dev do prod, czy dla każdego środowiska „buduje się od nowa” z zewnętrznych źródeł.

Praktyczny przykład: organizacja korzysta z publicznych obrazów „latest” jako baz dla produkcyjnych kontenerów. Pipeline nie wykonuje żadnego skanowania, brak też podpisów obrazów. W razie kompromitacji obrazu upstream ryzyko przechodzi wprost na produkcję, często bez śladu w logach.

Jeśli pipeline nie zapewnia przejrzystej ścieżki: kod → build → skan → podpis → deploy, audytor powinien traktować to jako luka w łańcuchu dostaw, a nie „drobny brak wygody”.

Audyt, logowanie i ślad dowodowy

Bez porządnego śladu audytowego ocena incydentów, a nawet zwykłego regresu, staje się loterią. Narzędzie CI/CD powinno umożliwiać odtworzenie sekwencji: kto zmienił pipeline, jaka wersja kodu została zbudowana, jakie zależności zostały użyte i kto zaakceptował wdrożenie.

Lista pytań kontrolnych dla audytu i logów jest dość powtarzalna:

• logi audytowe na poziomie platformy – rejestrowanie zmian konfiguracji, ról, runnerów, sekretów oraz ich powiązanie z użytkownikiem i czasem,
• logi uruchomień pipeline’ów – pełny zapis uruchomień, włącznie z wersjami pipeline’y (hash pliku konfiguracyjnego) i commitami, które je wyzwoliły,
• integracja z SIEM – możliwość eksportu logów do centralnego systemu (wspólne korelowanie z innymi źródłami: chmura, endpointy, firewalle),
• retencja i integralność logów – gwarancja, że logi nie są nadpisywane zbyt szybko oraz że użytkownicy o podwyższonych uprawnieniach nie mogą ich modyfikować lub kasować,
• identyfikacja użytkowników – SSO, MFA, brak współdzielonych kont „ci-bot” bez przypisania do osoby lub roli usługowej.

Sygnał ostrzegawczy to platforma, w której logi jobów są jedynym śladem i można je kasować z poziomu zwykłego użytkownika. Z punktu widzenia dochodzenia powłamaniowego oznacza to de facto brak ścieżki dowodowej.

Jeżeli narzędzie CI/CD oferuje dobre logi, ale organizacja nie wysyła ich do SIEM ani nie definiuje alertów (np. na nieudane próby logowania, zmianę runnera, modyfikację sekretów), potencjał bezpieczeństwa pozostaje w dużej mierze niewykorzystany.

Wbudowane skanowanie bezpieczeństwa i integracja z narzędziami zewnętrznymi

Narzędzia CI/CD coraz częściej dostarczają wbudowane skanery (SAST, DAST, SCA, skanowanie kontenerów) lub przynajmniej integracje zewnętrzne. Kluczowe pytanie nie brzmi „czy skaner istnieje”, tylko „jak trudno wymusić jego konsekwentne używanie”.

Przy przeglądzie tego obszaru warto przeanalizować:

• łatwość włączenia skanów – czy dołączenie SAST/DAST/SCA do pipeline’u wymaga kilku linii konfiguracji, czy budowy skomplikowanego szablonu,
• predefiniowane polityki – możliwość definiowania progów akceptacji (np. blokada merge/deploy przy wykryciu podatności o wysokiej krytyczności),
• centralizacja wyników – czy wyniki skanów trafiają w jedno miejsce (dashboard projektu, narzędzie centralne) z możliwością raportowania na poziomie organizacji,
• obsługa wyjątków – mechanizm akceptacji ryzyka: tymczasowe „waiver’y” z uzasadnieniem, terminem wygaśnięcia i śladem, kto je dodał,
• skalowalność – czy skanowanie można parametryzować tak, aby ciężkie skany chodziły np. raz dziennie, a lżejsze przy każdym merge’u.

W praktyce częsty obrazek to skanery, które istnieją na slajdach i w cenniku, ale w realnych pipeline’ach są wyłączone „bo spowalniają buildy”. Wtedy nawet najlepsze narzędzie nie wnosi dodatkowego bezpieczeństwa.

Jeśli narzędzie utrudnia stworzenie centralnych polityk (np. brak możliwości wymuszenia skanów na poziomie grupy/organizacji), audytor powinien uznać, że utrzymanie konsekwentnego standardu będzie wymagało dodatkowych narzędzi lub silnej dyscypliny procesowej.

Bezpieczne uruchamianie kodu zewnętrznego: akcje, pluginy, szablony

Współczesne pipeline’y w dużej mierze składają się z gotowych klocków: akcji społeczności w GitHub Actions, pluginów Jenkinsa, template’ów w GitLab CI, zadań marketplace’owych w Azure DevOps. To ogromne ułatwienie, ale jednocześnie powierzchnia ataku.

Minimalny zestaw pytań kontrolnych wygląda następująco:

• źródło i zaufanie – czy używane są oficjalne akcje/pluginy dostawcy i zweryfikowanych vendorów, czy losowe repozytoria z GitHuba,
• pinning wersji – czy wersje akcji/pluginów są przypięte do konkretnych commitów/tagów, czy używane są „floating tags” typu v1, latest, master,
• przegląd uprawnień – czy akcje/procesy zewnętrzne otrzymują dostęp „just enough” (np. odczyt repo zamiast admin org),
• polityki użycia marketplace’ów – możliwość centralnego whitelistowania/blacklistowania akcji/pluginów na poziomie organizacji,
• aktualizacje i deprecjacje – czy istnieje mechanizm monitorowania, że akcja/plugin jest porzucony lub zawiera znane podatności.

Sygnał ostrzegawczy: pipeline używa kilkunastu akcji społeczności z przypięciem do gałęzi głównej repo i bez jakiegokolwiek procesu przeglądu. W takim przypadku złośliwa zmiana w jednym z tych repozytoriów staje się wejściem do Twojej infrastruktury.

Jeśli narzędzie CI/CD nie udostępnia centralnych polityk dla marketplace’u, rolę „strażnika bramy” musi przejąć architektura Git/SCM (np. przegląd pipeline’ów w code review) i dodatkowe mechanizmy skanowania konfiguracji.

Mechanizmy ochrony przed nadużyciami wewnętrznymi

Incydenty związane z CI/CD to nie tylko ataki zewnętrzne. Pipeline jest potężnym narzędziem dla osób z wewnątrz: developera, który ma nadmierne uprawnienia, czy administratora, który traktuje środowisko produkcyjne jak piaskownicę.

Przyglądając się ochronie przed nadużyciami wewnętrznymi, warto skupić się na:

• rozgraniczeniu ról – inne osoby odpowiadają za definicję pipeline’u, inne za jego uruchamianie w produkcji; brak pojedynczych „superuserów” obsługujących pełny cykl,
• wymogu podwójnej kontroli – manualne approvale dla wdrożeń na krytyczne środowiska, najlepiej z udziałem osoby spoza zespołu deweloperskiego,
• ograniczeniu dostępu do sekretów – brak dostępu wprost do wartości sekretów dla użytkowników, którzy jedynie konfigurują pipeline (view-only lub „write-only”),
• monitoringu anomalii – alerty na nietypowe akcje: uruchomienie pipeline’u z gałęzi spoza standardowego flow, nagłe dodanie nowych runnerów, zmiana destynacji deployu,
• zasadach dla kont serwisowych – wyraźne odróżnienie kont ludzkich i maszynowych, krótkie TTL tokenów, brak logowania interaktywnego kontami serwisowymi.

W praktyce audyt często pokazuje, że „dla wygody” kilku adminów ma pełne uprawnienia do wszystkiego: SCM, CI/CD, chmury, rejestru kontenerów. W takiej konfiguracji nawet nieumyślna pomyłka może mieć skutki na poziomie całej organizacji.

Jeśli narzędzie CI/CD nie wspiera granularnych ról lub approvali, organizacja powinna rozważyć dodatkowe „bezpieczniki” w innych warstwach (np. kontrola na poziomie chmury lub klastra, wymagana aprobata zmian infrastrukturalnych poza CI/CD).

Ranking ogólny: które narzędzia CI/CD najłatwiej utwardzić

Przechodząc od kryteriów do praktyki, można ułożyć ogólny ranking z punktu widzenia „jak daleko od pudełka do minimum przyzwoitości”. Ocenie podlegają przede wszystkim: domyślne zabezpieczenia, ergonomia włączania mechanizmów bezpieczeństwa, dojrzałość modeli uprawnień, integracja z sejfami oraz dostępność wbudowanych lub łatwo podłączalnych skanerów.

Poniższy przegląd nie jest testem funkcjonalnym całego ekosystemu, ale właśnie próbą odpowiedzi na pytanie: ile pracy wymaga doprowadzenie platformy do sensownego poziomu bezpieczeństwa przy typowym zespole (Dev + Ops + Security) w średniej organizacji.

GitLab CI/CD (SaaS i self-managed) – wysoki poziom integracji i bogaty zestaw security „z pudełka”

GitLab jest jednym z najbardziej zintegrowanych rozwiązań all-in-one: repozytoria, CI/CD, zarządzanie projektami i szerokie portfolio funkcji bezpieczeństwa w jednym interfejsie. Dla audytora oznacza to duże plusy: jedno miejsce logowania, spójne role i centralne polityki. Jednocześnie z rozbudowaną funkcjonalnością przychodzi duża złożoność, zwłaszcza w wariancie self-managed.

Z punktu widzenia utwardzania pipeline’ów GitLaba można podzielić na dwa scenariusze: GitLab.com (SaaS) oraz instalacje własne.

GitLab.com – sensowne domyślne zabezpieczenia i stosunkowo niski próg wejścia

W wariancie SaaS wiele krytycznych problemów jest rozwiązanych przez dostawcę: aktualizacje, backupy, iso­lację runnerów shared, dostępność wbudowanych skanerów i integracji z chmurą. Platforma ma od początku:

• natywne zmienne i masked variables z możliwością rozróżnienia zakresu (projekt, grupa, protected),
• dobrze zdefiniowany RBAC z rolami project/group (Guest, Reporter, Developer, Maintainer, Owner),
• mechanizmy protected branches i protected tags, pozwalające na ograniczenie, kto może modyfikować pipeline’y i wypuszczać releasy,
• wbudowane template’y security dla SAST, DAST, SCA, skanowania kontenerów i dependency scanning,
• przyzwoite logowanie i trace pipeline’ów, chociaż pełne logi audytowe są bardziej elastyczne w wyższych planach.

GitLab.com – typowe pułapki i praktyczne punkty kontrolne

Przy utwardzaniu GitLab.com pierwsza fala działań jest stosunkowo prosta, druga wymaga już konsekwencji procesowej. Z punktu widzenia audytora warto przejrzeć kilka stałych obszarów konfiguracji.

• polityka tworzenia projektów i grup – czy każdy użytkownik może zakładać własne projekty/grupy, czy istnieje kontrola nad strukturą i dziedziczeniem uprawnień,
• konfiguracja protected branches/tags – czy kluczowe gałęzie (main, master, release/*) oraz tagi releasowe są chronione i ograniczone do wąskiej grupy maintainerów,
• centralne template’y .gitlab-ci.yml – czy pipeline’y są budowane w oparciu o wspólne include’y i szablony grupowe, czy każdy projekt ma własną, niespójną konfigurację,
• domyślne ustawienia runnerów – czy stosowane są wyłącznie runnerzy shared i dobrze zweryfikowani runnerzy grupowi/projektowi, czy zdarzają się „prywatne” instancje podpięte przez deweloperów,
• polityka dla forka – czy pipeline’y z forków mają ograniczone uprawnienia (mniej sekretów, brak dostępu do produkcyjnych deploy’i).

Sygnał ostrzegawczy: w organizacji istnieje kilkadziesiąt projektów, w części z nich zdefiniowany jest manualny deploy na produkcję dostępny dla roli Developer, a protected branches nie są skonfigurowane. W takiej konfiguracji dowolny developer może zmodyfikować pipeline, wstrzyknąć krok z dostępem do sekretów i przeprowadzić nieautoryzowany deploy.

Jeżeli GitLab.com jest wykorzystywany bez centralnych szablonów i bez spójnej polityki ról w grupach, platforma szybko staje się zbiorem „lokalnych eksperymentów”. Samo narzędzie daje dobre mechanizmy, ale brak ich ujednoliconego użycia praktycznie zeruje korzyści.

GitLab self-managed – pełna kontrola, pełna odpowiedzialność

Instalacje on-premise lub w chmurze własnej oferują znacznie większą elastyczność, ale wymagają też dojrzałości operacyjnej. Z punktu widzenia bezpieczeństwa pipeline’ów pojawia się kilka dodatkowych wymiarów, których w SaaS nie ma lub są schowane przed użytkownikiem.

• architektura runnerów – wybór executorów (shell, Docker, Kubernetes, custom) i ich izolacji. Shell-runner na wspólnym serwerze z innymi usługami to klasyczny antywzorzec,
• separacja środowisk – osobne instancje GitLaba dla dev/test/prod lub przynajmniej twarde rozdzielenie grup i runnerów między środowiskami,
• integracja z zewnętrznym sejfem – podpięcie Vault/Secret Manager jako źródła sekretów dla runnerów, zamiast przechowywania wszystkiego w zmiennych GitLaba,
• aktualizacje i hardening samej platformy – regularne upgrade’y, stosowanie rekomendowanych ustawień z benchmarków (np. CIS), osobne bazy danych/redis dla krytycznych komponentów,
• audyt konfiguracji omnibus/helm – przejrzenie konfiguracji instalacyjnej pod kątem domyślnych haseł, niezahardowanych endpointów, braku TLS wewnątrz klastra.

Praktyczny scenariusz: w średniej organizacji GitLab self-managed działa od kilku lat, z licznymi migracjami i „szybkimi łatkami”. Runner shellowy, uruchamiany pod kontem z uprawnieniami sudo, ma dostęp zarówno do plików konfiguracji GitLaba, jak i do kubeconfig klastra produkcyjnego. Jedno przejęte repo z możliwością modyfikacji .gitlab-ci.yml otwiera atakującemu drogę do całej infrastruktury.

Jeżeli GitLab self-managed jest eksploatowany jak klasyczne narzędzie deweloperskie („ważne, żeby działało i było szybkie”), bez jasno określonego właściciela bezpieczeństwa i planu utrzymania, staje się elementem krytycznej infrastruktury bez opieki. Przy takim stanie rzeczy nawet najlepsze praktyki na poziomie pipeline’ów nie zrekompensują słabego fundamentu.

GitLab – mocne strony z perspektywy łatwości utwardzania pipeline’ów

Na tle innych platform GitLab ma kilka wyraźnych atutów, które z punktu widzenia audytora obniżają koszt osiągnięcia przyzwoitego poziomu bezpieczeństwa.

• wspólna domena dla kodu, pipeline’ów i security – jedna struktura grup/projektów upraszcza zarządzanie uprawnieniami i egzekwowanie standardów,
• rozbudowane include’y i szablony – możliwość centralnego zdefiniowania polityk bezpieczeństwa (np. obowiązkowe joby SAST/SCA, standardowe reguły deploy’u) i dołączania ich do projektów,
• rozsądne domyślne security dla zmiennych – masked i protected variables, dziedziczenie w dół z grup oraz wyraźne rozróżnienie zmiennych chronionych przed pipeline’ami z nieprotected branches,
• natywne integracje security – gotowe joby dla skanerów (zwłaszcza w wyższych planach), które można włączyć minimalną konfiguracją,
• dobrze udokumentowane API i eventy – łatwość podłączania narzędzi audytowych, które same „ściągają” konfiguracje pipeline’ów i repozytoriów do analizy.

Jeśli organizacja potrafi zainwestować czas w przygotowanie centralnych szablonów i polityk, GitLab pozwala stosunkowo łatwo zbudować standardowy „baseline” bezpieczeństwa obowiązujący wszystkie nowe projekty. Trudność rośnie tam, gdzie istnieje duży „dług konfiguracyjny” – dziesiątki starych repozytoriów i pipeline’ów wymagających migracji.

GitLab – ograniczenia i koszty złożoności

Od strony bezpieczeństwa problemem nie jest brak funkcji, ale ich liczba i rozproszenie. Administratorzy i zespoły często nie wykorzystują dostępnych mechanizmów, bo trudno ogarnąć je całościowo.

• rozstrzał funkcji między planami – część przydatnych mechanizmów (np. bardziej zaawansowane skanery czy rozszerzony audit log) trafia do wyższych planów, co prowadzi do hybrydowych konfiguracji,
• skomplikowana dziedzicząca się struktura uprawnień – połączenie group permissions, project members, access tokens i „invited users” bywa trudne do przejrzenia,
• różne typy runnerów ze złożonymi konfiguracjami – Kubernetes executor, autoscaling, różne pule runnerów dla wielu grup – każdy z tych elementów jest osobnym obszarem do hardeningu,
• przeciążenie interfejsu – liczne opcje w UI powodują, że zmiana pojedynczej polityki (np. dla pipeline’ów na forkach) potrafi zostać przeoczona lub wprowadzona tylko w części projektów,
• brak w pełni centralnych policy enforcement points – wiele krytycznych ustawień (np. reguły dla .gitlab-ci.yml) nadal wymaga dyscypliny na poziomie repozytoriów lub narzędzi zewnętrznych.

Sygnał ostrzegawczy: w organizacji istnieją dwie lub trzy „szkoły” konfiguracji GitLaba – część zespołów używa templatingu i centralnych include’ów, część buduje pipeline’y ręcznie, część z kolei ma własne, nieudokumentowane runner’y. Z zewnątrz wygląda to jak trzy różne platformy, choć formalnie to ten sam GitLab.

Jeżeli GitLab nie ma przypisanego właściciela (lub zespołu) odpowiedzialnego za standardy i migracje, platforma będzie sukcesywnie dryfować w stronę niejednorodnego, trudnego do audytowania krajobrazu, w którym zidentyfikowanie rzeczywistych ryzyk staje się zadaniem na tygodnie, a nie dni.

GitHub Actions – szybki start, ale bezpieczeństwo kosztuje dyscyplinę

GitHub Actions to naturalny wybór dla zespołów już pracujących na GitHubie. Integracja z repozytorium kodu jest bezproblemowa, a marketplace akcji drastycznie przyspiesza budowę pipeline’ów. Od strony bezpieczeństwa ten komfort ma jednak swoją cenę: łatwość użycia marketplace’u szybko zamienia się w powierzchnię ataku.

Z perspektywy audytora GitHub Actions prezentuje dość czytelny obraz: fundamenty są sensowne (permissions, secrets, environments), ale bez świadomej konfiguracji domyślne ustawienia bywają zbyt liberalne.

GitHub Actions – mocne strony pod kątem utwardzania

W samym rdzeniu Actions znajduje się kilka mechanizmów, na których można oprzeć minimum bezpieczeństwa.

• job permissions – możliwość deklaratywnego ograniczenia uprawnień tokenów GITHUB_TOKEN per workflow/job (np. tylko read:contents),
• environments z wymaganym approvalem – wbudowana koncepcja środowisk (dev, staging, prod) z manualnymi zatwierdzeniami wdrożeń i ograniczeniem, kto może je akceptować,
• secrets na poziomie repo, środowiska i organizacji – sensowny model dziedziczenia, pozwalający odseparować sekrety produkcyjne od deweloperskich,
• protection rules dla branchy – możliwość powiązania build/deploy z konkretnymi regułami dla gałęzi (wymagane review, status checks),
• dobrze opisany model eventów – łatwość analizy, kiedy pipeline się uruchamia i z jakimi uprawnieniami.

Jeżeli zespół konsekwentnie stosuje ograniczanie permissions oraz environments z approvalami, GitHub Actions daje się dość szybko „zamknąć” w bezpieczniejszych ramach. Kluczowe jest tu słowo „konsekwentnie” – pojedynczy workflow lekceważący te zasady może otworzyć boczne drzwi.

GitHub Actions – typowe słabości i pułapki bezpieczeństwa

Największym ryzykiem w Actions jest masowe korzystanie z akcji społeczności przy braku pinningu wersji i centralnych polityk. Drugi wątek to domyślne, szerokie uprawnienia workflow’ów.

• floating tags w akcjach – użycie zapisów typu uses: org/action@v1 bez przypięcia do konkretnego SHA pozwala na niekontrolowaną zmianę kodu wykonującego się w pipeline’ach,
• workflowy uruchamiane z pull requestów z forków – niewłaściwa konfiguracja może doprowadzić do sytuacji, w której kod od nieznanego kontrybutora wykonuje się z pełnymi uprawnieniami w repo docelowym,
• domyślne permissions dla GITHUB_TOKEN – historycznie zbyt szerokie, co przy braku explicite ustawionego permissions: w workflowach dawało nadmierne możliwości,
• brak centralnego whitelisting/blacklisting akcji (w podstawowej konfiguracji) – kontrola nad tym, jakie akcje można stosować, jest w dużej mierze procesowa,
• rozproszenie konfiguracji secrets – mieszanie secrets na poziomie repo i organizacji bez jasnej polityki, które są krytyczne i kto nimi zarządza.

Sygnał ostrzegawczy: większość workflowów w organizacji korzysta z kilku kluczowych akcji społeczności z marketplace’u, wszystkie używają floating tagów, a nikt nie jest w stanie wskazać, kiedy ostatnio weryfikowano te repozytoria. W takiej sytuacji atak supply chain przez przejęcie popularnej akcji ma realną szansę powodzenia.

Jeżeli GitHub Actions jest rozwijany „chaotycznie” – każdy zespół dodaje własne workflowy, dobiera dowolne akcje i nie ma centralnej osoby/roli przeglądającej konfiguracje – poziom bezpieczeństwa będzie silnie zależał od świadomości pojedynczych deweloperów, a nie od polityk organizacyjnych.

Punkty kontrolne bezpieczeństwa dla GitHub Actions

Przy przeglądzie konfiguracji GitHub Actions warto przygotować konkretną listę pytań, które pomagają ocenić, jak daleko pipeline’y odbiegły od „minimum przyzwoitości”.

• permissions na poziomie workflow – ile workflowów ma zdefiniowane explicite ograniczone permissions:, a ile korzysta z domyślnych ustawień,
• pinning wersji akcji – czy akcje z marketplace’u są przypięte do commit SHA, tagów z gwarancją stabilności, czy do otwartych aliasów typu @master,
• konfiguracja events – czy workflowy wywoływane przez pull_request i pull_request_target są świadomie odseparowane i mają ograniczone uprawnienia,
• użycie environments – czy wdrożenia na produkcję są zawsze realizowane przez environments z approvalem i ograniczonym zestawem approverów,
• polityka secrets – czy istnieje wykaz krytycznych sekretów na poziomie organizacji i jasne przypisanie odpowiedzialności za ich rotację.

Jeśli większość workflowów nie definiuje jawnie permissions ani nie używa environments, a decyzje o akcjach z marketplace’u są pozostawione pojedynczym deweloperom, GitHub Actions wymaga pilnego ujednolicenia standardów. W odwrotnej sytuacji – z wprowadzonymi centralnymi zaleceniami i szablonami workflowów – platforma może być relatywnie bezpieczna, choć nadal silnie zależna od dyscypliny zespołów.

Jenkins – maksymalna elastyczność, minimalne domyślne bezpieczeństwo

Jenkins jest nadal obecny w wielu większych organizacjach, zwłaszcza tam, gdzie CI/CD rozwijało się wcześnie. To narzędzie niezwykle elastyczne, ale niemal całkowicie pozbawione bezpiecznych domyślnych ustawień. Hardening Jenkinsa to w praktyce osobny projekt, często bardziej zbliżony do zabezpieczania platformy PaaS niż typowego narzędzia CI.

Z punktu widzenia audytora Jenkins jest systemem, w którym wszystko można zrobić, a niewiele jest z góry zabronione. Oznacza to dużą swobodę dla doświadczonych zespołów i ogromne ryzyko w środowiskach bez wyraźnego nadzoru security.

Jenkins – obszary krytyczne przy utwardzaniu

Bezpieczeństwo Jenkinsa zaczyna się na poziomie samej instancji, a dopiero później schodzi do pipeline’ów. Kilka punktów jest niezmiennie problematycznych.

Najczęściej zadawane pytania (FAQ)

Na co zwracać uwagę przy wyborze „bezpiecznego” narzędzia CI/CD?

Podstawowy punkt kontrolny to funkcje security dostępne out‑of‑the‑box: sensowny model uprawnień (RBAC), izolacja runnerów, zarządzanie sekretami, audit logi, ochrona gałęzi oraz możliwość rozdzielenia środowisk (dev/test/prod). Jeżeli te elementy wymagają od razu instalacji wielu pluginów lub własnego „glue code”, to sygnał ostrzegawczy.

Drugie kryterium to ergonomia hardeningu: jak szybko da się ustawić minimum (np. osobne serwisy dla runnerów, ograniczenie tokenów, zasady kto może edytować pipeline). Jeżeli uzyskanie podstawowego poziomu bezpieczeństwa wymaga tygodni prac i walki z dokumentacją, narzędzie w praktyce będzie nieutwardzone.

Czym różni się bezpieczeństwo CI/CD w modelu SaaS od self-hosted?

W modelu SaaS dostawca odpowiada za infrastrukturę, aktualizacje i podstawową izolację środowisk. Zwykle domyślne ustawienia są już względnie bezpieczne: świeże wersje oprogramowania, odseparowane build roomy, standardowe polityki użycia sekretów. Minusem jest mniejsza możliwość dostosowania wszystkiego „pod siebie” oraz konieczność zaufania operatorowi chmury.

W self‑hosted pełną kontrolę nad bezpieczeństwem ma Twój zespół – od systemu operacyjnego po konfigurację runnerów. To daje elastyczność, ale też pełną odpowiedzialność za hardening, łatki i monitoring. Jeśli nie masz dojrzałego zespołu, self‑hosted z rozbudowanym ekosystemem pluginów szybko staje się zbiorem niezarządzanych ryzyk.

Jakie funkcje security powinno mieć narzędzie CI/CD „w pudełku”?

Minimum to: granularny RBAC (kto może edytować pipeline, sekrety, konfigurację runnerów), natywne zarządzanie sekretami z kontrolą dostępu, czytelne audit logi oraz mechanizmy ochrony gałęzi i tagów releasowych (protected branches/tags). Przydatne są też: możliwość izolacji jobów (np. osobne runnery dla prod), wbudowane polityki retencji logów i artefaktów oraz podstawowa integracja z zewnętrznymi sejfami (Vault, KMS).

Jeżeli nawet te elementy trzeba „dokręcać” kilkunastoma pluginami lub własnymi skryptami, każdy taki element staje się osobnym punktem awarii i źródłem długu bezpieczeństwa. Im więcej krytycznych elementów jest dostępnych natywnie i dobrze udokumentowanych, tym łatwiej utrzymać spójny poziom ochrony.

Jakie są najczęstsze błędy bezpieczeństwa w pipeline’ach CI/CD?

Najczęściej powtarzające się problemy to: runner z uprawnieniami „do wszystkiego”, sekrety trzymane w plaintext (np. w zmiennych środowisk bez ograniczeń), zbyt szerokie tokeny dostępu oraz korzystanie z niezweryfikowanych akcji/pluginów z marketplace’ów. Częstym błędem jest też brak rozdzielenia środowisk – ten sam pipeline i ten sam runner obsługuje dev, test i produkcję.

Jeżeli w logach pipeline’u widzisz pełne tokeny, a edycja pipeline’u jest możliwa dla każdego developera, to jasny sygnał ostrzegawczy. W takiej sytuacji atak na CI/CD bywa prostszy niż atak na samą aplikację, bo wystarczy „wstrzyknąć” złośliwą zmianę w definicji joba.

Jak sprawdzić, czy obecne narzędzie CI/CD jest wystarczająco bezpieczne?

Praktyczny sposób to krótki audyt konfiguracji domyślnej i kilku reprezentatywnych projektów. Kluczowe pytania kontrolne: kto może edytować pipeline’y i sekrety, czy runner prod jest odseparowany od reszty, czy są włączone audit logi i czy ktoś je faktycznie przegląda, oraz czy da się z poziomu pojedynczego joba uzyskać dostęp do wszystkich środowisk i repozytoriów.

Dobrym testem jest też ocena wysiłku, jaki trzeba włożyć, by dojść do „minimum” (RBAC, izolacja, sekrety). Jeśli inżynier DevOps jest w stanie w ciągu kilkunastu godzin podciągnąć bezpieczeństwo istotnie w górę, narzędzie jest sensowne. Jeżeli na to samo potrzeba projektu na kilka miesięcy, rozważ zmianę platformy lub architektury.

Czy wbudowane skanery SAST/SCA w narzędziu CI/CD wystarczą do bezpieczeństwa pipeline’u?

Nie. Skanery kodu i zależności rozwiązują część problemów aplikacyjnych, ale nie adresują kluczowych ryzyk samej platformy CI/CD: nadużycia uprawnień, wycieku sekretów, przejęcia runnerów czy złośliwych pluginów. Pipeline, który każdy może modyfikować, z runnerem mającym pełny dostęp do wszystkich systemów, pozostaje miękkim celem, nawet jeśli ma komplet skanerów.

Sensowny model to: najpierw architektura, uprawnienia, izolacja i zarządzanie sekretami, dopiero na tym fundamencie dołożone skanery (natywne lub zewnętrzne). Jeśli musisz wybierać, bezpieczna konfiguracja pipeline’u ma priorytet nad „bogatą tablicą wyników SAST” w raporcie.

Jak porównywać narzędzia CI/CD pod kątem security, gdy każde ma inny zestaw funkcji?

Przydatne jest rozbicie oceny na kilka koszyków: funkcje wbudowane vs. wymagające rozszerzeń, model wdrożenia (SaaS vs self‑hosted), łatwość integracji z istniejącymi narzędziami security oraz jakość dokumentacji security. Następnie dla każdego narzędzia sprawdzasz, ile punktów kontrolnych spełnia „od ręki”, a gdzie wymaga dodatkowej inżynierii.

Narzędzie z przeciętnymi natywnymi skanerami, ale świetną integracją z komercyjnym SAST/SCA i zewnętrznym sejfem, może w praktyce być bezpieczniejsze niż platforma „all‑in‑one”, która jest zamknięta i trudna do rozszerzenia. Jeśli dojście do sensownego poziomu ochrony można zaplanować i zrealizować w krótkim czasie, to dobry kandydat do wysokiej pozycji w rankingu.

Kluczowe Wnioski

• Pipeline CI/CD jest dziś jednym z kluczowych celów atakujących, bo stanowi najkrótszą i często najsłabiej chronioną ścieżkę od repozytorium do produkcji, zwykle z uprawnieniami pozwalającymi zmieniać artefakty, konfigurację i infrastrukturę.
• Główne ryzyka wynikają z wygodnych, ale niebezpiecznych skrótów: kont z uprawnieniami „boga”, sekretów w plaintext, nadmiernie rozbudowanych logów oraz pipeline’ów umożliwiających zdalne wykonywanie kodu zbyt szerokimi uprawnieniami.
• Rosnąca powierzchnia ataku to efekt m.in. rozproszonych zespołów, dynamicznego IaC, setek jobów na runnerach oraz używania zewnętrznych marketplace’ów z pluginami i akcjami – każdy taki dodatek bez właściwego modelu uprawnień i izolacji jest potencjalnym wektorem ataku.
• Skanery SAST/SCA wbudowane w narzędzie CI/CD nie wystarczą, jeśli architektura, RBAC, izolacja jobów i zarządzanie sekretami są słabe – bez tego mechanizmy skanowania stanowią jedynie cienką warstwę kosmetyki.
• Przy ocenie bezpieczeństwa narzędzia kluczowym punktem kontrolnym jest rozróżnienie funkcji security dostępnych „z pudełka” od tych wymagających pluginów i własnego „glue code”; im więcej krytycznych mechanizmów jest natywnych i dobrze opisanych, tym niższe ryzyko i mniejsza liczba punktów awarii.
• Model wdrożenia (SaaS vs self-hosted) bezpośrednio wpływa na odpowiedzialność za hardening: w SaaS dostawca zapewnia wiele parametrów bezpieczeństwa domyślnie, natomiast w self-hosted cały ciężar konfiguracji, aktualizacji i utrzymania minimalnych standardów spoczywa na zespole wewnętrznym.

Opracowano na podstawie

• NIST Special Publication 800-204C: Implementation of DevSecOps for a Microservices-based Application with a CI/CD Pipeline. National Institute of Standards and Technology (2022) – Wytyczne NIST dot. zabezpieczania pipeline’ów CI/CD i DevSecOps
• NIST Secure Software Development Framework (SSDF), SP 800-218. National Institute of Standards and Technology (2022) – Ramy bezpiecznego wytwarzania oprogramowania, w tym automatyzacji i CI/CD
• OWASP CI/CD Security Cheat Sheet. OWASP Foundation – Praktyczne zalecenia bezpieczeństwa dla narzędzi i pipeline’ów CI/CD