Jak Wygenerować Firmware SBOM: Narzędzia Open Source i Przepływy Pracy

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 trzy praktyczne ścieżki 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.

CRA Link: Ustawa UE o odporności cybernetycznej (Załącznik I) wymaga od producentów zarządzania lukami bezpieczeństwa przez cały cykl życia produktu. SBOM jest praktycznym fundamentem: nie możesz łatać tego, czego nie skatalogowałeś. 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 Firmware SBOM są Trudniejsze niż Oprogramowanie SBOM

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)

Klasa create-spdx bbclass jest zawarta w ostatnich wydaniach Yocto i domyślnie dziedziczona przez konfigurację dystrybucji Poky. Nie jest wymagane żadne dodatkowe narzędzie. Po normalnym buildzie generowane są trzy pliki:

# After a normal Yocto build
ls tmp/deploy/spdx/
# IMAGE-MACHINE.spdx.json         ← main SPDX document
# IMAGE-MACHINE.spdx.index.json   ← per-recipe component index
# IMAGE-MACHINE.spdx.tar.zst      ← full archive with all component SBOMs

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:

# Add to 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

# Step 1: Generate the component manifest
make legal-info
# Output: output/legal-info/manifest.csv

# Step 2: Convert to CycloneDX SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: scan for CVEs at build time
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ł.

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 v3, przepisanie oryginalnego narzędzia w Rust, zapewnia szybszą ekstrakcję i ulepszoną obsługę formatów dla nowoczesnych obrazów firmware:

# Install binwalk v3
pip install binwalk

# Extract all embedded filesystems
binwalk -eM firmware.bin

# Check what got extracted
ls _firmware.bin.extracted/

# Check for encrypted partitions before proceeding
binwalk -E firmware.bin
# High entropy (above 0.9) regions indicate encrypted content

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):

# Check for package manager databases
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

# Run Syft on the extracted filesystem
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

# Install Intel's cve-bin-tool
pip install cve-bin-tool

# Scan extracted binary directory
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:

# Clone and set up EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Run EMBA with SBOM output
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. Dla CRA generuj CycloneDX. SPDX jest preferowany do zgodności z licencjami open source.

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.

Build → SBOM (CycloneDX) → Dependency-Track → Alert CVE → Oświadczenie VEX → Raport ENISA (jeśli wykorzystana)

Cztery kroki, aby to zoperacjonalizować:

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. Wydawaj oświadczenia VEX. Dokumentuj, czy produkt jest affected, not_affected, fixed lub under_investigation. Zobacz przewodnik VEX.
4. Raportuj do ENISA. Od września 2026 r. Zobacz przewodnik raportowania 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

Deadline: Główne zobowiązania CRA obowiązują od 11 grudnia 2027 r. Raportowanie podatności do ENISA rozpoczyna się 11 września 2026 r. Potrzebujesz operacyjnego pipeline SBOM przed wrześniem 2026 r. Zobacz harmonogram wdrażania CRA.

□ 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

Jak CRA Evidence Pomaga

CRA Evidence śledzi twoje firmware SBOM wraz z Digital Product Passports, ocenami zgodności i dokumentacją techniczną w jednym obszarze roboczym zgodności. Prześlij swój CycloneDX SBOM bezpośrednio do wersji produktu, staje się on aktualnym inwentarzem komponentów dla tego wydania.

Prześlij swój pierwszy SBOM lub rozpocznij bezpłatny okres próbny.

Firmware SBOM nie są opcjonalne w ramach CRA, są fundamentem wszystkiego, czego wymaga rozporządzenie. Wybierz właściwy przepływ pracy dla swojej sytuacji, build-time jeśli możesz, analiza binarna jeśli musisz, i zoperacjonalizuj go przed terminem raportowania we wrześniu 2026 r.