CRACI vs Timesys Vigiles

Krótka odpowiedź

Vigiles to produkt do zarządzania SBOM i podatnościami firmy Timesys, którą Lynx Software Technologies przejęło w grudniu 2023; Lynx sprzedaje go teraz jako Lynx Vigiles. Powstał z myślą o wbudowanym Linuksie: warstwa Yocto, meta-timesys, zbiera metadane o pakietach w Państwa obrazie i przesyła je, a Vigiles dopasowuje je do kuratorowanej bazy CVE, a następnie śledzi decyzje triage i eksportuje raporty SBOM, VEX i podatności.

CRACI to runner GitHub Actions. Państwa build BitBake działa na nim, a podczas jego działania CRACI rejestruje każdy pakiet i źródło pobrane przez build, ogranicza, z czym build może się łączyć, i nadal monitoruje SBOM pod kątem podatności. Oba produkty dają SBOM i monitorowanie CVE dla obrazu Yocto; różnią się tym, skąd pochodzi SBOM. Vigiles odczytuje, co według metadanych BitBake trafia do obrazu. CRACI rejestruje, co build faktycznie pobrał.

W skrócie

Co Vigiles robi dobrze

Stworzony dla wbudowanego Linuksa. Vigiles integruje się z Yocto przez meta-timesys, a także z Buildroot, OpenWrt, Timesys Factory i FreeRTOS, oraz importuje SBOM-y w formatach od SPDX 2.2 do 3.0.1, od CycloneDX 1.1 do 1.7 i CSV dla całej reszty. Lynx podaje, że Vigiles, uruchomiony w 2019 roku, przetworzył ponad 90 000 SBOM-ów.

Mniej szumu CVE. Vigiles dopasowuje komponenty do kuratorowanej bazy CVE, a nie do surowych danych publicznych, co według Lynx usuwa większość fałszywych alarmów powodowanych przez dane publiczne. Jego skaner może przesłać pełne pliki .config jądra Linux i U-Boot, dzięki czemu CVE w funkcjach, których Państwo nie budują, są odfiltrowywane. Ma to znaczenie we wbudowanym Linuksie: w przykładowym raporcie w README meta-timesys 60 z 62 nienaprawionych CVE dotyczy jądra.

Decyzje trwałe między wydaniami. Zespoły zapisują, czy każde CVE ma status affected, fixed, deferred lub not exploitable, a Vigiles przechowuje te decyzje dla każdego wydania, wyróżnia CISA Known Exploited Vulnerabilities i eksportuje SBOM-y w formatach CycloneDX, SPDX i SPDX Lite wraz z raportami VEX i podatności. Jego raporty pokazują też CVE już naprawione przez poprawki w Państwa buildzie oraz poprawki dostępne w warstwie meta-timesys-security. Lynx wymienia EU CRA i EO 14028 wśród standardów, przy których pomaga, a Vigiles łączy się z Jira i Okta.

Czym różni się CRACI

SBOM Vigiles jest tylko tak kompletny jak widok obrazu w BitBake. README meta-timesys opisuje to jako zbieranie metadanych o pakietach do zainstalowania, a pakiety zbudowane poza BitBake lub zbudowane przez niego, ale nieobecne w manifeście głównego systemu plików, trzeba wymienić ręcznie. CRACI nie odczytuje metadanych. Jest maszyną, na której działa build.

Czego nie zawiera własny SBOM Yocto

Nie porównywaliśmy SBOM Vigiles z SBOM CRACI. Porównaliśmy SBOM CRACI z wbudowanym SBOM SPDX Yocto, który także jest generowany z metadanych BitBake. W równoległym buildzie core-image-sato na runnerze ARM64 z 32 vCPU SBOM z CRACI zawierał każdy komponent SBOM Yocto oraz 88, które ten pominął: pakiety hosta na maszynie buildu, takie jak cpio z Ubuntu, źródła GitHub i GitHub Action actions/upload-artifact, a także inne źródła i narzędzia pobrane podczas buildu. Żaden z nich nie jest zainstalowany w obrazie, a wszystkie znajdują się na krytycznej ścieżce buildu.

