CRACI vs OX Security

Krótka odpowiedź

OX Security to platforma zarządzania stanem bezpieczeństwa aplikacji (ASPM) z własnymi skanerami (SAST, SCA, sekrety, IaC i kontenery), agregacją znalezisk z narzędzi zewnętrznych, politykami stanu bezpieczeństwa CI/CD oraz kontekstem runtime i chmury. W zakresie bezpieczeństwa łańcucha dostaw oferuje Pipeline Bill of Materials (PBOM): podpisany zapis tego, jak zbudowano każdy artefakt, od commita przez CI/CD po produkcję.

CRACI konkuruje o ten sam budżet na łańcuch dostaw. Różnica tkwi w punkcie obserwacji. OX łączy się z używanymi już przez Państwa systemami kontroli wersji, CI i rejestrami i na ich podstawie buduje obraz. CRACI to runner buildów dla GitHub Actions: rejestruje, co każde zadanie faktycznie pobrało, egzekwuje politykę ruchu wychodzącego podczas działania, monitoruje to, co dostarczono, i wytwarza dowody dla CRA. OX jest znacznie szerszy; CRACI jest samym buildem.

W skrócie

Co OX Security robi dobrze

• Zapis buildu wykraczający poza SBOM. PBOM firmy OX obejmuje definicje pipeline'ów, tożsamość runnera, argumenty buildu, podpisy artefaktów i historię wersji, a OX podaje, że zawiera każdy komponent open source rozwiązany w każdym buildzie. Jest podpisywany dla każdego buildu. OX generuje też SBOM-y w formatach SPDX i CycloneDX.
• Stan bezpieczeństwa CI/CD. Polityki OX oznaczają niebezpieczne pliki workflow, nieprzypięte akcje zewnętrzne, przestarzałe polecenia GitHub Actions, nadmierne uprawnienia workflow, sekrety w postaci jawnego tekstu i ryzykowne webhooki, a także mogą oznaczać systemy CI niezatwierdzone do buildów.
• Egzekwowanie w pipeline'ie. GitHub Action OX Security Scan uruchamia skany sekretów, SAST, SCA i IaC oraz przerywa workflow, gdy znajdzie problem blokujący według Państwa polityk OX.
• Agregacja. OX pobiera znaleziska ze skanerów takich jak Checkmarx, Veracode, SonarQube, Snyk, Black Duck i JFrog Xray, obok własnych.
• Szeroki zakres integracji. Po stronie CI wymienia GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines, CircleCI i Drone CI, a także osiem systemów kontroli wersji i dziesięć rejestrów kontenerów.
• Funkcje na erę AI. OX VibeSec obejmuje kod i zależności generowane przez AI za pomocą AI Bill of Materials, a naprawa AI sugeruje poprawki kodu w pull requestach i IDE.

Czym różni się CRACI

Rejestrowane przez runner, a nie zbierane z połączonych narzędzi

Dokumentacja OX podaje, że jego SBOM zbiera dane z połączonych źródeł, w tym z kontroli wersji, pipeline'ów CI/CD, obrazów kontenerów i importowanych plików. Daje to szeroki widok całego środowiska. CRACI przyjmuje węższe i głębsze spojrzenie na każdy build: proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów podczas działania zadania, obejmując npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródła Git, a także presety pobierania. Dowody zależności przemieszczają się razem z cache CI, więc pakiet przywrócony z cache nadal jest uwzględniany.

Każdy SBOM CRACI zawiera stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Gdy zapis ma lukę, mówi o tym wprost.

Kontrola podczas działania buildu

Polityki stanu bezpieczeństwa OX sprawdzają, jak skonfigurowany jest pipeline. CRACI ogranicza, do czego build może dotrzeć. Polityki ruchu wychodzącego działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania, typowanymi źródłami niestandardowymi dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git oraz jawnymi regułami TLS, TCP, UDP i ICMP. Polityki są walidowane przed uruchomieniem zadania, w razie błędu blokują ruch, a CRACI może powiadomić Państwa o naruszeniu.

Pochodzenie i monitorowanie z jednego zapisu

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu i nie deklaruje żadnego poziomu SLSA. Stale ponownie ocenia SBOM-y tego, co Państwo dostarczyli, w miarę publikowania nowych podatności.

Inwentarz tego, co gdzie jest wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawi się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast odtwarzać to z informacji o wydaniach i arkuszy kalkulacyjnych.

W czym OX jest lepszy

Mówiąc wprost: CRACI nie ma skanowania SAST, sekretów, IaC ani kontenerów, kontroli stanu bezpieczeństwa CI/CD, agregacji zewnętrznych skanerów ani kontekstu runtime i chmury. Bramki polityk CRACI mogą zablokować build z powodu znalezisk, ale CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. Jeśli potrzebują Państwo jednej platformy obejmującej każdy używany pipeline i skaner, OX obejmuje znacznie więcej.

Które rozwiązanie wybrać

OX Security sprawdzi się lepiej, gdy

• Chcą Państwo jednej platformy ASPM, która agreguje wiele skanerów i priorytetyzuje znaleziska z nich wszystkich.
• Potrzebują Państwo polityk stanu bezpieczeństwa CI/CD dla GitLab, Jenkins, Azure Pipelines lub CircleCI.
• Chcą Państwo już dziś bramek pull requestów dla znalezisk w kodzie, sekretach i IaC.

CRACI sprawdzi się lepiej, gdy

• Budują Państwo w GitHub Actions i chcą mieć runner, politykę ruchu wychodzącego i zapis zależności w jednym miejscu.
• Potrzebują Państwo SBOM tego, co pobrał każdy build, ze stanem kompletności, który można pokazać audytorowi.
• Chcą Państwo monitorowania tego, co dostarczono, i dowodów dla CRA z tego samego zapisu.

Korzystanie z obu

CRACI zastępuje runner, a nie GitHub Actions, więc akcja OX Security Scan działa na runnerze CRACI jak każdy inny krok. OX może importować SBOM-y w formacie CycloneDX, więc CRACI może dostarczyć SBOM zarejestrowany z buildu jako podstawę pracy OX.

Na potrzeby Cyber Resilience Act

Cyber Resilience Act wymaga od producentów znajomości komponentów każdego produktu, obsługi ich podatności i przechowywania dowodów. SBOM-y, PBOM i polityki stanu bezpieczeństwa OX wspierają bezpieczne wytwarzanie i inwentarz całego środowiska. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA: SBOM-y z czasu buildu eksportowane w formacie CycloneDX lub SPDX, śledzenie podatności i dane o pochodzeniu przez API. Żadne z tych narzędzi samo w sobie nie zapewnia zgodności. Zob. dowody dla CRA oraz zgodność z CRA.

Dodanie CRACI

Proszę zainstalować aplikację CRACI GitHub App w swojej organizacji, a następnie zmienić etykietę runnera w zadaniu na runs-on: craci. Uruchomienia nadal są widoczne w interfejsie GitHub. Warto zacząć od jednego workflow wytwarzającego artefakt wydania i porównać SBOM z CRACI z tym, który OX pokazuje dla tego samego repozytorium. Więcej o integracji CI/CD, generowaniu SBOM w czasie buildu i cenach.

Rozważają Państwo więcej niż dwa narzędzia? Alternatywy dla OX Security porównują dziewięć opcji obok siebie.