Porównanie
CRACI vs Sonatype
Sonatype decyduje, które komponenty open source mogą trafić do Państwa repozytoriów, i oznacza ryzyko w tym, co znajdzie się w Państwa aplikacjach. CRACI uruchamia build i rejestruje, co faktycznie pobrał. Odpowiadają na różne pytania i dobrze ze sobą współpracują.
Zaktualizowano
Krótka odpowiedź
Sonatype najlepiej sprawdza się w zarządzaniu open source: polityki decydują o dozwolonych komponentach, firewall zatrzymuje złe pakiety na poziomie repozytorium, a analiza pokazuje, co znalazło się w Państwa aplikacji. CRACI to runner CI zgodny z GitHub Actions, który rejestruje każdą zewnętrzną zależność pobraną przez build i na podstawie tego zapisu tworzy SBOM, dane o pochodzeniu i dowody zgodności. Sonatype jest skanerem i strażnikiem. CRACI jest rejestratorem, którego bramki polityk mogą też zablokować build z powodu znalezisk. Większość zespołów potrzebujących obu uruchamiałaby je obok siebie.
Co jest czym w ofercie Sonatype
Sonatype sprzedaje kilka produktów, a ich nazwy mają w tym porównaniu znaczenie:
- Sonatype Lifecycle to produkt do analizy składu oprogramowania (SCA) i polityk, działający w modelu self-hosted lub SaaS.
- Sonatype Repository Firewall blokuje i poddaje kwarantannie komponenty niespełniające Państwa polityk, zanim trafią do repozytoriów. Jest przeznaczony dla Sonatype Nexus Repository. Sonatype Firewall Pro obejmuje inne menedżery repozytoriów, takie jak JFrog Artifactory, Cloudsmith i GitHub Packages, dla npm, Maven, PyPI i NuGet.
- Sonatype SBOM Manager importuje, monitoruje i udostępnia SBOM-y, z workflow VEX.
Pakietowanie oferty się zmienia. Cennik Sonatype podaje, że wszystkie funkcje Lifecycle są teraz częścią Sonatype Guide, że nowi klienci kupują Guide do SCA i zarządzania oraz że Guide obejmuje też funkcje zgodności SBOM Manager.
W skrócie
| Funkcja | CRACI | Sonatype |
|---|---|---|
| Obserwuje zależności podczas działania buildu | Proxy rozpoznające pakiety na runnerze | Skanuje wynik buildu, lockfile i manifesty |
| SBOM z czasu buildu ze stanem kompletności | Pięć stanów, dla każdego zadania i cache | CycloneDX lub SPDX z każdego skanu |
| Polityka ruchu wychodzącego dla zadań buildu | Domyślna odmowa lub zezwolenie, blokuje w razie awarii | Nie uruchamia Państwa buildów |
| Blokuje złośliwe pakiety przed pobraniem | Dziś tylko polityka ruchu wychodzącego na poziomie źródeł | Repository Firewall i Firewall Pro |
| Monitorowanie dostarczonych SBOM-ów | Monitorowane SBOM-y są stale ponownie oceniane | SBOM Manager monitoruje importowane SBOM-y |
| Polityka licencyjna | Reguły polityki licencyjnej, w tym blokowanie buildu z powodu licencji | Polityki obejmujące ponad 2000 licencji |
| Priorytetyzacja według osiągalności | Dane o osiągalności i aktualizacjach w Lifecycle | |
| Uruchamia Państwa zadania CI | Zadania działają na runnerach CRACI | Podłącza się do istniejącego CI |
| Obsługiwane systemy CI | Dziś GitHub Actions; GitLab CI i Jenkins w planach rozwoju | Jenkins, GitHub Actions, GitLab, Azure DevOps, Bamboo |
| Ceny | $0.002 za minutę vCPU ($0.004 za 2 vCPU), naliczane co sekundę; bez opłaty miesięcznej i bez opłat za SBOM | Nowi klienci kupują Sonatype Guide (Enterprise według wyceny). Firewall Pro od $4,800 rocznie. Stan na wrzesień 2026. |
- W zestawie
- Częściowo
- Brak
- W planach rozwoju
Co Sonatype robi dobrze
Polityki na dużą skalę. Lifecycle zawiera 18 domyślnych polityk i ponad 30 konfigurowalnych ograniczeń obejmujących reguły bezpieczeństwa, prawne i architektoniczne. Polityki licencyjne obejmują ponad 2000 licencji open source. Priorytetyzuje znaleziska na podstawie danych o osiągalności, zmianach łamiących zgodność i dostępności aktualizacji, a także może otwierać Golden Pull Requests z sugerowanymi aktualizacjami.
Analiza tego, co wytworzył build. Integracje Lifecycle domyślnie używają Advanced Binary Fingerprinting, które bada wszystko, co zawiera aplikacja po buildzie, łącznie z osadzonymi zależnościami, i potrafi rozpoznać komponenty przemianowane lub zmodyfikowane. Dopiero potem sięga po lockfile i manifesty. Każdy raport ze skanu można wyeksportować jako SBOM CycloneDX lub SPDX.
Zatrzymywanie złych pakietów na wejściu. Repository Firewall egzekwuje Państwa standardy bezpieczeństwa, licencji i jakości w momencie pobierania i poddaje kwarantannie podejrzane komponenty. CRACI nie ma dziś odpowiednika: listy blokowanych pakietów są w jego planach rozwoju.
Pasuje do każdego pipeline'u. Sonatype integruje się z Jenkins, GitHub Actions, GitLab CI, Azure DevOps i Bamboo, a także z Maven, Gradle i CLI dla innych serwerów CI. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju.
Czym różni się CRACI
Rejestruje build, zamiast analizować jego wynik
Binary fingerprinting mówi, co jest w gotowej aplikacji. Nie mówi, co build pobrał po drodze: kompilatory i łańcuchy narzędzi, skrypty instalacyjne, obrazy bazowe, pliki binarne wydań pobierane przez curl czy pakiety przywrócone z cache. CRACI to widzi, ponieważ jest runnerem. 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 źródeł lub pobierania. Dowody zależności przemieszczają się razem z cache CI, więc pakiety 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. Gdy zapis ma lukę, wiedzą Państwo o tym.
Kontroluje, dokąd build może dotrzeć
Repository Firewall zarządza tym, co przechodzi przez repozytorium. Polityka ruchu wychodzącego CRACI zarządza tym, do czego build w ogóle 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 dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git. Są walidowane przed uruchomieniem zadania i w razie awarii blokują ruch. Razem pozwalają zapewnić, że zadania buildu pobierają pakiety tylko z zatwierdzonych źródeł, a te źródła udostępniają tylko dozwolone pakiety.
Nadal obserwuje to, co dostarczono
API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu. CRACI agreguje podatności z wielu buildów i repozytoriów oraz stale ponownie ocenia monitorowane SBOM-y.
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.
Kiedy używać obu
- Używają już Państwo Nexus Repository z Firewall. Niech pozostanie bramką. Warto dodać CRACI, aby każdy build miał zapis tego, co pobrał, oraz politykę ruchu wychodzącego utrzymującą buildy przy zatwierdzonych źródłach.
- Państwa dział prawny polega na politykach licencyjnych Lifecycle. Mogą pozostać. CRACI zawiera metadane deklarowanych licencji w eksporcie SBOM i także egzekwuje politykę licencyjną.
- Zbierają Państwo SBOM-y w SBOM Manager. SBOM Manager importuje CycloneDX i SPDX, te same formaty, które eksportuje CRACI, więc SBOM-y z czasu buildu mogą znaleźć się obok już zarządzanych.
- Państwa pipeline'y działają na Jenkins lub Azure DevOps. Sonatype sprawdzi się już dziś. CRACI wymagałby najpierw przeniesienia tych pipeline'ów na GitHub Actions; Jenkins jest w jego planach rozwoju.
Na potrzeby Cyber Resilience Act
Sonatype publikuje przewodnik użytkownika CRA i listę kontrolną CRA oraz pozycjonuje SBOM Manager jako swój produkt dla CRA. Jego przewodnik podkreśla generowanie plików VEX do raportowania znanych podatności w SBOM-ach oraz Nexus Repository jako witrynę aktualizacji do dystrybucji aktualizacji bezpieczeństwa.
CRACI obejmuje stronę dowodową z poziomu buildu: SBOM dla każdego wydania z określoną kompletnością, dane o pochodzeniu, ciągłe monitorowanie podatności i eksport SBOM 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 w sobie nie zapewnia zgodności produktu. Zob. zgodność z CRA oraz czym jest CRA.
Dodanie CRACI obok Sonatype
CRACI zastępuje runner, a nie GitHub Actions. Wystarczy zmienić runs-on na craci w workflow, a
uruchomienia nadal są widoczne w interfejsie GitHub. Kroki Sonatype pozostają w workflow. Warto zacząć od jednego pipeline'u
wydań, porównać SBOM z CRACI z raportem Lifecycle i sprawdzić, co zobaczyło tylko jedno z nich.
CRACI obsługuje dziś GitHub Actions. GitLab CI, Jenkins i inne systemy CI są w planach rozwoju. Więcej o generowaniu SBOM w czasie buildu i śledzeniu podatności.
Proszę uruchomić prawdziwy build i porównać
Proszę skierować jeden workflow GitHub Actions na CRACI i porównać jego SBOM z tym, który tworzą Państwa obecne narzędzia.
Umów demo