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:

# Yocto 6.0 i nowsze: dodaj do local.conf
OE_FRAGMENTS += "core/yocto/sbom-cve-check"

# Yocto 5.x i wcześniejsze: dodaj do local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Yocto 6.0 usunęło klasę cve-check i zastąpiło ją klasą sbom-cve-check.

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

Buildroot: natywne wyjście CycloneDX lub make legal-info

Nowsze wydania Buildroot generują SBOM CycloneDX bezpośrednio (podręcznik Buildroot 2026.08, sekcja 8.9):

# Wygeneruj SBOM CycloneDX
make show-info | utils/generate-cyclonedx > sbom.cdx.json

# Opcjonalnie: skanuj SBOM pod kątem CVE
cat sbom.cdx.json | support/scripts/cve-check --nvd-path dl/buildroot-nvd/

Alternatywna ścieżka konwertuje manifest prawny:

# 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

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. Do nich potrzebny jest krok 2b.

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

# Zainstaluj cve-bin-tool
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: biblioteki skompilowane i okrojone w pliku binarnym, bez wpisu w bazie pakietów.

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 -f /path/to/firmware.bin -l /tmp/emba-log/ -p ./scan-profiles/default-sbom.emba

EMBA obsługuje ekstrakcję wewnętrznie, identyfikuje komponenty poprzez wiele równoległych strategii (dopasowanie ciągów znaków, skróty binarne, analiza systemu plików, zapytania do baz CVE), wyprowadza CycloneDX SBOM z danymi VEX i generuje pełny raport o lukach bezpieczeństwa. To najbardziej kompleksowa otwartoźródłowa opcja analizy firmware metodą czarnej skrzynki, szczególnie przydatna przy audytach firmware stron trzecich.

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. Dependency-Track od OWASP monitoruje twój SBOM na podstawie aktualnych kanałów CVE (NVD, OSV, GitHub Advisory) i powiadamia, gdy nowe podatności dotyczą istniejących komponentów.

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. Gdy w komponencie znajdzie się CVE, udokumentuj, czy produkt jest affected, not_affected, fixed lub under_investigation. Formatem jest CycloneDX VEX, a Dependency-Track zarządza przepływem pracy. Szczegóły procesu opisuje przewodnik VEX.

5. Zgłoś podatność. Od września 2026 r. CRA wymaga zgłaszania aktywnie wykorzystywanych podatności w ciągu 24 godzin, jednocześnie do CSIRT wyznaczonego jako koordynator i do ENISA przez Single Reporting Platform. Dokładny przepływ opisuje przewodnik zgłaszania do ENISA. Dependency-Track razem z VEX to operacyjny fundament, który pozwala być gotowym.

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. Każda biblioteka skompilowana bezpośrednio do pliku binarnego, bez wpisu w bazie pakietów, pozostanie niewidoczna. Zawsze łącz Syft z cve-bin-tool lub blint.

2. Ignorowanie obszarów wysokiej entropii. binwalk cicho pomija zaszyfrowane partycje. Przed ekstrakcją uruchom analizę entropii (binwalk -E) i udokumentuj wszelkie luki wprost w SBOM.

3. Zapominanie o bootloaderze. U-Boot, coreboot i GRUB są komponentami firmware z prawdziwymi CVE. Leżą poza systemem plików OS i większość narzędzi je pomija, o ile nie zostaną wskazane wprost. SBOM musi obejmować bootloader.

4. Traktowanie analizowanych SBOM jako autorytatywnych. SBOM odtworzony po buildzie metodą inżynierii wstecznej to przybliżenie. Oznaczaj komponenty poziomami pewności. Użyj pola evidence CycloneDX, aby udokumentować, jak zidentyfikowano każdy komponent: dopasowanie ciągu znaków, baza pakietów, skrót binarny lub wpis ręczny.

5. Brak planu cyklu życia. Jeden SBOM z jednego momentu nie spełnia żadnego wymogu zgodności. Nowe CVE publikowane są codziennie. Bez ciągłego monitorowania przez Dependency-Track lub odpowiednik SBOM stanie się przestarzały w ciągu tygodni.

6. Luka blobu ODM. Jeśli sprzęt trafia na rynek z firmware od ODM lub producenta chipa, nie da się przeanalizować tego, czego się nie zbudowało. Zabezpiecz się kontraktowo: wymagaj dostarczenia SBOM od dostawców firmware. W CRA to nie jest opcja, bo producent odpowiada za cały produkt.

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