Oba SBOM-y wymieniały te same 653 wersje crate'ów Rust, ale Yocto podaje je tylko przez nazwę pliku i adres URL pobierania, bez package URL. Dopasowywanie podatności działa na package URL, więc tych crate'ów nie można monitorować na podstawie SBOM Yocto. CRACI rejestruje każdy z nich z package URL pkg:cargo.

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 awarii blokuje ruch, a przy naruszeniu wysyła alert. W przypadku Yocto stanowi drugą warstwę obok własnego BB_ALLOWED_NETWORKS w BitBake, a polityka domyślnej odmowy nie pozwala przejętemu narzędziu buildu wysłać sekretów na host, którego build nie potrzebuje.

Pochodzenie i monitorowanie z tego samego zapisu

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, stale ponownie ocenia monitorowane SBOM-y w miarę pojawiania się biuletynów, pozwala zespołom bezpieczeństwa wykonywać triage znalezisk i przekazywać je zespołowi odpowiedzialnemu za poprawkę oraz pokazuje, które wcześniejsze buildy zawierały podatną zależność, więc znają Państwo okres narażenia. CRACI obsługuje VEX i może składać zgłoszenia podatności CRA w Państwa imieniu.

Sam build, na większych runnerach

Vigiles nie uruchamia Państwa buildu; CRACI tak. Buildy Yocto działają na runnerach o rozmiarze do 32 vCPU i 96 GB RAM, z naliczaniem co sekundę po $0.002 za minutę vCPU ($0.004 za domyślny runner z 2 vCPU). W tym samym porównaniu core-image-sato build bez generowania SBOM przez Yocto trwał o 43% krócej niż build z tym generowaniem.

Zastąpienie Vigiles przez CRACI

W przypadku obrazów Yocto budowanych w GitHub Actions CRACI obejmuje to, po co kupuje się Vigiles: SBOM dla każdego buildu, monitorowanie CVE po wydaniu, decyzje triage i VEX. Dodaje to, czego SBOM oparty na metadanych nie może dać: pakiety hosta, źródła GitHub i akcje użyte przez build oraz politykę ruchu wychodzącego podczas działania.

Trzeba jasno powiedzieć, z czego Państwo rezygnują. Kuratorowane dane CVE Vigiles oraz filtry konfiguracji jądra i U-Boot ograniczają szum CVE w sposób, w jaki CRACI tego nie robi. Vigiles raportuje, które CVE naprawiają już poprawki w Państwa buildzie, czego CRACI nie rejestruje; własny SPDX Yocto także zawiera te metadane receptur, więc jeśli Państwo na nich polegają, należy pozostawić włączone create-spdx. Vigiles obejmuje też Buildroot, OpenWrt i FreeRTOS, działa w dowolnym CI i importuje SBOM-y w wielu formatach. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju, więc pipeline'y Jenkins lub GitLab trzeba by najpierw przenieść na GitHub Actions.

Na potrzeby CRA

Cyber Resilience Act wymaga od producentów dokumentowania komponentów ich produktów, w tym w postaci SBOM, oraz obsługi podatności tak długo, jak produkt jest wspierany, z obowiązkami zgłaszania od września 2026. Vigiles pomaga, przechowując SBOM-y, decyzje dotyczące CVE i raporty dla każdego wydania. CRACI wytwarza dla każdego buildu dowody tego, co trafiło do firmware'u, wraz z danymi o pochodzeniu, bieżącym monitorowaniem i eksportem SBOM w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych producentowi w szerszym procesie CRA; żadne z tych narzędzi samo w sobie nie zapewnia zgodności produktu. Zob. czego wymaga CRA.

Przeniesienie buildu Yocto na CRACI

Wystarczy ustawić runs-on: craci w zadaniu BitBake i wybrać rozmiar runnera; workflow nadal działa w GitHub Actions. Przykład Yocto w dokumentacji CRACI buduje core-image-sato na największym rozmiarze. Proszę zobaczyć, jak CRACI działa w obszarach przemysłowego IoT oraz elektroniki użytkowej.