Jak wygenerować SBOM dla firmware: narzędzia i procesy

Gdy pojawiła się krytyczna luka bezpieczeństwa jak Log4Shell lub OpenSSL's Heartbleed, każdy zespół programistyczny musiał odpowiedzieć na jedno pytanie: czy jesteśmy zagrożeni? Dla producentów firmware odpowiedź na to pytanie jest praktycznie niemożliwa bez Software Bill of Materials. Wdrożenie kontenerowe może zapytać swój menedżer pakietów w ciągu sekund. Binarka firmware działająca w urządzeniach produkcyjnych rozmieszczonych po całej hali fabrycznej, nie. Bez firmware SBOM nie masz inwentarza, a bez inwentarza nie wiesz, co musisz załatać, zgłosić lub wymienić.

Ten przewodnik omawia dwa podstawowe podejścia do generowania firmware SBOM przy użyciu narzędzi open source, wyzwania sprawiające, że firmware jest trudniejszy niż oprogramowanie, oraz jak operacjonalizować wynik dla ciągłej zgodności z CRA.

Czym Jest Firmware SBOM?

Firmware SBOM to ustrukturyzowany inwentarz wszystkich komponentów oprogramowania zawartych w obrazie firmware: pakiety OS, biblioteki współdzielone, bootloadery, moduły jądra, sterowniki i wszelkie vendored binary blobs. Te same minimalne elementy NTIA mają zastosowanie jak do każdego SBOM oprogramowania: nazwa dostawcy, nazwa komponentu, wersja, unikalny identyfikator, relacje zależności, autor danych SBOM i znacznik czasu, ale są znacznie trudniejsze do uzupełnienia dla firmware niż dla aplikacji webowej.

CycloneDX 1.6 definiuje firmware jako odrębny typ komponentu obok sprzętu urządzenia, co oznacza, że możesz modelować cały produkt, warstwy sprzętu, firmware i oprogramowania, w jednym dokumencie CycloneDX. Jest to istotne dla klasyfikacji produktów CRA: router sklasyfikowany jako produkt z elementami cyfrowymi musi mieć swoje komponenty firmware śledzone i monitorowane przez cały okres wsparcia.

Załącznik I, część II CRA wymaga od producentów:

"1) identyfikowania i dokumentowania podatności i komponentów zawartych w produkcie z elementami cyfrowymi, w tym przez sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktów;"

W przypadku firmware "zależności najwyższego poziomu" oznaczają każdy pakiet OS, bibliotekę współdzieloną, bootloader i moduł jądra w obrazie, nie tylko to, co zgłasza menedżer pakietów.

Zobacz wymagania SBOM w ramach CRA dla pełnego kontekstu regulacyjnego.

Firmware SBOM to nie jest Hardware Bill of Materials (HBOM). HBOM dokumentuje fizyczne komponenty: płytki PCB, chipy, złącza. Firmware SBOM dokumentuje oprogramowanie działające na tym sprzęcie.

Dlaczego Generowanie Firmware SBOM jest Trudniejsze niż Standardowego SBOM Oprogramowania?

Generowanie SBOM dla aplikacji webowej oznacza uruchomienie npm list --json lub pip list. Generowanie SBOM dla firmware oznacza rekonstrukcję manifestu z artefaktów, które nigdy nie były zaprojektowane do inwentaryzacji.

Kluczowy wniosek: generowanie firmware SBOM to inżynieria wsteczna w warunkach niepewności. Rekonstruujesz manifest z artefaktów, a nie generujesz go z danych wejściowych. To rozróżnienie kształtuje wybór narzędzia i przepływu pracy.

Dwie Podstawowe Podejścia

Każdy przepływ pracy firmware SBOM należy do jednej z dwóch kategorii:

1. SBOM w czasie budowania. Generowany podczas procesu budowania z dokładnych danych wejściowych systemu budowania. Najwyższa dokładność. Wymaga dostępu do źródłowego builda. Działa z Yocto i Buildroot.
2. Post-build / analizowany SBOM. Poddany inżynierii wstecznej z binarnego obrazu firmware. Niższa pewność, ale często jedyna opcja gdy otrzymujesz firmware od ODM lub audytujesz urządzenie, którego sam nie budujesz.

Właściwy wybór zależy wyłącznie od tego, czy kontrolujesz build.

Podejście 1: SBOM w Czasie Budowania z Yocto lub Buildroot

Kiedy używać: Posiadasz własny build firmware. Jest to złoty standard dla dokładności.

Yocto: klasa create-spdx (wbudowana)

System budowania OpenEmbedded generuje dane SBOM SPDX domyślnie przez dziedziczenie create-spdx w INHERIT_DISTRO. Po normalnym buildzie obrazu główny plik SPDX JSON pojawia się w katalogu deploy obrazu:

# Po normalnym buildzie obrazu Yocto
ls tmp/deploy/images/MACHINE/
# IMAGE-MACHINE.spdx.json         ← główny dokument SPDX
# Metadane SBOM recept są uwzględnione dla recept w obrazie

Wygenerowany SBOM zawiera wszystkie komponenty oprogramowania, dokładne wersje, licencje, adresy URL źródeł, zastosowane patche i relacje zależności. Nie ma niepewności ekstrakcji, SBOM pochodzi z tych samych danych wejściowych, które wyprodukowały binarny plik.

Aby wykonać analizę CVE również w czasie budowania:

# Dodaj do local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Zobacz dokumentację Yocto SBOM dla pełnych opcji konfiguracji.

Buildroot: make legal-info + generator CycloneDX

# Krok 1: Wygeneruj manifest komponentów
make legal-info
# Wynik: output/legal-info/manifest.csv

# Krok 2: Konwertuj do SBOM CycloneDX
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Opcjonalnie: skanuj CVE w czasie builda
python support/scripts/cve-check --nvd-path ./nvd-data/

Konwerter cyclonedx-buildroot produkuje dane wyjściowe CycloneDX JSON z manifestu prawnego Buildroot, dzięki czemu jest natychmiast użyteczny do zgodności z CRA.

Znane ograniczenie: Binarne bloby stron trzecich dodane do builda (firmware Wi-Fi, bloby GPU) są śledzone tylko wtedy, gdy ręcznie dodasz je jako pakiety Yocto lub Buildroot. Jeśli twój system budowania nie wie o blobie, SBOM też o nim nie będzie wiedział.

Zephyr RTOS: west spdx

Zephyr generuje SBOM natywnie za pomocą polecenia west spdx. Domyślnie tworzy dokumenty SPDX 2.3 w formacie tag-value:

west spdx --init -d build
west build -d build -b <your_board> <app_dir>
west spdx -d build

Wynik znajduje się w build/spdx/ i obejmuje app.spdx, zephyr.spdx, build.spdx oraz modules-deps.spdx. Binarne bloby stron trzecich lub biblioteki spoza drzewa, których nie obejmują metadane builda, nie są ujęte. Udokumentuj te luki albo dodaj je ręcznie jako komponenty zewnętrzne.

W przypadku FreeRTOS i platform bare-metal RTOS bez natywnych narzędzi SBOM przeskanuj skompilowany plik binarny za pomocą cve-bin-tool. Wersję jądra RTOS i dołączone middleware wpisz ręcznie jako komponenty CycloneDX.

Podejście 2: Analiza Istniejącego Pliku Binarnego

Kiedy używać: Otrzymałeś firmware od ODM lub OEM, lub audytujesz urządzenie, którego sam nie budujesz.

Krok 1: Wyodrębnij firmware za pomocą binwalk

binwalk to standardowe narzędzie open source do rozpakowywania firmware:

# Zainstaluj binwalk
pip install binwalk

# Wyodrębnij wszystkie osadzone systemy plików
binwalk -eM firmware.bin

