CRACI vs Black Duck

Krótka odpowiedź

Black Duck to szerokie portfolio bezpieczeństwa aplikacji zbudowane wokół produktu do analizy składu oprogramowania (SCA), uzupełnione o analizę statyczną, analizę plików binarnych, fuzzing i zarządzanie stanem bezpieczeństwa. 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. Black Duck to skaner, i to dokładny. CRACI to rejestrator. Dla większości producentów oba rozwiązania się uzupełniają.

W skrócie

Co Black Duck robi dobrze

Wykrywanie open source, którego nikt nie zadeklarował. Black Duck SCA łączy skanowanie menedżerów pakietów ze skanowaniem sygnatur, wykrywaniem fragmentów częściowego lub zmodyfikowanego kodu i analizą plików binarnych. Ma to znaczenie, gdy kod skopiowano do repozytorium lub dołączono bez manifestu. Znaleziska opierają się na Black Duck Security Advisories, z oceną istotności, priorytetyzacją i metrykami osiągalności, a platforma oznacza złośliwe pakiety.

Licencje. Black Duck identyfikuje licencje zadeklarowane i niezadeklarowane, pełne teksty licencji i dane o prawach autorskich, a jego KnowledgeBase śledzi ponad 2750 licencji open source. CRACI dołącza metadane zadeklarowanych licencji do eksportu SBOM i egzekwuje politykę licencyjną.

Pliki binarne i firmware. Black Duck Binary Analysis bada pliki wykonywalne, biblioteki, kontenery i firmware bez dostępu do kodu źródłowego. Jeśli otrzymują Państwo pliki binarne od stron trzecich lub muszą sprawdzić gotowy obraz firmware, to obszar, którego CRACI nie obejmuje.

Więcej niż SCA. Coverity zapewnia analizę statyczną w 22 językach, Defensics wykonuje testy fuzzingowe, a Software Risk Manager konsoliduje znaleziska jako system zarządzania stanem bezpieczeństwa aplikacji (ASPM). Black Duck integruje się z Jenkins, GitLab, Azure DevOps, Bitbucket Pipelines, CircleCI, TeamCity i wieloma innymi systemami CI. Jego Bridge CLI może otwierać Fix PR, które aktualizują podatne zależności bezpośrednie.

Czym różni się CRACI

Jest świadkiem buildu

Każda z powyższych technik coś bada: manifest, drzewo źródeł, plik binarny. Żadna z nich nie widzi buildu w trakcie działania, w tym toolchainów, skryptów instalacyjnych, obrazów bazowych, pobieranych wydań i pakietów z cache, które kształtują wynik, ale mogą nie być w nim widoczne. CRACI jest runnerem, więc widzi tę aktywność bezpośrednio. Proxy rozpoznające pakiety obserwuje 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.

Każdy SBOM określa swoją kompletność, dla każdego zadania i każdego cache, w pięciu stanach: Complete, Complete with connections, Incomplete, Unavailable i Not recorded. Eksport w formatach CycloneDX i SPDX jest wliczony.

Kontroluje sieć buildu

Ponieważ CRACI uruchamia zadanie, można ustawić dla niego politykę ruchu wychodzącego: domyślna odmowa lub domyślne zezwolenie, 24 wbudowane presety źródeł oprogramowania i typowane źródła niestandardowe dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git. Polityki są weryfikowane przed startem zadania i w razie błędu blokują ruch, a CRACI może powiadomić Państwa, gdy zadanie je naruszy. Skaner informuje o tym, co się przedostało. Polityka ruchu wychodzącego ogranicza to, co może się przedostać.

Pochodzenie i monitorowanie

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI stale ponownie ocenia monitorowane SBOM-y pod kątem nowych podatności.

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.

Które rozwiązanie wybrać i kiedy używać obu

• Produkty embedded budowane z Yocto. CRACI może uruchamiać buildy Yocto i BitBake na swoich runnerach, do 32 vCPU i 96 GB, z polityką ruchu wychodzącego, która uzupełnia własne mechanizmy kontroli sieci BitBake. SBOM z CRACI rejestruje, co pobrał build, w tym pakiety hosta i GitHub Actions, które SBOM z create-spdx w Yocto pomija, z package URL dla każdego crate'a Rust. Black Duck Binary Analysis może następnie sprawdzić gotowy obraz. Zob. przewodnik po Yocto.
• Kod z długą historią kopiowanego lub dołączanego open source. Skanowanie fragmentów i sygnatur to mocna strona Black Duck. Warto je zachować.
• Zespoły na GitHub Actions, które potrzebują dowodów wydań. CRACI rejestruje każdy build, przechowuje dla niego SBOM i dane o pochodzeniu oraz eksportuje SBOM-y w formatach CycloneDX lub SPDX.
• Pipeline'y w Jenkins, GitLab lub Azure DevOps. Tu dziś lepiej sprawdza się Black Duck. CRACI obsługuje dziś wyłącznie GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju, więc te pipeline'y trzeba by najpierw przenieść.

Cyber Resilience Act

Black Duck publikuje zestaw stron o CRA, obejmujących terminy, wymóg zgłaszania podatności w ciągu 24 godzin i powody, dla których uważa samo SCA za niewystarczające dla CRA. Przyporządkowuje swoje portfolio do rozporządzenia: Black Duck SCA do analizy kodu względem danych EUVD i NVD oraz generowania SBOM, Coverity z opcją kontroli zgodnych z CRA zapowiedzianą w lipcu 2026, Defensics do testów odporności i Software Risk Manager do bramek polityk. Jego argument brzmi: rozporządzenie wymaga warstw, czyli SCA dla komponentów oraz testów statycznych i dynamicznych dla własnego kodu i usług.

CRACI dodaje dowody z samego buildu: co trafiło do każdego wydania, na ile ten zapis jest kompletny, oraz ciągłe monitorowanie po wydaniu, z SBOM-ami eksportowanymi w formatach CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA. Więcej o zgodności z CRA i przemysłowym IoT.

Dodanie CRACI obok Black Duck

CRACI zastępuje runner, a nie GitHub Actions. Wystarczy zmienić runs-on na craci w workflow, a uruchomienia nadal będą widoczne w interfejsie GitHub. Kroki skanowania Black Duck pozostają w workflow. Proszę wybrać jedno wydanie produktu, porównać SBOM z czasu buildu z CRACI z zestawieniem komponentów z Black Duck i przejrzeć komponenty, które znalazło tylko jedno z nich.