Narzędzia bezpieczeństwa CI/CD: runner i build w porównaniu

Każde porównanie pokazuje, w czym drugi produkt jest dobry, czym różni się CRACI i kiedy warto używać obu. Wszystkie kategorie: wszystkie porównania.

Dlaczego pipeline potrzebuje własnych narzędzi bezpieczeństwa

Pipeline CI/CD przechowuje poświadczenia, pobiera kod z internetu i wytwarza artefakty, które uruchamiają Państwa klienci. To czyni go celem samym w sobie. Napastnik, który może zmienić to, co build pobiera lub wytwarza, nie musi w ogóle dotykać Państwa kodu źródłowego. Skanery kodu nie powstały z myślą o tym, ponieważ odczytują repozytorium, a nie build.

Narzędzia bezpieczeństwa CI/CD zamykają tę lukę z różnych stron. Jedne sprawdzają konfigurację pipeline'u, inne obserwują, co dzieje się na runnerze w czasie działania zadania, a jeszcze inne kontrolują sam runner. To, do której grupy należy narzędzie, mówi więcej niż lista funkcji, ponieważ decyduje o tym, co narzędzie widzi i co może zatrzymać.

Rodzaje narzędzi bezpieczeństwa CI/CD

Skanery odczytujące kod

Analiza statyczna (SAST), skanowanie sekretów i analiza składu oprogramowania (SCA) odczytują repozytorium: pliki źródłowe, manifesty i lockfile. GitHub Advanced Security łączy na przykład skanowanie kodu CodeQL ze skanowaniem sekretów i push protection oraz alerty Dependabot z GitHub Advisory Database. Te narzędzia znajdują problemy przed uruchomieniem buildu. Nie widzą, co build faktycznie pobrał ani z czym się łączył.

Narzędzia utwardzające pipeline wokół buildu

Narzędzia do oceny stanu bezpieczeństwa i nadzoru sprawdzają konfigurację pipeline'u. Cycode monitoruje polityki bezpieczeństwa CI/CD, konfiguracje i nadzór. StepSecurity prowadzi inwentarz używanych akcji zewnętrznych, z procesami zatwierdzania nowych, i otwiera pull requesty przypinające akcje do SHA commitów oraz ustawiające uprawnienia GITHUB_TOKEN zgodnie z zasadą najmniejszych uprawnień. Te narzędzia utrudniają nadużycie pipeline'u, ale działają na definicji buildu, a nie na buildzie w trakcie jego wykonywania.

Agenty obserwujące runner

Agenty runtime działają wewnątrz zadania na runnerach, które Państwo zachowują. StepSecurity Harden-Runner monitoruje połączenia wychodzące, procesy i zapisy plików, wiąże każde z nich z krokiem workflow, który je wywołał, i może blokować ruch wychodzący spoza listy dozwolonych. Cimon firmy Cycode monitoruje wykonywanie procesów, ruch wychodzący i dostęp do plików na poziomie jądra za pomocą eBPF, tworzy SBOM zaobserwowany w czasie działania i podpisuje dane o pochodzeniu SLSA. Agenty działają w wielu systemach CI i na runnerach hostowanych, ponieważ dodaje się je do istniejącej infrastruktury.

Runnery, które kontrolują i rejestrują build

CRACI przyjmuje ostatnie podejście: zastępuje runner. Zadania działają w CRACI z runs-on: craci, a uruchomienia nadal są widoczne w GitHub. Polityka ruchu wychodzącego jest częścią runnera, jest walidowana przed startem zadania i blokuje w razie błędu. Proxy rozpoznające pakiety rejestruje każdy pakiet pobrany przez zadanie, łącznie z pakietami przywróconymi z cache CI, więc każde zadanie tworzy SBOM ze stanem kompletności, ślad sieciowy i dane o pochodzeniu.

Zestawienie

