CRACI vs Harness

Krótka odpowiedź

Harness, założony w 2017 roku z siedzibą w San Francisco, sprzedaje platformę do wszystkiego, co następuje po napisaniu kodu: ciągłej integracji, ciągłego dostarczania, flag funkcji, zarządzania kosztami chmury, inżynierii chaosu i testów bezpieczeństwa. Jego moduł Supply Chain Security (SCS) dodaje generowanie SBOM, pochodzenie SLSA, bramki polityk OPA oraz kontrole stanu repozytoriów i pipeline'ów. Jeśli chcą Państwo jednego dostawcy dla całego pipeline'u dostarczania, u kilku dostawców Git, Harness powstał właśnie z myślą o tym.

CRACI ma węższy zakres i sięga głębiej w build. To runner GitHub Actions: podczas działania każdego zadania rejestruje każdą zewnętrzną zależność pobieraną przez build, egzekwuje politykę ruchu wychodzącego w sieci buildu i na podstawie tego zapisu tworzy SBOM-y, dane o pochodzeniu i monitorowanie podatności. Harness dodaje do pipeline'u kroki związane z łańcuchem dostaw; CRACI czyni zapisem bezpieczeństwa sam runner.

Najpierw jedna kwestia praktyczna. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. Pipeline'y Harness CI musiałyby przejść na GitHub Actions, aby działać na CRACI.

W skrócie

Co Harness robi dobrze

Jedna platforma do dostarczania. Harness obejmuje CI, CD, GitOps, flagi funkcji, infrastrukturę jako kod, inżynierię chaosu i zarządzanie kosztami chmury, z egzekwowaniem polityk opartym na OPA. Współpracuje z GitHub, GitLab, Bitbucket, Azure Repos i własnymi repozytoriami Harness Code oraz podaje, że obsługuje ponad 1000 klientów korporacyjnych i zatrudnia ponad 1200 osób.

Wybór infrastruktury buildów. Harness Cloud uruchamia buildy na zarządzanych przez Harness maszynach Linux, Windows i macOS: Linux AMD64 od 2 do 96 rdzeni, ARM64 od 2 do 64 rdzeni w tej samej stawce oraz macOS na Apple M4. Na Linux AMD64 dostępna jest zagnieżdżona wirtualizacja. Buildy można też uruchamiać na własnych klastrach Kubernetes, maszynach wirtualnych lub bare metal. Test Intelligence uruchamia tylko testy, których dotyczy zmiana, a Build Intelligence i funkcje cache ponownie wykorzystują niezmienione wyniki i zależności.

Funkcje łańcucha dostaw w pipeline'ie. Krok SBOM Orchestration modułu SCS generuje SBOM dla obrazu kontenera lub repozytorium kodu przy użyciu Syft lub cdxgen, w formacie SPDX lub CycloneDX, i może przyjmować SBOM-y z innych narzędzi. Harness podaje, że generuje i aktualizuje SBOM-y przy każdym buildzie. Polityki OPA mogą blokować buildy i wdrożenia z powodu komponentów, licencji lub pochodzenia, a moduł śledzenia napraw śledzi podatne artefakty.

Pochodzenie SLSA. Harness dokumentuje SLSA Build Level 1, 2 i 3 w ramach SLSA v1.0, z pochodzeniem podpisywanym przez atestacje in-toto i cosign. Jego dokumentacja podaje, że Level 3 wymaga utwardzonej infrastruktury buildów lub Harness Cloud, który izoluje procesy buildu od siebie.

Kontrole stanu i pipeline'ów. SCS audytuje repozytoria i pipeline'y pod kątem OWASP Top 10 CI/CD Security Risks i benchmarków CIS oraz oznacza nieprzypięte, niezweryfikowane i nadmiernie uprzywilejowane GitHub Actions. Harness oferuje też swoje kroki SCS jako GitHub Actions i komponenty GitLab CI/CD, więc moduł nie jest związany z Harness CI; te kroki wymagają konta Harness z licencją SCS.

Czym różni się CRACI

SBOM pochodzi z buildu, a nie ze skanu jego wyniku

Syft i cdxgen to skanery: odczytują obraz lub repozytorium po fakcie i wnioskują o zawartości z lockfile, manifestów i baz pakietów. Sprawdza się to, gdy te pliki mówią wszystko. Buildy często robią więcej: skrypty instalacyjne pobierają kod, skrypty buildu Rust pobierają zasoby w czasie buildu, a cache przywracają pakiety, o których nie wspomina żaden lockfile.