# Sprawdź, co zostało wyodrębnione
ls _firmware.bin.extracted/

# Przed kontynuacją sprawdź zaszyfrowane partycje
binwalk -E firmware.bin
# Wysoka entropia (powyżej 0.9) wskazuje na zaszyfrowaną zawartość

Krok 2a: Zidentyfikuj dystrybucję Linux i uruchom Syft

Jeśli wyodrębniony system plików zawiera standardową wbudowaną dystrybucję Linux (OpenWRT, oparty na Debianie, oparty na Alpine):

# Sprawdź bazy danych menedżerów pakietów
ls _firmware.bin.extracted/squashfs-root/var/lib/dpkg/    # Debian-based
ls _firmware.bin.extracted/squashfs-root/lib/apk/db/      # Alpine/musl-based
ls _firmware.bin.extracted/squashfs-root/var/lib/opkg/    # OpenWRT/opkg

# Uruchom Syft na wyodrębnionym systemie plików
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft odczytuje bazy danych menedżerów pakietów i generuje SBOM z wysoką pewnością dla spakietowanych komponentów. Nie widzi niestandardowych bibliotek C/C++, które zostały skompilowane bezpośrednio do pliku binarnego.

Krok 2b: Skanuj pliki binarne pod kątem znanych podatnych bibliotek za pomocą cve-bin-tool

# Zainstaluj cve-bin-tool od Intel
pip install cve-bin-tool

# Skanuj wyodrębniony katalog binarny
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool używa dopasowywania wzorców ciągów znaków do sygnatur 447+ znanych wbudowanych bibliotek: OpenSSL, libpng, libxml2, expat, zlib, curl i innych. Pokrywa to, czego Syft nie widzi.

Krok 2c: Dogłębna analiza firmware z EMBA

Dla kompleksowej analizy łączącej ekstrakcję, generowanie SBOM i pełny przegląd bezpieczeństwa w jednym przepływie pracy:

# Sklonuj i skonfiguruj EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Uruchom EMBA z wyjściem SBOM
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA obsługuje ekstrakcję wewnętrznie, identyfikuje komponenty poprzez wiele równoległych strategii, wyprowadza CycloneDX SBOM z danymi VEX i generuje pełny raport o lukach bezpieczeństwa.

Informacje o Narzędziach: Szybkie Porównanie

SPDX vs CycloneDX: Oba formaty są szeroko akceptowane. CycloneDX ma natywny typ komponentu firmware i wbudowaną obsługę VEX, więc lepiej pasuje do zgodności z CRA. SPDX jest preferowany do zgodności z licencjami open source i jest natywnym wynikiem Yocto. Dla CRA generuj CycloneDX. Jeśli używasz Yocto, generuj oba formaty. BSI TR-03183-2 v2.1.0, niemieczna wytyczna techniczna dla SBOM pod CRA, zaleca CycloneDX 1.6+ albo SPDX 3.0.1+ i jest dokumentem najczęściej przywoływanym przez audytorów oraz jednostki notyfikowane.

Zarządzanie Firmware SBOM w Czasie

Jednorazowy SBOM to migawka. Dla zgodności z CRA potrzebujesz operacyjnego SBOM, który ewoluuje wraz z twoim produktem.

Pięć kroków, aby to uruchomić operacyjnie:

1. Regeneruj przy każdym buildzie firmware. Podłącz generowanie SBOM Yocto lub Buildroot do swojego pipeline CI/CD.

2. Wypchnij do Dependency-Track. Monitoruje twój SBOM na podstawie aktualnych kanałów CVE i powiadamia o nowych lukach.

3. Podpisz SBOM. Podpisz wygenerowany plik za pomocą cosign od Sigstore przed zapisaniem lub udostępnieniem:

   cosign sign-blob sbom.cdx.json \
     --bundle sbom.cdx.json.bundle \
     --yes
   

   Przechowuj bundle razem z SBOM. Klienci i organy mogą zweryfikować go poleceniem cosign verify-blob. CRA dziś tego nie wymaga, ale frameworki bezpieczeństwa łańcucha dostaw, takie jak SLSA i in-toto, traktują to jako oczekiwaną praktykę.

