Hur man Genererar ett Firmware SBOM: Öppna Källkodsverktyg och Arbetsflöden

När en kritisk sårbarhet som Log4Shell eller OpenSSL:s Heartbleed dök upp hade varje programvaruteam bråttom att besvara en fråga: är vi drabbade? För firmware-tillverkare är den frågan nästan omöjlig att besvara utan en Software Bill of Materials. En containerdeploy kan fråga sin pakethanterare på sekunder. En firmware-binär som sitter i produktionsenheter på en fabriksgolv kan det inte. Utan ett firmware SBOM har du inget lager, och utan ett lager vet du inte vad du behöver patcha, rapportera eller ersätta.

Den här guiden täcker de tre praktiska vägarna för att generera ett firmware SBOM med öppna källkodsverktyg, utmaningarna som gör firmware svårare än programvara, och hur man operationaliserar resultatet för löpande CRA-efterlevnad.

Sammanfattning

• Två vägar: byggtid (Yocto/Buildroot, högst noggrannhet) eller post-build binäranalys (EMBA/Syft/cve-bin-tool, bästa möjliga)
• Välj utifrån kontroll: om du äger bygget, använd byggtid; om du fick firmware från en ODM, använd binäranalys
• För binäranalys: extrahera med binwalk, sök igenom paketerade komponenter med Syft, sök igenom strippade binärer med cve-bin-tool, eller kör en fullständig revision med EMBA
• Generera i CycloneDX JSON för CRA-efterlevnad; lägg till SPDX om du även behöver efterlevnad av öppna källkodslicenser
• Pusha till Dependency-Track för löpande CVE-övervakning och hantering av VEX-arbetsflöde
• ENISA-rapportering börjar 11 september 2026: du behöver en operativ pipeline före det datumet, inte december 2027
• ODM-firmware är ditt juridiska ansvar under CRA: kräv SBOM-leverans från alla firmware-leverantörer

Vad Är ett Firmware SBOM?

Ett firmware SBOM är ett strukturerat lager av alla programvarukomponenter i en firmware-bild: OS-paket, delade bibliotek, bootloaders, kärnmoduler, drivrutiner och eventuella vendored binary blobs. Samma NTIA-minimumelement gäller som för alla programvaru-SBOM: leverantörens namn, komponentnamn, version, unik identifierare, beroendeförhållanden, SBOM-dataförfattare och tidsstämpel, men de är väsentligt svårare att fylla i för firmware än för en webbapplikation.

CycloneDX 1.6 definierar firmware som en distinkt komponenttyp vid sidan av enhetshårdvara, vilket innebär att du kan modellera hela produkten, hårdvaru-, firmware- och programvarulager, i ett enda CycloneDX-dokument. Detta är relevant för CRA-produktklassificering: en router som klassificeras som en produkt med digitala element måste ha sina firmware-komponenter spårade och övervakade under hela supportperioden.

CRA Link: EU:s Cyber Resilience Act (Bilaga I) kräver att tillverkare hanterar sårbarheter under hela produktens livscykel. Ett SBOM är den praktiska grunden: du kan inte patcha det du inte har katalogiserat. Se SBOM-krav under CRA för hela den regulatoriska kontexten.

Ett firmware SBOM är inte en Hardware Bill of Materials (HBOM). HBOM dokumenterar fysiska komponenter: kretskort, chips, kontakter. Ett firmware SBOM dokumenterar den programvara som körs på den hårdvaran.

Varför Firmware SBOM är Svårare än Programvaru-SBOM

Att generera ett SBOM för en webbapplikation innebär att köra npm list --json eller pip list. Att generera ett för firmware innebär att rekonstruera ett manifest från artefakter som aldrig var designade för att inventarieras.

Kärninsikten: firmware SBOM-generering är reverse engineering under osäkerhet. Du rekonstruerar ett manifest från artefakter, genererar det inte från indata. Denna distinktion formar vilket verktyg och arbetsflöde du bör välja.