CRACI widzi ten ruch, ponieważ jest runnerem. Proxy rozpoznające pakiety rejestruje, co każde zadanie pobiera ze źródeł pakietów: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presetów pobierania, a dowody zależności przemieszczają się razem z cache CI. Rejestruje ukryte zależności, które pomijają narzędzia oparte na lockfile, a każdy SBOM określa swoją kompletność dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.

Polityka dla sieci buildu, a nie wykrywanie po fakcie

Harness podaje, że jego moduł wykrywa nietypowe zachowanie runnerów CI, w tym połączenia sieciowe i eskalację uprawnień. CRACI obiera inną drogę: polityka ruchu wychodzącego na runnerze decyduje, do których hostów zadanie może dotrzeć. Polityki działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania i typowanymi źródłami niestandardowymi, są walidowane przed startem zadania i w razie błędu blokują ruch. Ponieważ polityka domyślnej odmowy zezwala tylko na to, czego potrzebuje build, zamiast szukać znanych złośliwych hostów, blokuje wyprowadzanie danych na serwer napastnika nawet przy ataku, którego nikt wcześniej nie widział. Naruszenia wysyłają alert.

Pochodzenie i monitorowanie z tego samego zapisu

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu i nie deklaruje żadnego poziomu SLSA; Harness podpisuje swoje dane o pochodzeniu i dokumentuje poziomy od 1 do 3, a jeśli podpisane pochodzenie lub poziom SLSA są wymogiem zakupowym, przemawia to za Harness. CRACI agreguje podatności z wielu buildów i repozytoriów, nadal ponownie ocenia monitorowane SBOM-y w miarę pojawiania się biuletynów i pokazuje, które wcześniejsze buildy zawierały podatną zależność, dzięki czemu wiedzą Państwo, w jakim okresie byli narażeni.

Cennik, który można przeczytać

CRACI pobiera opłaty tylko za minuty buildu: $0.002 za minutę vCPU ($0.004 za domyślny runner 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej i bez opłat za SBOM. Harness publikuje stawki Harness Cloud, $0.005 za minutę za 2-rdzeniową maszynę Linux z 7 GB i $0.080 za 32 rdzenie, rozliczane do najbliższej minuty, natomiast jego płatne plany i moduł SCS są wyceniane przez dział sprzedaży. Cena katalogowa CRACI jest o 20% niższa za minutę przy obu rozmiarach ($0.004 wobec $0.005, $0.064 wobec $0.080); maszyny Harness mają więcej pamięci na rdzeń.

Co wybrać

• Warto pozostać przy Harness, jeśli chcą Państwo CI, CD, flag funkcji i zarządzania kosztami od jednego dostawcy, jeśli Państwa kod jest w GitLab, Bitbucket lub Azure Repos, jeśli potrzebują Państwo Windows, macOS lub własnego sprzętu do buildów albo jeśli wymogiem jest udokumentowany SLSA Build Level 3.
• Warto wybrać CRACI, jeśli Państwa kod jest w GitHub, używają Państwo GitHub Actions lub planują ich używać i chcą, aby SBOM, polityka sieciowa i dane o pochodzeniu pochodziły z runnera, który wykonał build, a rozliczenie odbywało się za minutę buildu.

Warto jasno określić, z czego rezygnują Państwo, wybierając CRACI. Nie wdraża oprogramowania, nie obsługuje flag funkcji ani nie zarządza kosztami chmury, nie sprawdza repozytoriów i pipeline'ów pod kątem benchmarków stanu bezpieczeństwa ani nie skanuje kodu źródłowego. Dziś uruchamia tylko zadania Linux, a Windows i macOS są w planach rozwoju, podobnie jak runnery hostowane u klienta dla Enterprise.

Dla produktów regulowanych

Frameworki takie jak unijny Cyber Resilience Act oczekują od producentów, że będą wiedzieć, co jest w każdym wydaniu, i obsługiwać jego podatności, z obowiązkami raportowania od września 2026. Harness dostarcza SBOM-y, dane o pochodzeniu i wyniki polityk z kroków swojego pipeline'u. CRACI wytwarza dowody z zapisu buildu i eksportuje SBOM-y w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmie w szerszym procesie CRA; żadne z tych narzędzi samo nie zapewnia zgodności produktu.

Przeniesienie pipeline'u do CRACI

CRACI zastępuje runner, a nie GitHub Actions, a uruchomienia nadal są widoczne w interfejsie GitHub. Gdy pipeline działa już jako workflow GitHub Actions, uruchomi się na CRACI po zmianie jednej linii:

runs-on: craci

Więcej o generowaniu SBOM w czasie buildu, a także porównanie platform CI/CD, alternatywy dla Harness i ceny.