CRACI vs Aikido

Konsolidacja a dowody

Zespoły zwykle sięgają po Aikido, bo chcą mieć mniej narzędzi bezpieczeństwa. Aikido obejmuje zależności open source, własny kod, sekrety, infrastrukturę jako kod, kontenery, konfigurację chmury, testy dynamiczne i ochronę w czasie działania w jednym produkcie, z jednym miejscem do triażu znalezisk. Dla małego zespołu, który szybko potrzebuje szerokiego pokrycia, to mocna oferta.

Po CRACI zespoły sięgają z węższego powodu. Muszą wiedzieć, co faktycznie robiły ich buildy, kontrolować, dokąd build może się połączyć, i tworzyć dowody dla każdego wydania, które obronią się przed klientem lub audytorem. CRACI osiąga to, będąc samym runnerem CI.

Co Aikido robi dobrze

Główny atut to zakres. Każdy plan Aikido obejmuje SCA, SAST, wykrywanie sekretów, IaC, konfigurację chmury, skanowanie kontenerów, DAST, skanowanie licencji i generowanie SBOM. Jego SCA wykorzystuje analizę osiągalności na poziomie funkcji, by ograniczyć szum, a AutoFix otwiera pull requesty z poprawionymi wersjami. W CI Aikido może blokować pull requesty z krytycznym ryzykiem i współpracuje z GitHub, GitLab, Jenkins, Bitbucket, CircleCI i innymi. CRACI obsługuje dziś wyłącznie GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju.

Aikido oferuje też Safe Chain, bezpłatne narzędzie, które uruchamia lokalne proxy przed menedżerami pakietów npm i PyPI i blokuje pakiety ze znanym złośliwym oprogramowaniem, zanim zostaną zainstalowane, lokalnie i w CI. CRACI nie blokuje dziś pojedynczych pakietów. Blokowanie pakietów na poziomie całej organizacji jest w planach rozwoju CRACI, a nie w produkcie.

W zakresie zgodności wyższe plany Aikido obejmują raporty zgodności SOC 2 i ISO 27001 oraz synchronizację z platformami compliance, takimi jak Drata i Vanta. Jeśli głównym celem jest zasilanie programu SOC 2 znaleziskami z bezpieczeństwa aplikacji, Aikido jest do tego stworzone.

Czym różni się CRACI

CRACI to środowisko uruchomieniowe CI

Ochrona w czasie działania w Aikido zabezpiecza działające aplikacje. CRACI działa w innym środowisku: w zadaniu buildu. Państwa zadania GitHub Actions wykonują się na CRACI w izolowanych maszynach wirtualnych, na runnerach od 1 do 32 jednostek obliczeniowych, na x86-64 lub ARM64. Konfiguracja polega na zmianie runs-on na craci. Workflow pozostają bez zmian, a uruchomienia nadal widać w interfejsie GitHub.

Ponieważ CRACI uruchamia zadanie, może egzekwować politykę ruchu wychodzącego w trakcie jego działania. 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 dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git. Są weryfikowane przed startem zadania, a w razie błędu blokują ruch. Skaner może powiedzieć, że istnieje ryzykowny pakiet. Polityka sieciowa nie pozwala buildowi połączyć się tam, dokąd nie powinien.

Deterministyczne dowody z buildu

Aikido tworzy obraz zależności na podstawie manifestów i lockfile, a następnie dodaje analizę, w tym kontrole podatności na wykorzystanie oparte na AI. To rozsądny sposób ustalania priorytetów.

SBOM w CRACI nie jest wnioskowany. Proxy rozpoznające pakiety rejestruje, co zadanie pobrało ze źródeł pakietów, a dowody zależności są przenoszone razem z cache CI, więc pakiety przywrócone z cache nadal są uwzględniane. Każdy SBOM określa własną kompletność dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. To zapis tego, co się wydarzyło, a nie szacunek, i wskazuje, gdzie ma luki.

Ma to znaczenie, bo statyczne narzędzia SBOM różnią się od siebie bardziej, niż większość osób się spodziewa, a przyczyna jest strukturalna. Każde z nich czyta inny zestaw plików i rozwiązuje je inaczej, więc to, co według nich zawiera repozytorium, zależy od tego, które narzędzie zapytano i jak je skonfigurowano. Projekt, który nie zawiera lockfile, jak express 5.2.1, nie daje czytnikowi lockfile niczego do rozwiązania. CRACI nie da się porównać na tych zasadach, ponieważ rejestruje buildy, a nie skanuje katalogów, i właśnie o to chodzi: zapis buildu nie zależy od tego, jakie pliki akurat są obecne.

Dane o pochodzeniu przez API

CRACI generuje SBOM wewnątrz własnego runnera, na podstawie tego, co pobrało zadanie. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Zgodność oparta na tym zapisie

W przypadku unijnego Cyber Resilience Act najtrudniej jest wykazać, co trafiło do każdego wydania i jak śledzi się jego podatności w czasie. CRACI agreguje podatności z wielu buildów i repozytoriów oraz na bieżąco ponownie ocenia monitorowane SBOM-y. SBOM-y eksportuje się w formatach CycloneDX lub SPDX, łącznie z podatnościami, a API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA. Zob. zgodność z CRA oraz dowody dla CRA.

Inwentarz tego, co gdzie jest wdrożone

Widok inwentarza w CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, globalnie. Gdy pojawia się nowa podatność, widzą Państwo, które produkty korzystają z podatnej wersji, zamiast składać tę wiedzę z informacji o wydaniach i arkuszy kalkulacyjnych.

Kiedy sprawdza się każde z nich

• Proszę wybrać Aikido, gdy potrzebują Państwo jednego narzędzia obejmującego kod, zależności, chmurę i działające aplikacje, korzystają dziś z systemów CI innych niż GitHub Actions lub koncentrują się na raportowaniu SOC 2 albo ISO 27001 na podstawie znalezisk z bezpieczeństwa aplikacji.
• Proszę wybrać CRACI, gdy budują Państwo na GitHub Actions i muszą dokładnie wiedzieć, co pobrał każdy build, kontrolować dostęp buildu do sieci i przechowywać dowody wydań na potrzeby CRA i audytów klientów.
• Proszę używać obu, gdy chcą Państwo mieć skanowanie i bramkowanie pull requestów z Aikido oraz kontrolę środowiska buildu i dowody z CRACI. Kontrole CI i Safe Chain z Aikido działają jako kroki workflow, a te kroki mogą działać na runnerze CRACI jak każde inne.