Porównanie narzędzi bezpieczeństwa CI/CD, stan na wrzesień 2026
Funkcja	CRACI	StepSecurity Harden-Runner	Cycode (Cimon)	GitHub Advanced Security
Gdzie działa	Sam jest runnerem	Agent na runnerach, które Państwo utrzymują	Agent w Państwa obecnym CI	Skanuje repozytoria w GitHub
Kontrola ruchu wychodzącego z buildu	Domyślne blokowanie lub zezwalanie, przy awarii blokuje	Lista dozwolonych w trybie blokowania	Tryb zapobiegania z dozwolonymi hostami
Tryb audytu przed blokowaniem	Tryb monitorowania lub dry-run	Wzorce bazowe dla każdego zadania	Tryb wykrywania	Brak kontroli ruchu wychodzącego
Monitorowanie procesów i plików			eBPF	Brak informacji
SBOM rejestrowany z buildu	Dla każdego zadania, ze stanem kompletności	Rejestruje miejsca docelowe, procesy, pliki	SBOM obserwowany w czasie działania	Graf z manifestów oraz przesłane dane z buildu
Podpisane pochodzenie buildu	Brak podpisanego pochodzenia	Brak informacji	SLSA Provenance v1.0	Atestacje artefaktów
SAST		Brak informacji		CodeQL
Skanowanie sekretów		Brak informacji		Secret Protection
Obsługiwane systemy CI	Dziś GitHub Actions; GitLab CI i Jenkins w planach rozwoju	GitHub Actions, GitLab CI, Azure DevOps	GitHub Actions, Azure Pipelines, Jenkins, GitLab CI, Buildkite, Harness	GitHub, a Azure DevOps jako osobny zakup

W zestawie
Częściowo
Brak
W planach rozwoju

„Nie podano” oznacza, że nie mogliśmy tego potwierdzić na publicznych stronach dostawcy. Szczegóły każdej kolumny znajdą Państwo na stronach CRACI vs StepSecurity, CRACI vs Cycode oraz CRACI vs GitHub Advanced Security.

Które narzędzie obejmuje które ryzyko CI/CD

OWASP Top 10 CI/CD Security Risks to najszerzej stosowana lista tego, co może pójść źle w pipeline. Jej dziesięć ryzyk to:

CICD-SEC-1: Insufficient Flow Control Mechanisms
CICD-SEC-2: Inadequate Identity and Access Management
CICD-SEC-3: Dependency Chain Abuse
CICD-SEC-4: Poisoned Pipeline Execution (PPE)
CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
CICD-SEC-6: Insufficient Credential Hygiene
CICD-SEC-7: Insecure System Configuration
CICD-SEC-8: Ungoverned Usage of 3rd Party Services
CICD-SEC-9: Improper Artifact Integrity Validation
CICD-SEC-10: Insufficient Logging and Visibility

Żadne pojedyncze narzędzie nie obejmuje wszystkich dziesięciu. Oto cztery, w których mają zastosowanie kontrole CRACI:

Ryzyka OWASP CI/CD, którymi zajmuje się CRACI
Funkcja	Czego dotyczy ryzyko	Co robi CRACI
CICD-SEC-3: Dependency Chain Abuse	Build pobiera złośliwy lub nieoczekiwany pakiet	Polityka ruchu wychodzącego ogranicza źródła, z których zadanie może pobierać, a SBOM zadania rejestruje każdy pobrany pakiet
CICD-SEC-7: Insecure System Configuration	Słabe ustawienia systemów uruchamiających pipeline	Zadania działają w izolowanych maszynach wirtualnych, a polityka, której nie można zastosować, blokuje w razie błędu
CICD-SEC-9: Improper Artifact Integrity Validation	Zmanipulowany artefakt przechodzi przez pipeline, jakby był prawidłowy	Brak podpisanych danych o pochodzeniu; API zwraca dane o pochodzeniu dla każdego buildu
CICD-SEC-10: Insufficient Logging and Visibility	Ataki w pipeline pozostają niezauważone i nie da się ich zbadać	Ślad sieciowy dla każdego zadania, alerty o naruszeniach polityki oraz API zwracające SBOM-y, ślady sieciowe i dane o pochodzeniu

