O 123% więcej zgłoszonych CVE dziennie w 2026 niż przed rokiem.

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

Strona główna Sonatype
sonatype.com

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