CRACI vs CircleCI

Krótka odpowiedź

CircleCI to dojrzała, elastyczna platforma CI/CD. Łączy się z GitHub, GitLab i Bitbucket, uruchamia zadania na szerokiej gamie maszyn, od kontenerów Docker po macOS i GPU, i pozwala pakować konfigurację wielokrotnego użytku jako orby. W kwestii bezpieczeństwa CircleCI chroni poświadczenia, a skanowanie pozostawia orbom i narzędziom zewnętrznym.

CRACI stosuje odwrotne podejście: to runner jest zapisem bezpieczeństwa. Uruchamia zadania GitHub Actions, obserwuje każdą zależność zewnętrzną pobieraną przez każdy build, egzekwuje politykę ruchu wychodzącego w sieci buildu i na podstawie tego, co zobaczył, tworzy SBOM-y, dane o pochodzeniu i dowody dla CRA. Na tym polega różnica między tradycyjnym CI a CI świadomym bezpieczeństwa.

CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. CircleCI nie jest jeszcze obsługiwany. Zespoły korzystające z CircleCI musiałyby przenieść pipeline do GitHub Actions, aby używać runnerów CRACI, albo poczekać na inne systemy CI, które są w planach rozwoju.

Co CircleCI robi dobrze

Szeroki wybór mocy obliczeniowej. CircleCI oferuje klasy zasobów Docker, Linux VM, Arm, Windows, macOS i GPU, więc jedna platforma może zbudować backend, klienta Windows i aplikację na iOS. Runnery self-hosted rozszerzają to na Państwa własne maszyny z Linuxem, Windows i macOS oraz na Kubernetes, a czas zadań na runnerach nie zużywa kredytów.

Funkcje przyspieszające. Cache warstw Dockera jest dostępny we wszystkich planach. Podział testów rozkłada zestaw na równoległe executory według nazwy, rozmiaru pliku lub historycznych danych o czasie, co skraca czas rzeczywisty dużych zestawów testów.

Konfiguracja wielokrotnego użytku. Orby pakują zadania, polecenia i executory, dzięki czemu zespoły mogą ich używać w wielu projektach, i ułatwiają podłączanie narzędzi zewnętrznych, w tym skanerów bezpieczeństwa.

Higiena poświadczeń. Wytyczne CircleCI dotyczące łańcucha dostaw koncentrują się na ochronie sekretów: dzieleniu ich na konteksty, umieszczaniu kluczy wdrożeniowych i podpisujących w kontekstach ograniczonych, zarządzanych przez grupy w Państwa VCS, oraz używaniu tokenów OIDC, aby zadania łączyły się z usługami chmurowymi bez długotrwałych poświadczeń przechowywanych w CircleCI.

Czym różni się CRACI

Build jest źródłem prawdy

Na tradycyjnej platformie CI SBOM tworzy narzędzie dodane do pipeline'u, które zwykle odczytuje manifesty i lockfile. CRACI zamiast tego obserwuje build. Proxy rozpoznające pakiety rejestruje podczas działania zadania ruch do źródeł pakietów: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presetów pobierania. Dowody zależności są przenoszone razem z cache CI, więc pakiet przywrócony z cache nadal jest uwzględniany.

Wiedzą Państwo, jak kompletny jest SBOM

Każde zadanie tworzy SBOM CycloneDX lub SPDX ze stanem kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.

Sieć buildu ma politykę

Funkcja zakresów IP w CircleCI kieruje zadania przez znane adresy CircleCI, aby Państwa własne systemy mogły dodać je do listy dozwolonych. To rozwiązuje kwestię dostępu przychodzącego. CRACI dodaje kontrolę w drugim kierunku: polityki ruchu wychodzącego dla każdego zadania, w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania, typowanymi źródłami niestandardowymi i jawnymi regułami TLS, TCP, UDP i ICMP. Polityki są weryfikowane przed startem zadania, a w razie błędu blokują ruch. CRACI zapewnia też stabilny zakres adresów IP ruchu wychodzącego.

Pochodzenie i monitorowanie z tego samego zapisu

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI agreguje podatności z różnych buildów i repozytoriów oraz nadal ponownie ocenia monitorowane SBOM-y.

Co wybrać

• Warto pozostać przy CircleCI, jeśli Państwa kod jest w GitLab lub Bitbucket, jeśli zależą Państwo od buildów Windows, macOS lub GPU albo uruchamiają Państwo zadania na własnym sprzęcie.
• Warto rozważyć CRACI, jeśli Państwa kod jest w GitHub, rozważają Państwo GitHub Actions zamiast CircleCI i dostarczają Państwo oprogramowanie, przy którym trzeba wykazać, co trafiło do każdego wydania.
• Warto używać obu podczas stopniowej migracji: pipeline'y macOS i Windows pozostawić w CircleCI, a workflow GitHub Actions dla Linuxa uruchamiać na CRACI tam, gdzie dowody z buildu są najważniejsze.

Na potrzeby Cyber Resilience Act

Unijny Cyber Resilience Act oczekuje 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 i pełnym stosowaniem od grudnia 2027. W CircleCI te dowody pochodzą z tych skanerów i orbów, które podłączą Państwo do swoich pipeline'ów. CRACI wytwarza je z zapisu buildu i eksportuje SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA.

Przeniesienie pipeline'u do CRACI

CRACI uruchamia workflow GitHub Actions, więc pipeline CircleCI potrzebuje najpierw odpowiednika w GitHub Actions. Gdy już go ma, wystarczy zainstalować aplikację CRACI GitHub App w organizacji i ustawić etykietę runnera:

runs-on: craci

Uruchomienia nadal są widoczne w interfejsie GitHub. Zadania mają do dyspozycji Docker Engine, Buildx i Compose v2, runnery o rozmiarach od 1 do 32 vCPU z 3 GB RAM na każdy oraz obsługę cache GitHub Actions. Więcej o generowaniu SBOM w czasie buildu, a także o cenach i programie dla startupów.