W przypadku CICD-SEC-7 CRACI obejmuje runner. Konfiguracja repozytoriów i organizacji GitHub pozostaje po Państwa stronie. Mówiąc wprost o reszcie: CRACI nie zajmuje się zarządzaniem tożsamością i dostępem (CICD-SEC-2) ani higieną poświadczeń (CICD-SEC-6) i nie zarządza kontrolą przepływu, uprawnieniami pipeline'u ani usługami zewnętrznymi (CICD-SEC-1, 5 i 8). Do tego służą skanowanie sekretów, takie jak GitHub Secret Protection czy wykrywanie sekretów Cycode, oraz opisane wyżej narzędzia do oceny stanu bezpieczeństwa.

Jak wybrać narzędzie bezpieczeństwa CI/CD

Zastąpić runnery czy je zachować. Jeśli chcą Państwo zachować runnery hostowane przez GitHub, runnery self-hosted lub inny system CI, kontrole w czasie działania można dodać za pomocą agenta. Jeśli są Państwo otwarci na zmianę runnera, runner taki jak CRACI zapewnia kontrolę ruchu wychodzącego i zapis buildu bez wdrażania agenta.
Tryb audytu już dziś. Harden-Runner i Cimon mogą obserwować ruch, zanim cokolwiek zablokują. Tryb monitorowania lub dry-run w CRACI jest w planach rozwoju.
Analiza śledcza na poziomie procesów. Jeśli podczas incydentu muszą Państwo wiedzieć, który proces zapisał który plik, zapewni to agent monitorujący procesy i pliki. CRACI nie monitoruje procesów ani zapisów plików.
SBOM i dowody dla CRA. Jeśli potrzebują Państwo SBOM każdego buildu na poziomie pakietów, danych o pochodzeniu i dowodów na potrzeby Cyber Resilience Act, warto sprawdzić, co każde narzędzie rejestruje i czy nadal monitoruje to, co dostarczono. CRACI rejestruje SBOM w czasie działania buildu, ponownie ocenia monitorowane SBOM-y, gdy pojawiają się nowe podatności, i eksportuje SBOM-y jako CycloneDX lub SPDX.
Platformy CI i systemy operacyjne. CRACI obsługuje dziś GitHub Actions (GitLab CI i Jenkins są w planach rozwoju) i działa na Linuksie na x86-64 i ARM64 (Windows i macOS są w planach rozwoju). Jeśli budują Państwo w innych systemach CI lub już teraz potrzebują runnerów Windows albo macOS, należy najpierw sprawdzić zakres obsługi agentów.
Kod i sekrety. Skanery kodu źródłowego i sekretów obejmują obszar, którego nie obejmuje żaden runner. CRACI nie ma SAST ani skanowania sekretów, więc należy zaplanować je osobno.

Agent na runnerze a bycie runnerem

Agent jest dodawany do infrastruktury zaprojektowanej przez kogoś innego. Na runnerach hostowanych przez GitHub instaluje go krok na początku każdego zadania, a jego zasięg zależy od tego, na co pozwala ta infrastruktura. Dzięki temu agenty mogą obejmować naraz runnery hostowane, floty self-hosted i kilka systemów CI, co jest realną zaletą, gdy buildy są rozproszone po nich wszystkich.

Runner, który sam egzekwuje politykę, działa odwrotnie. W CRACI polityka ruchu wychodzącego jest walidowana przed startem zadania, odrzuca nieznane pola i blokuje w razie błędu, więc polityka, której nie można zastosować, nie prowadzi do niezabezpieczonego uruchomienia. Jej źródła są typowane według ekosystemu, z 24 wbudowanymi presetami źródeł oprogramowania i źródłami niestandardowymi dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git, więc zapis dotyczy pakietów, a nie tylko hostów. W zadaniach działających w CRACI runner zastępuje agenty runtime, zamiast działać obok nich. Więcej o integracji CI/CD i generowaniu SBOM w czasie buildu. Mogą też Państwo umówić demo, aby zobaczyć zadanie GitHub Actions działające pod polityką ruchu wychodzącego.