De Två Grundläggande Tillvägagångssätten

Varje firmware SBOM-arbetsflöde faller i en av två kategorier:

1. SBOM vid byggtid. Genererat under byggprocessen från byggsystemets exakta indata. Högsta noggrannhet. Kräver tillgång till källbygget. Fungerar med Yocto och Buildroot.
2. Post-build / analyserat SBOM. Reverse-engineered från en firmware-binärbild. Lägre säkerhet, men ofta det enda alternativet när du tar emot firmware från en ODM eller granskar en enhet du inte tillverkade själv.

Det rätta valet beror helt på om du kontrollerar bygget.

Tillvägagångssätt 1 — SBOM vid Byggtid med Yocto eller Buildroot

När du ska använda det: Du äger firmware-bygget. Detta är guldstandarden för noggrannhet.

Yocto: create-spdx-klassen (inbyggd)

create-spdx bbclass ingår i de senaste Yocto-utgåvorna och ärvs som standard via Pokys distro-konfiguration. Inga ytterligare verktyg krävs. Efter ett normalt bygge genereras tre filer:

# 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

Det genererade SBOM inkluderar alla programvarukomponenter, exakta versioner, licenser, käll-URL:er, tillämpade patchar och beroendeförhållanden. Det finns ingen extraktionsosäkerhet, SBOM härleds från samma indata som producerade binären.

För att även utföra CVE-analys vid byggtid:

# Add to local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Se Yocto SBOM-dokumentationen för fullständiga konfigurationsalternativ.

Buildroot: make legal-info + CycloneDX-generator

# 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/

cyclonedx-buildroot-konverteraren producerar ett CycloneDX JSON-utdata från Buildrots lagliga manifest, vilket gör det omedelbart användbart för CRA-efterlevnad.

Känd begränsning: Binära blobs från tredje part som läggs till bygget (Wi-Fi-firmware, GPU-blobs) spåras bara om du manuellt lägger till dem som Yocto- eller Buildroot-paket. Om ditt byggsystem inte känner till en blob, gör inte heller SBOM det.

Tillvägagångssätt 2 — Analysera en Befintlig Binär

När du ska använda det: Du fick firmware från en ODM eller OEM, eller du granskar en enhet du inte bygger själv.

Steg 1: Extrahera firmware med binwalk

binwalk v3, Rust-omskrivningen av det ursprungliga verktyget, ger snabbare extraktion och förbättrat formatstöd för moderna firmware-bilder:

# 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

Steg 2a: Identifiera Linux-distributionen och kör Syft

Om det extraherade filsystemet innehåller en standard inbäddad Linux-distribution (OpenWRT, Debian-baserad, Alpine-baserad):

# 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 läser pakethanterardatabaser och genererar ett SBOM med hög säkerhet för paketerade komponenter. Det ser inte anpassade C/C++-bibliotek som kompilerades direkt in i binären.

Steg 2b: Sök igenom binärer efter kända sårbara bibliotek med 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 använder strängmönstermatchning mot signaturer för 447+ kända inbäddade bibliotek: OpenSSL, libpng, libxml2, expat, zlib, curl och fler. Det täcker vad Syft missar.

Steg 2c: Djupgående firmware-analys med EMBA

För en heltäckande analys som kombinerar extraktion, SBOM-generering och en fullständig säkerhetsgenomgång i ett enda arbetsflöde:

# 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 hanterar extraktion internt, identifierar komponenter genom flera parallella strategier, matar ut ett CycloneDX SBOM med VEX-data och genererar en fullständig sårbarhetsrapport.

Verktygsr­eferens — Snabb Jämförelse

SPDX vs CycloneDX: Båda formaten accepteras brett. CycloneDX har en native firmware-komponenttyp och inbyggt VEX-stöd. För CRA, generera CycloneDX. SPDX föredras för efterlevnad av öppna källkodslicenser.

