CRACI vs NetRise

Krótka odpowiedź

NetRise to firma zajmująca się analizą binarną. Jej produkt Turbine analizuje firmware, obrazy kontenerów i pliki binarne aplikacji, aby utworzyć SBOM ze skompilowanego kodu i znaleźć w nim ryzyka, w tym podatności, ujawnione sekrety, błędy konfiguracji i kryptografię. Dragos ogłosił 21 września 2026, że przejął NetRise. CRACI to runner GitHub Actions, który rejestruje, co pobiera każdy build podczas działania, tworzy SBOM na podstawie tego zapisu i monitoruje go po wydaniu. NetRise analizuje wynik, także oprogramowania, którego Państwo nie zbudowali; CRACI zachowuje dowody z uruchamianych przez Państwa buildów. Dla PSIRT oba obejmują różne obszary.

W skrócie

Co NetRise robi dobrze

SBOM-y ze skompilowanego kodu. NetRise Turbine tworzy „a complete, binary-derived SBOM from the software itself”, łącznie z zależnościami linkowanymi statycznie i osadzonymi. Obejmuje firmware, obrazy kontenerów i pliki binarne aplikacji, aż po jądra, RTOS, sterowniki i firmware poniżej warstwy aplikacji. W ten sposób można zajrzeć do oprogramowania producentów układów, dostawców modułów i innych dostawców, których buildów Państwo nigdy nie widzą.

Ryzyko, którego skan CVE nie pokazuje. Turbine raportuje sekrety, klucze publiczne i prywatne, certyfikaty oraz błędy konfiguracji dostarczane wewnątrz artefaktu, a także problemy licencyjne i inwentarz kryptografii na potrzeby gotowości postkwantowej. NetRise ZeroLens szuka słabości w skompilowanym oprogramowaniu, zanim zostaną wykorzystane.

Priorytetyzacja. Turbine sprawdza, czy możliwa do prześledzenia ścieżka wykonania łączy działający punkt wejścia z podatnym komponentem, i pokazuje sygnały możliwości wykorzystania, takie jak status CISA KEV. NetRise podaje, że platforma stale skanuje NVD, katalog CISA KEV, grupy przestępcze i botnety, aby ocenić możliwość wykorzystania.

SBOM-y dostawców i integracje. NetRise obsługuje import, wzbogacanie, normalizację i eksport SPDX oraz CycloneDX, dzięki czemu można łączyć SBOM-y z wielu źródeł. Oferuje GraphQL API dla CI/CD i wymienia integracje z Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub i Google Cloud.

Pochodzenie open source. NetRise Provenance analizuje pochodzenie, opiekunów i kondycję repozytoriów komponentów open source oraz blokuje pakiety złośliwe i naruszające politykę tam, gdzie pobierają je programiści, także w CI/CD i asystentach kodowania AI.

Dziś część Dragos. Ogłoszenie Dragos mówi, że NetRise wnosi wgląd w firmware i oprogramowanie działające na urządzeniach technologii operacyjnej oraz że kierownictwo NetRise zintegruje go z Dragos Platform, nadal obsługując obecnych klientów. Warunków finansowych nie ujawniono.

Czym różni się CRACI

Analiza binarna działa wstecz od tego, co dostarczono. CRACI działa naprzód od buildu, ponieważ build działa na CRACI.

Build jest źródłem prawdy

Państwa workflow działa na runnerach CRACI po zmianie jednego wiersza w runs-on. Podczas działania zadania proxy rozpoznające pakiety rejestruje, co zadanie pobiera ze źródeł pakietów, a pakiety przywrócone z cache CI są przenoszone dalej. Każdy SBOM określa, jak jest kompletny, dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. W przypadku Yocto CRACI uruchamia BitBake na runnerach o rozmiarze do 32 vCPU i 96 GB RAM. W równoległym buildzie core-image-sato SBOM z CRACI zawierał każdy komponent z własnego wyniku SPDX Yocto, 88 dodatkowych, takich jak pakiety hosta i GitHub Actions, oraz package URL dla każdej z 653 wersji crate'ów Rust, które Yocto wymienia bez niego.

Kontrola nad tym, do czego build może dotrzeć

Polityka ruchu wychodzącego na runnerze decyduje, z którymi hostami zadanie może się łączyć. Jest walidowana przed uruchomieniem zadania, w razie błędu blokuje ruch, a przy naruszeniu wysyła alert. Skan wyniku nie zmieni tego, do czego build miał dostęp.

Od CVE do dotkniętych produktów

