CRACI vs Finite State

Krótka odpowiedź

Finite State to platforma bezpieczeństwa produktu dla urządzeń podłączonych do sieci. Analizuje firmware, pliki binarne, kod źródłowy i SBOM-y dostawców, priorytetyzuje podatności według osiągalności i zamienia wyniki w dowody na potrzeby regulacji takich jak CRA. CRACI to runner GitHub Actions, który rejestruje, co każdy build pobiera podczas działania, tworzy na tej podstawie SBOM i kontroluje, z czym build może się łączyć. Finite State analizuje to, co Państwo dostarczają, niezależnie od pochodzenia; CRACI rejestruje, co zrobił Państwa własny build. W dużej mierze się uzupełniają.

W skrócie

Co Finite State robi dobrze

Pokrycie plików binarnych i firmware. Finite State tworzy SBOM-y i inwentarz oprogramowania obejmujący firmware, pliki binarne i kod źródłowy, z obsługą ponad 50 binarnych architektur zestawu instrukcji. W przypadku urządzenia, które uruchamia kod wielu dostawców na nietypowych układach, właśnie o tę szerokość chodzi.

Jeden zapis dla wszystkich dostawców. Łączy firmware, pliki binarne, kod źródłowy, SBOM-y dostawców i znaleziska zewnętrzne w jednej platformie, co pomaga, gdy trzeba porównać deklaracje dostawcy z tym, co faktycznie jest w produkcie.

Mniej szumu. Finite State szereguje znaleziska według osiągalności, danych o exploitach i kontekstu produktu. Podaje, że od 2024 roku 40,5% znalezisk analizowanych przez niego pod kątem osiągalności potwierdzono jako nieosiągalne. Rejestruje decyzje VEX z wpływem na produkt i statusem możliwości wykorzystania.

Dowody zgodności. Jego workflow zgodności obejmuje mapowanie kontroli unijnego CRA i utrzymywanie dowodów oraz generuje raporty gotowe na audyt z artefaktami SBOM i VEX. Odnosi się też do takich frameworków jak wytyczne FDA, UN R155 i IEC 62443.

Integracje CI. Finite State osadza kontrole w GitHub Actions, GitLab CI i Jenkins. Jego akcja Binary Scan przesyła plik binarny zbudowany w CI na platformę Finite State do szybkiego lub pełnego skanu.

Czym różni się CRACI

Finite State zaczyna od artefaktów: gotowego pliku binarnego, drzewa źródeł, SBOM przesłanego przez dostawcę. CRACI zaczyna od samego buildu, ponieważ build działa na CRACI.

Zaobserwowane, a nie wywnioskowane

Zmieniają Państwo runs-on na craci, a zadanie działa w izolowanej maszynie wirtualnej na runnerze CRACI. 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 swoją kompletność dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Zespoły firmware mogą uruchamiać Yocto na runnerach do 32 vCPU i 96 GB RAM. Źródła pobierane przez BitBake z mirrora źródeł Yocto są rejestrowane w SBOM zadania CRACI.

Kontrola w trakcie buildu

Skan wyniku nie zmieni tego, do czego build mógł dotrzeć. Polityka ruchu wychodzącego CRACI może to zrobić: działa w trybie domyślnej odmowy lub zezwolenia, jest walidowana przed startem zadania, w razie błędu blokuje ruch i wysyła alert o naruszeniu.

Pochodzenie i monitorowanie

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

CRACI nie analizuje plików binarnych ani nie prowadzi analizy osiągalności. Jego zapis buildu obejmuje buildy, które na nim działają, a do tego można dodać SBOM-y dostarczane przez Państwa dostawców. W przypadku firmware od dostawców otrzymanego jako plik binarny bez SBOM Finite State obejmuje obszar, którego CRACI nie obejmuje.

Inwentarz tego, co jest gdzie wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawia się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast składać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Kiedy które narzędzie, a kiedy oba

• Większość Państwa firmware pochodzi od dostawców. Finite State. Analiza binarna i przyjmowanie SBOM-ów dostawców powstały właśnie w tym celu.
• Budują Państwo własne obrazy i aplikacje w GitHub Actions. CRACI rejestruje każdy build. Po przesłaniu tego samego artefaktu do Finite State mają Państwo obok siebie zapis buildu i analizę binarną.
• Potrzebują Państwo systemu ewidencji dla wielu produktów i dostawców. Finite State. SBOM-y CRACI można eksportować do CycloneDX lub SPDX, formatów przyjmowanych przez akcję przesyłania Finite State.
• Chcą Państwo ograniczyć, co buildy mogą pobierać. CRACI. Ta kontrola istnieje tylko tam, gdzie działa build.

Na potrzeby CRA

Cyber Resilience Act wymaga od producentów identyfikowania i dokumentowania komponentów ich produktów, w tym przez SBOM, obsługi podatności przez cały okres wsparcia, a od września 2026 także zgłaszania aktywnie wykorzystywanych podatności. Finite State pomaga zebrać te dowody dla produktu i jego dostawców, dzięki mapowaniu kontroli CRA i raportom. CRACI pomaga, wytwarzając dla każdego buildu dowody na to, co trafiło do budowanego przez Państwa oprogramowania, wraz z danymi o pochodzeniu, bieżącym monitorowaniem i eksportem SBOM w formacie CycloneDX lub SPDX. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych producentom w szerszym procesie zgodności z CRA; sam nie zapewnia zgodności produktu. Zob. czego wymaga CRA.

Dodanie CRACI obok Finite State

Nic nie musi opuszczać Finite State. Wystarczy skierować zadanie buildu na runs-on: craci i zachować krok przesyłania do Finite State, a ten sam workflow zadziała na runnerze CRACI, który go zarejestruje. W przypadku Yocto przykład w dokumentacji CRACI pokazuje pełny workflow BitBake. CRACI obsługuje dziś tylko GitHub Actions, więc pipeline'y GitLab CI lub Jenkins musiałyby zostać przeniesione, aby korzystać z runnerów CRACI. GitLab CI i Jenkins są w planach rozwoju. Więcej o tym, jak CRACI działa dla przemysłowego IoT i elektroniki użytkowej.

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