4. Wydawaj oświadczenia VEX. Dokumentuj, czy produkt jest affected, not_affected, fixed lub under_investigation. Zobacz przewodnik VEX.

5. Zgłaszaj do ENISA. Od września 2026 r. Zobacz przewodnik zgłaszania do ENISA.

Częste Błędy do Uniknięcia

1. Ufanie wyłącznie Syft dla firmware. Syft widzi tylko komponenty zarządzane przez menedżer pakietów. Zawsze łącz z cve-bin-tool lub blint.

2. Ignorowanie obszarów wysokiej entropii. binwalk cicho pomija zaszyfrowane partycje. Najpierw uruchom binwalk -E; dokumentuj luki explicite.

3. Zapominanie o bootloaderze. U-Boot, coreboot i GRUB są komponentami firmware z prawdziwymi CVE pomijanymi przez większość narzędzi.

4. Traktowanie analizowanych SBOM jako autorytatywnych. Oznaczaj komponenty poziomami pewności używając pola evidence CycloneDX.

5. Brak planu cyklu życia. Bez Dependency-Track twój SBOM stanie się przestarzały w ciągu tygodni.

6. Luka blobu ODM. Wymagaj dostarczenia SBOM kontraktowo od wszystkich dostawców firmware. Jesteś odpowiedzialny na mocy CRA.

Lista Kontrolna Zgodności CRA dla Producentów Firmware

□ Zidentyfikuj wszystkie komponenty firmware w swoich produktach (SBOM)
□ Wybierz swoje podejście: build-time (Yocto/Buildroot) lub post-build (EMBA/Syft/cve-bin-tool)
□ Generuj SBOM w formacie CycloneDX JSON (używaj również SPDX do zgodności z licencjami open source)
□ Uwzględnij bootloader, jądro, wszystkie pakiety userspace i wszelkie bloby dostawców (lub dokumentuj je jako luki)
□ Importuj SBOM do Dependency-Track (lub odpowiednika) do ciągłego monitorowania
□ Ustanów przepływ pracy VEX do dokumentowania statusu exploitowalności CVE
□ Skonfiguruj pipeline raportowania gotowy dla ENISA od września 2026 r.
□ Wymagaj dostarczenia SBOM od wszystkich dostawców komponentów firmware (ODM-ów, producentów chipów)
□ Regeneruj SBOM przy każdym buildzie firmware i śledź zmiany w czasie
□ Dokumentuj swoją metodologię generowania SBOM dla celów audytu

Często zadawane pytania

Jakie narzędzie do firmware SBOM wybrać, jeśli buduję w Yocto?

Użyj wbudowanej klasy create-spdx z Yocto. Aktualna dokumentacja Yocto wskazuje, że OpenEmbedded dziedziczy ją domyślnie przez INHERIT_DISTRO. Generuje dokument SPDX na podstawie dokładnych danych wejściowych builda i nie wymaga dodatkowych narzędzi. Narzędzia do analizy binarnej po buildzie (EMBA, Syft) są potrzebne tylko wtedy, gdy proces budowania nie jest pod twoją kontrolą. Jeśli własny build Yocto jest w twoich rękach, create-spdx to złoty standard dla dokładności.

Czy Syft wystarczy do zgodności firmware z CRA?

Nie. Syft dobrze odczytuje bazy danych menedżerów pakietów (dpkg, apk, opkg), ale nie widzi bibliotek skompilowanych bezpośrednio do plików binarnych bez wpisu w bazie pakietów. Takie pliki bez symbolów stanowią znaczną część większości firmware. Połącz Syft z cve-bin-tool do wykrywania wbudowanych bibliotek, albo użyj EMBA, który robi to wszystko w jednym przebiegu.