CRACI agreguje podatności z wielu buildów i repozytoriów oraz stale ponownie ocenia monitorowane SBOM-y w miarę pojawiania się biuletynów. Historia buildów pokazuje, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, więc znają Państwo okres narażenia, a widok inwentarza pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach. Zespoły bezpieczeństwa wykonują triage znalezisk i przekazują każde z nich zespołowi odpowiedzialnemu za poprawkę, VEX jest obsługiwany, a bramki polityk mogą zablokować build zawierający konkretne CVE. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Równie ważne jest to, czego CRACI nie robi. Nie analizuje plików binarnych, więc nie zajrzy do firmware'u, którego Państwo nie zbudowali, ani do bloba dostawcy pobieranego przez build; wie jedynie, że build go pobrał i skąd. Można dodawać SBOM-y dostawców, aby ich komponenty były monitorowane, ale bez SBOM potrzebne jest narzędzie do analizy binarnej, takie jak NetRise. CRACI nie ma analizy osiągalności i nie szuka w wyniku sekretów ani błędów konfiguracji.

Czego PSIRT potrzebuje od każdego z nich

Zespół reagowania na incydenty bezpieczeństwa produktu musi wiedzieć, co jest dostarczane w każdym produkcie, łącznie z firmware'em zewnętrznym, znajdować dotknięte produkty, gdy pojawi się podatność, kontynuować monitorowanie po wydaniu, wykonywać triage znalezisk i wskazywać produkty, których problem nie dotyczy, często za pomocą VEX.

• Zewnętrzny firmware i pliki binarne, które Państwo otrzymują. NetRise. Analiza binarna to jedyny sposób, by zajrzeć do środka, gdy dostawca nie przekazuje SBOM.
• Firmware i oprogramowanie budowane przez Państwa w GitHub Actions. CRACI rejestruje każdy build podczas działania i przechowuje historię tego, które buildy zawierały dany komponent.
• Priorytetyzacja długiej listy znalezisk. Sygnały osiągalności i możliwości wykorzystania NetRise. CRACI pokazuje, że podatny pakiet był w buildzie, a nie czy Państwa kod go wywołuje.
• Przekazanie znaleziska zespołowi odpowiedzialnemu za poprawkę. Triage i przekazywanie w CRACI działają na rejestrowanych przez niego buildach; NetRise łączy się z Jira i ServiceNow.

Zob. CRACI dla zespołów PSIRT oraz porównanie narzędzi PSIRT.

Kiedy używać którego narzędzia, a kiedy obu

• Większość tego, co Państwo dostarczają, pochodzi od dostawców. NetRise. Analizuje zarówno kupowane, jak i budowane oprogramowanie.
• Budują Państwo własny obraz Linuksa lub aplikacje w GitHub Actions. CRACI uruchamia build i rejestruje jego składniki. Analiza tego samego obrazu w NetRise daje drugi, niezależny wgląd w to, co dostarczono.
• Zarządzają Państwo flotami technologii operacyjnej. NetRise, dziś w ramach Dragos, jest skierowany na firmware i oprogramowanie działające na takich urządzeniach. CRACI jest dla zespołów, które budują oprogramowanie.
• Chcą Państwo ograniczyć, co buildy mogą pobierać. CRACI. Taka kontrola istnieje tylko tam, gdzie działa build.

Na potrzeby CRA

Cyber Resilience Act wymaga od producentów dokumentowania komponentów ich produktów, w tym w postaci SBOM, obsługi podatności przez cały okres wsparcia oraz, od 11 września 2026, zgłaszania aktywnie wykorzystywanych podatności. NetRise odpowiada na CRA za pomocą SBOM-ów buildów wydaniowych ze skompilowanego artefaktu, obsługi podatności i weryfikacji poprawek w różnych wersjach oraz raportów stanowiących dowody zgodności. CRACI wytwarza dla każdego buildu dowody tego, co trafiło do budowanego przez Państwa oprogramowania, monitoruje je i składa zgłoszenia CRA w Państwa imieniu. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych producentom w szerszym procesie zgodności z CRA; sam w sobie nie zapewnia zgodności produktu. Zob. czego wymaga CRA.

Dodanie CRACI obok NetRise

Nic nie trzeba przenosić z NetRise. Wystarczy przenieść zadanie buildu na runner CRACI, ustawiając runs-on: craci, a ten sam workflow nadal działa w GitHub Actions, podczas gdy CRACI rejestruje build. Przykład Yocto w dokumentacji CRACI pokazuje pełny workflow BitBake. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. Proszę zobaczyć, jak CRACI działa w obszarze przemysłowego IoT.

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