Hardware Bill of Materials (HBOM) och CRA-efterlevnad

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. CRA använder inte termen "HBOM", men hårdvaruprodukter, separat marknadsförda hårdvarukomponenter, tillbörlig aktsamhet för tredjepartskomponenter och SBOM-komponentinventeringen pekar på samma praktiska behov: veta vilken hårdvara och inbyggd programvara som finns i produkten.

Varför HBOM är viktigt under CRA

CRA:s tillämpningsområde är bredare än enbart programvaruprodukter. Hårdvaruprodukter, separat marknadsförda hårdvarukomponenter och den inbyggda programvaran i dessa komponenter hör alla till produktens inventeringsproblem.

Det spelar roll för tillverkare eftersom komponentaktsamhet inte stannar vid bibliotek med öppen källkod. En processor på ditt kretskort, en trådlös modul på ditt utvecklingskort eller ett secure element i din IoT-gateway kan bära inbyggd programvara och säkerhetsrelevanta versioner. Du kan inte hantera dessa risker utan att inventera dem.

SBOM-kravet är den juridiska platsen för detta arbete: det efterfrågar komponenterna som ingår i produkter med digitala element. En ESP32-modul för därför in både den fysiska modulen och dess firmwarestack i komponentregistret. En HBOM är det praktiska verktyget för att fånga den inventeringen.

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
Efterlevnadsroll	Uttryckligt krav på komponentinventering	Praktisk utvidgning av samma inventering för hårdvaruprodukter
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	Teknisk fil, avsnitt för komponentinventering	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. Inkludera alla fysiska komponenter som behandlar, lagrar eller överför digitala data, eftersom sådana komponenter kan påverka cybersäkerheten.

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.

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. För CRA-arbete ska du behandla inbyggd programvara som programvara, eftersom den är datorkod som körs i ett elektroniskt informationssystem.

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 finnas i din komponentinventering. Om den innehåller en sårbarhet följer den samma sårbarhetshanterings- och rapporteringsflöde som alla andra 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 eller senare 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 eller senare 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-eller-senare-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.