CRACI vs GitLab CI

Krótka odpowiedź

GitLab to kompletna platforma DevSecOps: kontrola wersji, merge requesty, planowanie i CI/CD w jednym produkcie, z szerokim zestawem skanerów bezpieczeństwa i zarządzaniem podatnościami w planie Ultimate. Jeśli chcą Państwo jednego dostawcy dla całego cyklu życia oprogramowania, GitLab powstał właśnie z myślą o tym.

CRACI ma węższy zakres. To runner zgodny z GitHub Actions, który rejestruje każdą zewnętrzną zależność pobieraną przez build, kontroluje, do czego build może dotrzeć, i zamienia ten zapis w SBOM-y, dane o pochodzeniu i dowody dla CRA. Główna różnica to tradycyjne CI z podłączonymi skanerami kontra CI, w którym to sam runner jest zapisem bezpieczeństwa.

Najpierw jedna kwestia praktyczna. CRACI obsługuje dziś tylko GitHub Actions; GitLab CI i Jenkins są w planach rozwoju. Jeśli Państwa pipeline'y działają w GitLab CI, musieliby Państwo przenieść je do GitHub Actions, aby korzystać z runnerów CRACI, lub poczekać na obsługę GitLab CI, która jest w planach rozwoju.

Co GitLab robi dobrze

Jedna platforma. Kod, przeglądy, pipeline'y, znaleziska bezpieczeństwa i planowanie znajdują się w jednym miejscu, z jednym modelem uprawnień. Dla wielu organizacji już to przesądza sprawę.

Skanowanie bezpieczeństwa według planów. Warto dokładnie sprawdzić, co obejmuje każdy plan. Według GitLab podstawowy SAST, wykrywanie sekretów i skanowanie kontenerów działają we wszystkich planach, łącznie z Free. W Free i Premium te skany tworzą artefakty raportów JSON. Ultimate dodaje wokół nich workflow: znaleziska w merge requestach, raport podatności, listę zależności, zatwierdzenia bezpieczeństwa i GitLab Advanced SAST. Skanowanie zależności, ciągłe skanowanie podatności i DAST to funkcje Ultimate. Skanowanie kontenerów może też tworzyć raport SBOM CycloneDX w każdym planie.

Pochodzenie. GitLab Runner może generować deklarację pochodzenia artefaktu w formacie SLSA 1.0 we wszystkich planach. Istnieją też podpisane atestacje SLSA Level 3, ale GitLab wymienia je jako eksperyment na GitLab.com dla Ultimate, za flagą funkcji domyślnie wyłączoną.

Wybór runnera. Runnery hostowane przez GitLab obejmują Linux na x86-64 (od 2 do 32 vCPU) i arm64, a Windows i macOS są w wersji beta. Można też uruchamiać własne runnery w dowolnym miejscu, a GitLab podaje, że zadania na własnych runnerach nie zużywają minut obliczeniowych. GitLab Dedicated dodaje rezydencję danych w wybranym regionie.

Czym różni się CRACI

SBOM pochodzi z buildu, a nie z lockfile

Skanowanie zależności oparte na SBOM w GitLab wykrywa zależności z obsługiwanych lockfile lub eksportów grafu zależności. To solidne podejście, gdy lockfile mówi wszystko. Buildy często robią więcej: uruchamiają skrypty instalacyjne, pobierają toolchainy, przywracają cache i pobierają obrazy bazowe.

CRACI widzi tę aktywność, ponieważ jest runnerem. Proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów podczas działania zadania: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presetów pobierania. Dowody zależności przemieszczają się razem z cache CI, więc pakiet przywrócony z cache nadal jest uwzględniany. Każde zadanie tworzy SBOM w formacie CycloneDX lub SPDX.

Kompletność jest określona, a nie zakładana

Każdy SBOM ma stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Gdy w zapisie jest luka, widzą ją Państwo.

Sieć buildu podlega polityce

Polityki ruchu wychodzącego CRACI działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania i typowanymi źródłami niestandardowymi dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git. Polityki są walidowane przed startem zadania, w razie błędu blokują ruch i wysyłają alert o naruszeniu. W GitLab kontrola sieci buildów zależy od tego, co sami Państwo skonfigurują wokół własnych runnerów.

Pochodzenie

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu i nie deklaruje żadnego poziomu SLSA.

Monitorowanie tego, co dostarczono

CRACI agreguje podatności z wielu buildów i repozytoriów oraz nadal ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych biuletynów.

Co wybrać

• Warto pozostać przy GitLab, jeśli Państwa kod i pipeline'y są w GitLab i chcą Państwo jednej platformy albo potrzebują SAST, DAST i wykrywania sekretów w tym samym produkcie.
• Warto wybrać CRACI, jeśli Państwa kod jest w GitHub, używają Państwo GitHub Actions i potrzebują dowodów na to, co trafiło do każdego wydania, kontroli nad tym, do czego mogą docierać buildy, oraz SBOM-ów, za które mogą Państwo ręczyć podczas audytu.
• Warto używać obu, jeśli Państwa organizacja korzysta z obu platform. GitLab nadal obejmuje swoje projekty i skanery, a CRACI obsługuje stronę GitHub Actions i rejestruje te buildy.

Na potrzeby Cyber Resilience Act

Zgodnie z unijnym Cyber Resilience Act producenci muszą wiedzieć, co jest w każdym wydaniu produktu, i obsługiwać jego podatności. Obowiązki zgłaszania podatności mają zastosowanie od września 2026, a rozporządzenie stosuje się w pełni od grudnia 2027. GitLab Ultimate pomaga znajdować podatności w Państwa projektach i nimi zarządzać. CRACI rejestruje, z czego zbudowano każde wydanie, nadal je monitoruje i eksportuje SBOM-y w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA. Żadne z tych narzędzi samo nie zapewnia zgodności.

Dodanie CRACI

W przypadku repozytorium w GitHub wystarczy zainstalować aplikację CRACI GitHub App w organizacji, dla wszystkich repozytoriów lub wybranego zestawu, i zmienić etykietę runnera:

runs-on: craci

Workflow, akcje i interfejs GitHub pozostają bez zmian. CRACI zastępuje runner, a nie GitHub Actions. Więcej o generowaniu SBOM w czasie buildu i dowodach dla CRA, a także o cenach.