Jaki format SBOM wymagany jest przez CRA: CycloneDX czy SPDX?

CRA nie narzuca konkretnego formatu, ale CycloneDX JSON to zalecany wybór dla zgodności z CRA. CycloneDX ma natywny typ komponentu firmware (CycloneDX 1.6), wbudowaną obsługę VEX do śledzenia statusu podatności i jest bezpośrednio akceptowany przez Dependency-Track do bieżącego monitorowania. Generuj SPDX dodatkowo, jeśli potrzebujesz też zgodności z licencjami open source. Yocto produkuje SPDX natywnie.

Czy firmware wprowadzony na rynek przed grudniem 2027 podlega wymogom SBOM z CRA?

Produkty wprowadzone na rynek przed 11 grudnia 2027, które następnie przeszły istotną modyfikację, muszą spełniać wymagania CRA od momentu tej modyfikacji. Produkty wprowadzone przed tą datą bez istotnej modyfikacji nie mają obowiązku dostosowania się wstecz. Jednak obowiązek zgłaszania podatności do ENISA zaczyna się 11 września 2026 dla wszystkich aktywnie wykorzystywanych podatności w produktach objętych CRA, w tym produktów już obecnych na rynku.

Jeśli mój ODM odmawia dostarczenia SBOM, czy nadal ponoszę odpowiedzialność prawną na mocy CRA?

Tak. Jako producent wprowadzający produkt na rynek UE odpowiadasz za cały produkt, w tym za komponenty firmware dostarczone przez ODM lub producenta chipa. CRA nie pozwala na przeniesienie odpowiedzialności na dostawców. Zabezpiecz się kontraktowo: wymagaj dostarczenia SBOM w umowach z dostawcami. ODM, który odmawia, tworzy dla ciebie problem zgodności, nie dla siebie.

Od kiedy obowiązuje zgłaszanie podatności firmware do ENISA?

Od 11 września 2026. Od tej daty aktywnie wykorzystywane podatności w produktach objętych CRA muszą być zgłaszane do właściwego krajowego CSIRT (w Polsce: CERT Polska, prowadzony przez NASK, który przekazuje zgłoszenia do ENISA) w ciągu 24 godzin od uzyskania informacji o aktywnym wykorzystaniu, z kolejnym raportem w ciągu 72 godzin i raportem końcowym w ciągu 14 dni. To 15 miesięcy przed pełnym terminem zgodności w grudniu 2027. Operacyjny pipeline SBOM i monitorowania trzeba mieć przed wrześniem 2026, nie po.

Jak wygenerować SBOM dla firmware Zephyr RTOS?

Użyj west spdx. Najpierw utwórz katalog build poleceniem west spdx --init -d build, wykonaj normalny west build -d build, a potem uruchom west spdx -d build. Wynikiem jest zestaw dokumentów SPDX 2.3 obejmujących aplikację, kod źródłowy Zephyr, wynik builda i zależności modułów. Biblioteki lub bloby dostawców poza metadanymi builda dodaj jako komponenty zewnętrzne albo udokumentuj jako luki. Dla FreeRTOS i innych platform RTOS bez natywnych narzędzi SBOM przeskanuj skompilowany plik binarny za pomocą cve-bin-tool i wpisz wersję RTOS jako ręczny komponent CycloneDX.

Czy trzeba podpisywać firmware SBOM?

Podpis nie jest dziś obowiązkowy w CRA, ale jest oczekiwaną praktyką w frameworkach bezpieczeństwa łańcucha dostaw. Użyj cosign od Sigstore, aby podpisać SBOM, i przechowuj bundle weryfikacyjny obok pliku. Podpisany SBOM dowodzi, że dokument został wyprodukowany przez pipeline i nie został zmieniony. Ma to znaczenie przy udostępnianiu klientom, organom lub jednostkom notyfikowanym.