CRACI vs ONEKEY

Krótka odpowiedź

ONEKEY to platforma cyberbezpieczeństwa i zgodności produktów dla urządzeń połączonych z siecią. Przesyłają Państwo obraz firmware'u, a ONEKEY analizuje plik binarny, aby znaleźć komponenty, znane podatności, prawdopodobne zero-day i luki w zgodności, bez potrzeby udostępniania kodu źródłowego. CRACI to runner GitHub Actions, który rejestruje, co pobiera każdy build podczas działania, i na podstawie tego zapisu tworzy SBOM. ONEKEY analizuje wynik, a CRACI zachowuje dowody z buildu. Dobrze się uzupełniają i żaden z nich nie zastępuje drugiego.

W skrócie

Co ONEKEY robi dobrze

Analiza binarna bez kodu źródłowego. ONEKEY analizuje bezpośrednio skompilowany firmware. Jego strona ujmuje to wprost: „No source code or network access needed.” Ma to znaczenie, gdy duża część tego, co trafia na urządzenie, pochodzi od producentów układów, dostawców modułów i podwykonawców, a ich buildu Państwo nigdy nie widzą.

Znaleziska wykraczające poza znane CVE. Poza dopasowywaniem komponentów do danych o podatnościach ONEKEY prowadzi automatyczną analizę zero-day, która szuka w pliku binarnym takich problemów jak wstrzykiwanie poleceń, niezabezpieczona komunikacja i zaszyte poświadczenia.

SBOM-y z obrazu. ONEKEY generuje SBOM z pliku binarnego, umożliwia import SBOM-ów ze skanerów kodu źródłowego lub od dostawców i eksportuje CycloneDX oraz SPDX.

Wsparcie w zakresie zgodności. ONEKEY Compliance Wizard prowadzi zespoły przez wymagania Cyber Resilience Act, IEC 62443-4-2, ETSI EN 303 645 i Radio Equipment Directive oraz eksportuje wyniki na potrzeby certyfikacji przez strony trzecie.

Monitorowanie i CI. Monitorowanie firmware'u codziennie ponownie analizuje przesłany firmware w miarę pojawiania się nowych podatności. Dokumentacja ONEKEY pokazuje, jak przesyłać każdy nowy build z GitHub, GitLab lub Jenkins i przerywać pipeline, gdy pojawią się nowe znaleziska. ONEKEY utrzymuje też unblob, zestaw open source do wyodrębniania zawartości binarnych blobów.

Czym różni się CRACI

Skan pliku binarnego działa wstecz od gotowego obrazu. CRACI działa naprzód od buildu, ponieważ jest maszyną, na której build działa.

Build jest źródłem prawdy

Państwa workflow firmware'u 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. Źródła pobierane przez BitBake z mirrora źródeł Yocto są rejestrowane w SBOM zadania CRACI.

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. W przypadku Yocto stanowi drugą warstwę obok własnego BB_ALLOWED_NETWORKS w BitBake.

Pochodzenie i to, co dostarczono

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu. Agreguje podatności z wielu buildów i repozytoriów oraz stale ponownie ocenia monitorowane SBOM-y w miarę pojawiania się biuletynów.

Równie ważne jest to, czego CRACI nie robi. Nie analizuje plików binarnych, więc nie powie Państwu, co jest w pobieranym przez build blobie dostawcy, a jedynie że build go pobrał i skąd.

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ć którego narzędzia, a kiedy obu

• Integrują Państwo firmware, którego sami nie budują. ONEKEY. Analiza binarna to sposób, by zajrzeć do środka.
• Budują Państwo własny obraz Linuksa w GitHub Actions. CRACI uruchamia build i rejestruje jego składniki. ONEKEY daje dodatkowo drugi, niezależny wgląd w gotowy obraz.
• Audytor pyta, skąd Państwo wiedzą, że SBOM odpowiada produktowi. Zapis CRACI z runnera odpowiada na pytanie, co trafiło do tego buildu, a analiza ONEKEY na pytanie, co jest w tym obrazie. Razem wzajemnie się weryfikują.
• Potrzebują Państwo prowadzonych kontroli względem IEC 62443 lub ETSI EN 303 645. ONEKEY ma to wbudowane. CRACI eksportuje SBOM-y w formacie CycloneDX lub SPDX, a jego API zwraca ślady sieciowe i dane o pochodzeniu na potrzeby Państwa szerszego procesu.

Na potrzeby CRA

Cyber Resilience Act wymaga od producentów identyfikowania i dokumentowania komponentów ich produktów, w tym w postaci SBOM, oraz obsługi podatności tak długo, jak produkt jest wspierany. Zgłaszanie aktywnie wykorzystywanych podatności obowiązuje od września 2026. ONEKEY pomaga, analizując firmware wprowadzany przez Państwa na rynek i prowadząc przez wymagania. CRACI pomaga, wytwarzając dla każdego buildu dowody tego, co trafiło do tego firmware'u, wraz z danymi o pochodzeniu i bieżącym monitorowaniem. 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 ONEKEY

Krok przesyłania do ONEKEY pozostaje bez zmian. Wystarczy przenieść zadanie firmware'u na runner CRACI, ustawiając runs-on: craci, a ten sam workflow nadal działa w GitHub Actions, podczas gdy CRACI rejestruje build. Przesyłanie do ONEKEY odbywa się wtedy z buildu, na który mają Państwo dowody. Przykład Yocto w dokumentacji CRACI pokazuje pełny workflow BitBake. CRACI obsługuje dziś tylko GitHub Actions, więc pipeline'y GitLab lub Jenkins trzeba by przenieść, aby korzystać z runnerów CRACI. GitLab CI i Jenkins są w planach rozwoju. Proszę zobaczyć, jak CRACI działa w obszarach przemysłowego IoT oraz elektroniki użytkowej.

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