Hantera Ditt Firmware SBOM Över Tid

Ett engångs-SBOM är en ögonblicksbild. För CRA-efterlevnad behöver du ett operativt SBOM som utvecklas med din produkt.

Bygge → SBOM (CycloneDX) → Dependency-Track → CVE-avisering → VEX-uttalande → ENISA-rapport (om utnyttjad)

Fyra steg för att göra detta operativt:

1. Regenerera vid varje firmware-bygge. Koppla Yocto eller Buildroot SBOM-generering till din CI/CD-pipeline.
2. Pusha till Dependency-Track. Övervakar ditt SBOM mot live CVE-flöden och varnar dig för nya sårbarheter.
3. Utfärda VEX-uttalanden. Dokumentera om produkten är affected, not_affected, fixed eller under_investigation. Se VEX-guiden.
4. Rapportera till ENISA. Från september 2026. Se ENISA-rapporteringsguiden.

Vanliga Misstag att Undvika

1. Lita enbart på Syft för firmware. Syft ser bara paketförvaltade komponenter. Kombinera alltid med cve-bin-tool eller blint.

2. Ignorera högentropi-regioner. binwalk hoppar tyst över krypterade partitioner. Kör binwalk -E först; dokumentera luckor explicit.

3. Glömma bootloadern. U-Boot, coreboot och GRUB är firmware-komponenter med riktiga CVE:er som missas av de flesta verktyg.

4. Behandla analyserade SBOM som auktoritativa. Markera komponenter med konfidensnivåer med hjälp av CycloneDX:s evidence-fält.

5. Ingen livscykelplan. Utan Dependency-Track blir ditt SBOM inaktuellt inom veckor.

6. ODM-blobslucka. Kräv SBOM-leverans kontraktuellt från alla firmware-leverantörer. Du är ansvarig under CRA.

CRA-efterlevnadschecklista för Firmware-tillverkare

Deadline: CRA:s huvudsakliga skyldigheter gäller från 11 december 2027. Sårbar­hetsrapportering till ENISA börjar 11 september 2026. Du behöver en operativ SBOM-pipeline innan september 2026. Se CRA-implementeringstidslinjen.

□ Identifiera alla firmware-komponenter i dina produkter (SBOM:et)
□ Välj ditt tillvägagångssätt: byggtid (Yocto/Buildroot) eller post-build (EMBA/Syft/cve-bin-tool)
□ Generera SBOM i CycloneDX JSON-format (använd även SPDX för efterlevnad av öppna källkodslicenser)
□ Inkludera bootloader, kärna, alla userspace-paket och eventuella leverantörsblobs (eller dokumentera dem som luckor)
□ Importera SBOM till Dependency-Track (eller motsvarande) för löpande övervakning
□ Etablera ett VEX-arbetsflöde för att dokumentera utnyttjbarhetsstatus för CVE:er
□ Konfigurera rapporteringspipeline redo för ENISA från september 2026
□ Kräv SBOM-leverans från alla firmware-komponentleverantörer (ODM:ar, chipåterförsäljare)
□ Regenerera SBOM vid varje firmware-bygge och spåra förändringar över tid
□ Dokumentera din SBOM-genereringsmetodik för revisionsändamål

Hur CRA Evidence Hjälper

CRA Evidence spårar dina firmware SBOM tillsammans med Digital Product Passports, konformitetsbedömningar och teknisk dokumentation i en enda efterlevnadsarbetsyta. Ladda upp ditt CycloneDX SBOM direkt till en produktversion, det blir det levande komponentlagret för den utgåvan.

Ladda upp ditt första SBOM eller starta en gratis provperiod.

Firmware SBOM är inte valfria under CRA, de är grunden för allt som förordningen kräver. Välj rätt arbetsflöde för din situation, byggtid om du kan, binäranalys om du måste, och operationalisera det innan rapporteringsdeadlinen i september 2026.