CRACI w porównaniu z każdym narzędziem

CRACI kontra StepSecurity Agent na Państwa runnerze kontra bycie runnerem.

Obok siebie

Kilka narzędzi na jednej stronie, gdy wybierają Państwo kategorię, a nie jeden produkt.

Porównanie: Narzędzia bezpieczeństwa łańcucha dostaw oprogramowania Apiiro, Cycode, OX, Legit, Socket, Chainguard, StepSecurity i inne.

Narzędzia bezpieczeństwa CI/CD: pytania i odpowiedzi

Czym są narzędzia bezpieczeństwa CI/CD?

Narzędzia bezpieczeństwa CI/CD chronią pipeline, który zamienia kod źródłowy w wydane oprogramowanie. Dzielą się na cztery grupy: skanery odczytujące kod i zależności (SAST, skanowanie sekretów, SCA), narzędzia utwardzające konfigurację pipeline'u wokół buildu, agenty obserwujące runner w czasie działania zadania oraz runnery, które same kontrolują i rejestrują build. OWASP Top 10 CI/CD Security Risks to popularny sposób sprawdzenia, którymi ryzykami zajmuje się dane narzędzie.

Czym bezpieczeństwo CI/CD różni się od SCA?

Analiza składu oprogramowania (SCA) odczytuje manifesty i lockfile oraz wskazuje, które zadeklarowane zależności mają znane podatności. Bezpieczeństwo CI/CD chroni sam pipeline: kto może go zmieniać, do czego build ma dostęp i czy dostarczany artefakt jest tym, który zbudowano. CRACI pracuje na podstawie buildu: rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z pakietami przywróconymi z cache CI, i po wydaniu nadal monitoruje je pod kątem nowych podatności.

Czy przy CRACI potrzebuję agenta runtime?

Nie do kontroli ruchu wychodzącego ani zapisu buildu. W CRACI polityka ruchu wychodzącego jest częścią runnera, jest walidowana przed startem zadania i blokuje w razie błędu, więc CRACI zastępuje agenty takie jak Harden-Runner i Cimon w działających na nim zadaniach. Rezygnują Państwo z monitorowania procesów i plików, którego CRACI nie oferuje, oraz z trybu audytu, który jest w planach rozwoju CRACI. Jeśli analiza śledcza na poziomie procesów jest twardym wymogiem, zapewnia ją dziś agent na runnerach, które Państwo zachowują.

Czy narzędzia bezpieczeństwa CI/CD mogą blokować złośliwe pakiety?

Niektóre mogą, na różne sposoby. Kontrola ruchu wychodzącego uniemożliwia buildowi dostęp do źródeł spoza polityki, więc pobieranie z nieoczekiwanego hosta kończy się błędem. Listy blokowanych pakietów i kontrole rejestru w ogóle uniemożliwiają instalację znanej złośliwej wersji. CRACI egzekwuje dziś politykę ruchu wychodzącego dla każdego zadania, ze źródłami typowanymi według ekosystemu; listy blokowanych pakietów dla całej organizacji są w planach rozwoju CRACI.

Które narzędzia bezpieczeństwa CI/CD działają poza GitHub Actions?

Według stanu na wrzesień 2026 StepSecurity wymienia GitLab CI i Azure DevOps obok GitHub Actions, a Cimon firmy Cycode działa też na Azure Pipelines, Jenkins, GitLab CI, Buildkite i Harness. GitHub Advanced Security jest sprzedawany także dla Azure DevOps. CRACI obsługuje dziś GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju.

Porównanie narzędzi bezpieczeństwa CI/CD