Din SBOM listar bibliotek och programvarupaket, men vad händer med den inbyggda programvaran som är inbränd i ditt Bluetooth-chip eller mikrokontrollern i hjärtat av din enhet? En Hardware Bill of Materials (HBOM) utökar komponentinventeringen till att omfatta fysiska kretsar, moduler och den inbyggda programvara som körs på dem. Cyberresiliensförordningen definierar "produkt med digitala element" i Artikel 3.1 till att inkludera hårdvaruprodukter och definierar "hårdvara" i Artikel 3.5 som "ett fysiskt elektroniskt informationssystem, eller delar av ett sådant, som kan behandla, lagra eller överföra digitala data". Förordningen använder inte termen "HBOM" någonstans, men skyldigheten att dokumentera och utöva tillbörlig aktsamhet över alla komponenter, inklusive hårdvara, följer direkt av Artikel 3.1, Artikel 13.5 och Bilaga I, del II, punkt 1.
Sammanfattning
- En HBOM är en strukturerad inventering av de fysiska komponenterna i din produkt, inklusive den inbyggda programvara varje komponent bär
- Cyberresiliensförordningen kräver inte en HBOM under det namnet, men Artikel 3.1 utökar CRA:s tillämpningsområde till hårdvaruprodukter, Artikel 13.5 kräver tillbörlig aktsamhet över alla komponenter från tredje part, och Bilaga I, del II, punkt 1 kräver att du dokumenterar "komponenter som ingår i produkter med digitala element"
- Inbyggd programvara är programvara enligt Artikel 3.4: den "består av datorkod" och måste visas i din SBOM tillsammans med hårdvarukomponentsposter
- CycloneDX är det praktiska enhetliga formatet:
type: devicetäcker fysisk hårdvara,type: firmwaretäcker inbyggd programvara, och båda kan samexistera i ett enda CycloneDX 1.6-dokument - BSI TR-03183 täcker för närvarande inte HBOM som koncept; alla tre delar fokuserar på programvarans materialförteckningar och sårbarhetsrapporter
- Kommissionen kan specificera SBOM-format och element via genomförandeakter (Artikel 13.24), men inget parallellt mandat för ett separat HBOM-format finns i CRA:s text
Varför HBOM är viktigt under CRA
CRA:s tillämpningsområde är bredare än "programvaruprodukter". Artikel 3.1 definierar "produkt med digitala element" som:
produkt med digitala element: programvaru- eller hårdvaruprodukt och dess lösningar för fjärrbehandling av data, inbegripet programvaru- eller hårdvarukomponenter som släpps ut på marknaden separat.
Artikel 3.5 definierar "hårdvara" som:
hårdvara: ett fysiskt elektroniskt informationssystem, eller delar av ett sådant, som kan behandla, lagra eller överföra digitala data.
Den definitionen täcker processorn på ditt kretskort, den trådlösa modulen på ditt utvecklingskort och det säkra elementet i din IoT-gateway. Dessa är inte perifera för CRA-efterlevnad; de ligger inom förordningens tillämpningsområde.
Artikel 13.5 ställer sedan ett konkret krav på dig som tillverkare:
För att uppfylla kraven i punkt 1 ska tillverkarna visa tillbörlig aktsamhet när de integrerar komponenter som kommer från tredje part så att dessa komponenter inte komprometterar cybersäkerheten för produkten med digitala element, inbegripet vid integrering av komponenter i programvara med fri och öppen källkod som inte har tillhandahållits på marknaden i samband med kommersiell verksamhet.
Du kan inte utöva tillbörlig aktsamhet över hårdvarukomponenter du inte har inventerat. Bilaga I, del II, punkt 1 utökar detta ytterligare: SBOM:en måste täcka "sårbarheter och komponenter som ingår i produkter med digitala element". En produkt som innehåller en ESP32-modul innehåller den modulens inbyggda programvarustack som en komponent. En HBOM är det praktiska verktyget för att fånga den inventeringen.
Det finns ingen bestämmelse i CRA som kräver ett dokument kallat HBOM. Skyldigheten är att inventera alla komponenter, inklusive hårdvarukomponenter, inom ramen för den befintliga SBOM-skyldigheten enligt Bilaga I, del II, punkt 1. En HBOM är ett praktiskt sätt att uppfylla den skyldigheten för hårdvaruintensiva produkter, inte ett separat efterlevnadsdokument.
HBOM jämfört med SBOM i korthet
| Dimension | SBOM | HBOM |
|---|---|---|
| Primärt tillämpningsområde | Programvarubibliotek, paket, ramverk | Fysiska komponenter: kretsar, moduler, säkra element |
| Täckning av inbyggd programvara | Kan inkludera type: firmware-poster |
Inbyggd programvara listad tillsammans med sin överordnade hårdvarukomponent |
| CRA-mandat | Uttryckligt, Bilaga I, del II, punkt 1 | Implicit, via Artikel 3.1 tillämpningsområde och Artikel 13.5 tillbörlig aktsamhet |
| BSI TR-03183-täckning | Ja, TR-03183-2 (v2.1.0, 2025) | Nej, ingen av de tre TR-03183-delarna täcker HBOM |
| CycloneDX-stöd | Alla versioner | type: device sedan v1.1; type: firmware sedan v1.2 (maj 2020) |
| Typiskt genereringsverktyg | Syft, Trivy, cdxgen | Manuellt eller via hårdvaruleverantörers datablad; inga mogna automatiska genereringsverktyg finns ännu |
| Plats i teknisk fil | Bilaga VII, punkt 2(b) och punkt 8 | Samma plats, som del av den enhetliga komponentinventeringen |
För hela SBOM-skyldigheten, se CRA SBOM-krav. För formatjämförelse, se CycloneDX jämfört med SPDX.
Vad du ska inkludera i en HBOM
Följande kategorier återspeglar praktiska tekniska överväganden, inte en lagstadgad lista. CRA räknar inte upp kategorier för hårdvarukomponenter. Du bör inkludera alla fysiska komponenter som behandlar, lagrar eller överför digitala data, eftersom det är vad Artikel 3.5 täcker.
Bearbetnings- och anslutningskomponenter
Dessa är de högst prioriterade posterna eftersom deras inbyggda programvara är den vanligaste vektorn för sårbarheter:
- Huvud-applikationsprocessor eller SoC (namn, tillverkare, version/steppning, version av inbyggd programvara)
- Trådlösa moduler: Wi-Fi, Bluetooth, Zigbee, LoRa, mobilnät (vardera med version av inbyggd programvara)
- Sekundära mikrokontrollers som hanterar specifika delsystem
Säkerhetskomponenter
Säkerhetshårdvara förtjänar egna poster eftersom sårbarheter här har störst påverkan:
- Trusted Platform Module-kretsar (TPM)
- Säkra element och hårdvarusäkerhetsmoduler
- Kryptografiska acceleratorer
- Alla komponenter som lagrar nycklar, certifikat eller autentiseringsuppgifter i vila
Lagringskomponenter
Lagring är viktigt när den innehåller kod, konfiguration eller känsliga data:
- Flashminne som håller starthanterare eller inbyggd programvara
- eMMC- eller SD-moduler om de används för beständig lagring
- EEPROM som håller enhetskonfiguration
För varje post registrerar du som minimum: komponentnamn, tillverkare, hårdvaruversion eller steppning, och version av inbyggd programvara där tillämpligt. Länka varje hårdvarupost till dess motsvarande post för inbyggd programvara via CycloneDX-beroendeförhållanden.
En stor andel av IoT-sårbarheter involverar inbyggd programvara som aldrig uppdateras efter leverans. Att dokumentera versioner av inbyggd programvara i din HBOM är förutsättningen för övervakning och åtgärd. Du kan inte spåra det du inte har listat. Se vanliga SBOM-misstag för det bredare mönstret.
Hur inbyggd programvara passar in i CRA:s definition av programvara
Inbyggd programvara behandlas ibland som en särskild kategori skild från både hårdvara och programvara. CRA skapar inte den tredje kategorin. Artikel 3.4 definierar programvara som:
programvara: den del av ett elektroniskt informationssystem som utgörs av datorkod.
Inbyggd programvara består av datorkod. Därmed är inbyggd programvara, enligt CRA, programvara. Det är inte en tolkning som går utanför texten; den följer direkt av definitionen.
Ordet "inbyggd programvara" (firmware) förekommer inte någonstans i CRA-förordningen. Det är avsiktligt: definitionen i Artikel 3.4 är tillräckligt bred för att inkludera det, så ingen separat klassificering behövs.
Den praktiska konsekvensen är enkel. Inbyggd programvara som körs på ett chip i din produkt är en programvarukomponent i din produkt med digitala element. Den måste visas i din komponentinventering. Om den innehåller en sårbarhet är den sårbarheten föremål för samma rapporteringsskyldigheter enligt Artikel 14 som alla programvarusårbarheter.
CycloneDX som ett enhetligt format för SBOM och HBOM
CycloneDX hanterar både hårdvaru- och programvarukomponenter i ett enda dokument. Du behöver inte ett separat filformat för din HBOM.
Historik för komponenttyper (relevant för hårdvara)
| CycloneDX-version | Lanseringsdatum | Relevant tillägg |
|---|---|---|
| 1.1 eller tidigare | 2018 | type: device introducerades |
| 1.2 | 2020-05-26 | type: firmware lades till |
| 1.5 | 2023-06-26 | type: device-driver lades till |
| 1.6 | 2024 | Aktuell rekommendation för CRA-efterlevnad |
| 1.7 | Oktober 2025 | Senaste stabila version |
Observera att det inte finns något type: hardware i någon CycloneDX-version. Rätt typ för ett fysiskt chip eller en modul är type: device.
CycloneDX v1.2-specifikationens vägledning om modellering av hårdvara med inbyggd programvara anger:
"En hårdvaruenhet, till exempel en processor eller en kretsuppsättning. En hårdvaruenhet som innehåller inbyggd programvara BÖR inkludera en komponent för den fysiska hårdvaran i sig, och en annan komponent av typen 'firmware' eller 'operating-system' (beroende på vad som är relevant), som beskriver information om den programvara som körs på enheten."
Den vägledningen motsvarar direkt CRA:s behandling: den fysiska enheten och dess inbyggda programvara är relaterade men skilda komponenter, var och en med sin egen identitet och version.
Sikta på CycloneDX 1.6 för nytt HBOM-arbete. BSI TR-03183-2 v2.1.0 (2025-08-20) höjde sitt minimikrav för CycloneDX till 1.6. Att anpassa sig till 1.6 håller din SBOM och HBOM i samma dokument och uppfyller TR-03183.
Exempel: ESP32-enhet med inbyggd programvarustack
Exemplet nedan visar en realistisk hårdvarukomponent (ESP32-WROOM-32E), dess inbyggda programvara (ESP-IDF) och ett bibliotek inom den inbyggda programvaran (mbedtls), allt i ett enda CycloneDX 1.6-dokument med beroendeförhållanden:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "device",
"name": "ESP32-WROOM-32E",
"version": "Rev 3",
"manufacturer": { "name": "Espressif Systems" },
"description": "WiFi+BT SoC Module",
"properties": [
{ "name": "firmware-version", "value": "4.4.1" },
{ "name": "secure-boot", "value": "supported" }
]
},
{
"type": "firmware",
"name": "ESP-IDF",
"version": "4.4.1",
"description": "Firmware on ESP32"
},
{
"type": "library",
"name": "mbedtls",
"version": "2.28.0",
"description": "TLS library in firmware"
}
],
"dependencies": [
{ "ref": "ESP32-WROOM-32E", "dependsOn": ["ESP-IDF"] },
{ "ref": "ESP-IDF", "dependsOn": ["mbedtls"] }
]
}
dependencies-arrayen gör förhållandet mellan hårdvara och inbyggd programvara explicit. När mbedtls publicerar en CVE-patch kan du spåra vilken enhet som påverkas och vilken version av den inbyggda programvaran som ska uppdateras.
För formatjämförelse och verktygsval, se CycloneDX jämfört med SPDX.
Vanliga frågor
Kräver CRA uttryckligen en HBOM?
Nej, CRA använder inte termen "HBOM" någonstans. Skyldigheten att dokumentera hårdvarukomponenter följer indirekt: Artikel 3.1 för in hårdvaruprodukter inom CRA:s tillämpningsområde, Artikel 13.5 kräver tillbörlig aktsamhet över alla komponenter från tredje part, och Bilaga I, del II, punkt 1 kräver att du dokumenterar "komponenter som ingår i produkter med digitala element". En HBOM är det praktiska sättet att uppfylla dessa skyldigheter för hårdvaruprodukter, inte ett namngivet regulatoriskt krav.
Är inbyggd programvara i ett Bluetooth-chip att anse som programvara enligt CRA?
Ja. Artikel 3.4 definierar programvara som "den del av ett elektroniskt informationssystem som utgörs av datorkod". Inbyggd programvara består av datorkod, så den faller inom den definitionen. Ordet "inbyggd programvara" (firmware) förekommer inte i CRA; det behövs inte, eftersom definitionen i Artikel 3.4 redan täcker det. All inbyggd programvara som körs på en komponent i din produkt är en programvarukomponent i din produkt med digitala element och måste visas i din komponentinventering.
Täcker BSI TR-03183 HBOM?
Nej. BSI TR-03183 har tre delar: Del 1 (Allmänna krav), Del 2 (SBOM) och Del 3 (Sårbarhetsrapporter). Ingen av dem täcker HBOM som ett strukturellt koncept. TR-03183-2 nämner inbyggd programvara endast som en komponentfiltyp inom en programvarans materialförteckning, med fältet software_additionalPurpose: firmware. Om du behöver dokumentera hårdvarukomponenter för CRA-efterlevnad måste du använda tekniskt omdöme och CycloneDX:s inbyggda hårdvarutyper, snarare än att förlita dig på TR-03183-vägledning för den delen av din inventering.
Vilken CycloneDX-version stöder både programvaru- och hårdvarukomponenter?
type: device har funnits i CycloneDX sedan v1.1 (2018 eller tidigare). type: firmware lades till i v1.2, publicerad maj 2020. Båda är därmed tillgängliga i alla nyare CycloneDX-versioner. För CRA-arbete, sikta på v1.6 eller senare: BSI TR-03183-2 v2.1.0 (augusti 2025) höjde sitt minimikrav för CycloneDX till 1.6, och den senaste stabila versionen är 1.7 (oktober 2025). Det finns inget type: hardware i någon CycloneDX-version; använd type: device för fysiska komponenter.