HBOM-guide: Hardware Bill of Materials för CRA

Din SBOM listar bibliotek och programvarupaket. Den berättar inte om radiomodulen i din produkt inte längre supporteras, om starthanteraren kan uppdateras eller vilken batch som använde en utbytt kretsuppsättning.

Det är uppgiften för en Hardware Bill of Materials (HBOM). CRA använder inte termen "HBOM", men hårdvaruprodukter, inbyggd programvara, aktsamhet för tredjepartskomponenter och SBOM:ens komponentinventering pekar alla på samma praktiska behov: känna till vilken hårdvara och inbyggd programvara som finns i produkten, och veta om du kan agera när en sårbarhet uppstår.

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 begränsas till bibliotek med öppen källkod. En processor på ditt kretskort, en trådlös modul på ditt utvecklingskort eller ett säkert element i din IoT-gateway kan bära firmware, säkerhetsinställningar och supportdatum. Du kan inte hantera dessa risker utan att lista dem.

SBOM-kravet är där detta underlag vanligtvis hamnar. CRA ber tillverkare att identifiera och dokumentera komponenter och sårbarheter, inklusive via en maskinläsbar SBOM som täcker minst toppnivåberoenden. En ESP32-modul för därför in både den fysiska modulen och dess firmware-stack i komponentregistret. En HBOM är det praktiska verktyget för att fånga hårdvarusidan av inventeringen.

Supportperioder är en del av samma bild. CRA gör det möjligt att beakta kärnkomponenters supportperioder. Den tekniska dokumentationen behöver sedan den information som användes för att fastställa produktens supportperiod. Om en kretsuppsättning eller modul når supportens slut innan din produktsupportperiod löper ut, är HBOM:en den plats där det faktum ska bli synligt först.

Hur en HBOM ser ut i en verklig leveranskedja

Föreställ dig en EU-importör som köper en uppkopplad gateway från en ODM i Shenzhen. Importören behöver inte varje motstånd. Den behöver de byggfakta som förändrar cybersäkerhetsrisken: radiomodul, firmware-baslinje, supportstatus och godkända substitutioner.

Den viktigaste skillnaden är tillverkningsposten. En design-BOM anger vad konstruktionen avsåg att använda. HBOM:en bör också fånga vad fabriken faktiskt levererade.

HBOM jämfört med SBOM i korthet

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 och var du ska sluta

CRA ger ingen lagstadgad fältlista för HBOM. Det kräver inte heller att du listar varje passiv fysisk del. Komponentinventeringens baslinje sätter ett toppnivågolv för SBOM:en, och hårdvarusidan bör följa samma risklogik.

Använd detta tröskelvärde: lista hårdvara som kan förändra produktens cybersäkerhetsrisk, sårbarhetsstatus, uppdateringsväg eller dokumentation om supportperiod.

Börja med komponenter som utför någon av dessa uppgifter:

• Bearbetar data: huvud-processorer, SoC:ar, mikrokontrollers, FPGA:er och säkerhetsrelaterade ASIC:ar.
• Lagrar kod eller hemligheter: flash, eMMC, Trusted Platform Modules (TPM:ar), säkra element och lagringskontrollers.
• Sänder data: Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, mobilnät och GNSS-moduler.
• Startar upp eller uppdaterar produkten: starthanterare, bootloaders, UEFI, BIOS, firmware för baseboard management controller (BMC) och uppdateringskontrollers.
• Upprätthåller säkerhet: kryptografiska acceleratorer, hårdvarubaserade förtroenderötter, nyckellagringar och säkra enklaver.
• Exponerar serviceåtkomst: produktions-debugportar, JTAG, UART, SWD eller hanteringsgränssnitt där produktionslåsstatusen spelar roll.

Passiva delar som vanliga motstånd och kondensatorer hör normalt inte till HBOM:en om de inte har en säkerhetsfunktion, en digital identitet, inbyggd programvara eller en känd substitutionsrisk. Det praktiska testet är enkelt: om en sårbarhet, ett säkerhetsmeddelande, ett EOL-meddelande eller en leverantörssubstitution för delen skulle förändra ditt produktriskbeslut, lista den.

Hårdvarukategorier med hög prioritet

Följande kategorier är inte en lagstadgad lista. De är posterna som troligast spelar roll i CRA-dokumentation eftersom de bär firmware, nycklar, gränssnitt eller beroenden till leverantörssupport.

För varje post registrerar du som minimum: komponentnamn, tillverkare, hårdvaruversion eller steppning och firmware-version där tillämpligt. Länka varje hårdvarupost till dess motsvarande firmware-post via CycloneDX-beroendeförhållanden.

Firmware-lager som ofta missas

Ett enda fält för "firmware-version" är ofta för ytligt. Många produkter innehåller flera firmware-lager med olika ägare, uppdateringsvägar och sårbarhetskällor.

Lager som ofta missas inkluderar:

• Startfirmware: boot-ROM, bootloader, starthanterare och konfiguration för säker uppstart.
• Radiofirmware: Wi-Fi, Bluetooth, mobilnätets basband, Zigbee, Thread, LoRaWAN och NFC-firmware.
• Plattformsfirmware: UEFI, BIOS, BMC, option-ROM:ar och CPU-mikrokod. NIST SP 800-193 behandlar plattformsfirmware som grundläggande hårdvara och inbyggd programvara som behövs för att starta och driva ett system.
• Kontrollerfirmware: lagringskontrollers, nätverkskort, strömkontrollers, sensorhubbar och inbyggda kontroller.
• Säkerhetsfirmware: TPM-firmware, operativsystem för säkra element, applets för säkra element, avbildningar av betrodd körningsmiljö (TEE) och HSM-firmware.
• Programmerbar logik: FPGA-bitströmmar och säkerhetsrelaterad ASIC- eller FPGA-konfiguration.
• Binärfiler från leverantör: SDK-levererade firmware-filer som ingår i produktavbildningen men underhålls av en krets- eller modulleverantör.

Varje lager bör vara en separat komponent när det har sin egen version, uppdateringsväg, underhållare eller källa för säkerhetsmeddelanden. Det är vad som gör att du senare kan besvara den praktiska frågan: vilka exakta produktversioner berörs av detta säkerhetsmeddelande om firmware?

Fält som gör en HBOM användbar

Det lagstadgade golvet är smalare än en användbar HBOM. Fälten nedan är inte alla obligatoriska under CRA. De är det underlag som låter dig hantera sårbarheter, leverantörsändringar och supportperiodbeslut utan att börja från noll.

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 sårbarheten samma sårbarhetshanterings- och rapporteringsflöde som alla andra programvarusårbarheter.

Om inbyggd programvara inte kan uppdateras

En del inbyggd programvara kan inte uppdateras i fält. Boot-ROM kan vara maskprogrammerat. Kod för säkert element kan vara leverantörskontrollerat. En radiomodul kanske inte erbjuder någon kunduppdateringsväg. Det gör inte att komponenten försvinner från CRA-dokumentationen.

CRA förväntar sig att sårbarheter ska vara hanterbara via säkerhetsuppdateringar där det är tillämpligt. Om en hårdvarukomponent inte kan ta emot uppdateringar, dokumentera det faktum i HBOM:en och riskbedömningen.

Registrera:

• Uppdateringsstatus: fältuppdateringsbar, leverantören ansvarar, fabriksuppdatering eller oföränderlig.
• Orsak: ROM, engångsprogrammerbart minne, låst leverantörsmodul, certifieringsbegränsning eller ingen exponerad uppdateringskanal.
• Kompenserande kontroller: isolering, inaktiverad funktion, nätverksbegränsning, extra autentisering eller åtgärd på produktnivå.
• Åtgärdsväg: firmware-uppdatering, modulbyte, enhetsåterkallelse, kundmeddelande eller VEX not_affected-uttalande där den sårbara vägen inte är nåbar.
• Berört intervall: produktversion, PCB-revision, lot eller serienummerområde.

Om en exploaterbar sårbarhet inte kan åtgärdas eller begränsas kan CRA:s korrigeringsåtgärdsskyldigheter kräva korrigerande åtgärder, tillbakadragande eller återkallelse. HBOM:en bör ge dig det berörda produktintervallet innan det beslutet blir brådskande.

Komponentens EOL påverkar supportperioden

Produktens supportperiod är inte bara ett kundlöfte. Den är en del av CRA:s modell för sårbarhetshantering.

CRA gör det möjligt att beakta supportperioder för integrerade kärnkomponenter från tredje part vid fastställandet av produktens supportperiod. Den tekniska dokumentationen behöver sedan den information som används för att fastställa supportperioden. CRA:s vägledning om exempel på långlivad hårdvara inkluderar moderkort, mikroprocessorer, routrar, modem, switchar och industriella styrsystem, som ofta används i mer än fem år.

Det gör komponentens EOL till ett HBOM-fält, inte bara en inköpsnotering.

För kärnkomponenter, registrera:

• Leverantörens supportslutdatum: månad och år där tillgängligt.
• Datum för senaste firmware-version: det senaste datum leverantören levererade en säkerhetsrelevant firmware-uppdatering.
• Rådgivningskälla: PSIRT-sida, CSAF-flöde, e-postlista eller leverantörskontakt.
• Ersättningsväg: pinnkompatibel del, omdesignplan, beslut om sista inköp eller produkt-EOL-beslut.
• Avtalstäckning: om leverantörens patch- och meddelandeskyldigheter täcker din deklarerade produktsupportperiod.

Om en kärnmodul når supportens slut innan produkten gör det måste du fatta ett beslut innan produkten placeras på marknaden. Utöka leverantörens täckning, välj en annan del, begränsa produktens supportperiod där det är motiverat eller dokumentera en ersättningsplan.

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)

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:s vägledning för komponenttyper behandlar den fysiska enheten och programvaran som körs på den som separata komponenter. En processor eller kretsuppsättning bör representeras som en device, medan koden som körs på den bör representeras som firmware eller operating-system, beroende på fallet.

Denna vägledning stämmer direkt överens med CRA:s behandling: den fysiska enheten och dess firmware är relaterade men distinkta 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.

CycloneDX har också officiella cdx:device:*-egenskaper för hårdvarudetaljer som funktion, kortplacering, enhetstyp, serienummer, lotnummer och GS1-identifierare. Använd dessa namn där de passar. Om du lägger till anpassade egenskaper för uppdateringsbarhet eller säkerhetstillstånd, namnge dem tydligt så att läsare inte blandar ihop dem med den officiella CycloneDX-taxonomin.

Exempel: ESP32-enhet med firmware-stack

Exemplet nedan visar en realistisk hårdvarukomponent (ESP32-WROOM-32E), dess firmware (ESP-IDF) och ett bibliotek i firmwaren (mbedtls), allt i ett enda CycloneDX 1.6 eller senare dokument med beroendeförhållanden:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "device",
      "bom-ref": "device:esp32-wroom-32e",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "Wi-Fi and Bluetooth SoC module",
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf"
        }
      ],
      "properties": [
        { "name": "cdx:device:function", "value": "Wi-Fi and Bluetooth connectivity" },
        { "name": "cdx:device:deviceType", "value": "SMD module" },
        { "name": "example:firmware:updateable", "value": "vendor-supported" },
        { "name": "example:security:secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "firmware:esp-idf-4.4.1",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Espressif IoT Development Framework running on ESP32"
    },
    {
      "type": "library",
      "bom-ref": "library:mbedtls-2.28.0",
      "name": "mbedtls",
      "version": "2.28.0",
      "purl": "pkg:generic/mbedtls@2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "device:esp32-wroom-32e", "dependsOn": ["firmware:esp-idf-4.4.1"] },
    { "ref": "firmware:esp-idf-4.4.1", "dependsOn": ["library:mbedtls-2.28.0"] }
  ]
}

dependencies-arrayen gör förhållandet mellan hårdvara och firmware explicit. När mbedtls publicerar en CVE-patch kan du spåra vilken enhet som berörs och vilken firmware-version som ska uppdateras.

Exemplet utelämnar ett hårdvaru-CPE avsiktligen. CPE-strängar från National Vulnerability Database (NVD) är produktspecifika, och identifierare på modul- och die-nivå stämmer inte alltid överens. Lägg till ett cpe-fält bara när du har verifierat den exakta NVD-posten för komponenten. För formatjämförelse och verktygsval, se CycloneDX jämfört med SPDX.

Sårbarhetsmatchning för hårdvara skiljer sig åt

Programvarusårbarhetsskannrar matchar ofta med Package URL (PURL), Common Platform Enumeration (CPE) eller paketmetadata. Hårdvara är mer komplicerat.

PURL är byggt kring programvarupaketekosystem som npm, Maven, PyPI, Debian och RPM. Det är användbart för firmware-paket eller bibliotek där programvaran distribueras som ett paket. Det är inte rätt identifierare för ett fysiskt chip.

CPE kan representera hårdvara via part=h, och CycloneDX har ett cpe-fält på toppnivå för komponenter. Använd det när ett verifierat NVD CPE finns. Men förutsätt inte att varje chip, modul eller firmware-avbildning har ett.

För hårdvaruposter utan ett tillförlitligt CPE, håll matchningskedjan mänskligt läsbar:

• exakt tillverkarnamn
• tillverkarens artikelnummer
• hårdvarurevision eller steppning
• namn och version på firmware
• leverantörens säkerhetsmeddelande eller PSIRT-URL
• leverantörskontakt
• GS1-identifierare där tillgängligt, med den relevanta cdx:device:gs1:*-egenskapen

Övervaka sedan källorna som faktiskt publicerar säkerhetsmeddelanden om hårdvara och firmware: leverantörens PSIRT-sida, NVD, CISA Known Exploited Vulnerabilities, CISA ICS-meddelanden där relevant, och sektorspecifika flöden för industri-, medicin- eller radioprodukter. Använd VEX eller likvärdigt underlag när en komponent finns men den sårbara funktionen inte är nåbar i din produkt. För rapporteringsflödet, se CRA sårbarhets- och incidentrapportering.

Vad du bör fråga leverantörer och kontraktstillverkare

Tillverkaren ansvarar för komponentaktsamhet. För hårdvara innebär det att begära säkerhets- och livscykeldata innan delen låses in i produkten.

Be leverantörer och kontraktstillverkare om:

• Exakt levererad identitet: tillverkarens artikelnummer, hårdvarurevision, firmware-version och eventuella godkända substitutioner.
• Uppdateringsväg: om firmware är fältuppdateringsbar, leverantören ansvarar, fabriksuppdatering eller oföränderlig.
• Uppdateringssäkerhet: signering, autentisering, återrullningsskydd och detaljer om säker distribution.
• Supportdatum: komponentens EOL, sista inköpstillfälle, senaste firmware-version och supportslutdatum.
• Rådgivningskanal: PSIRT-sida, säkerhetspostlista, CSAF-flöde, supportportal eller namngiven kontakt.
• Status för kända sårbarheter: aktuella säkerhetsmeddelanden, åtgärdade firmware-versioner och eventuella VEX- eller CSAF-uttalanden.
• Produktionsspårbarhet: tillverkad BOM per produktionskörning, lot eller serienummerområde där substitutioner kan förekomma.
• Leveranskedjeväg: auktoriserad distributör eller originalkomponenttillverkarkälla där risk för förfalskning eller grå marknad är relevant.

En design-BOM räcker inte när en originaldesigntillverkare (ODM) eller kontraktstillverkare kan ersätta moduler under produktion. Du behöver den tillverkade komponentposten för de enheter du placerar på EU-marknaden.

Vad du gör nu

1. Sätt HBOM-tröskelvärdet: inkludera hårdvara som bearbetar, lagrar, sänder, startar upp, uppdaterar, upprätthåller säkerhet, exponerar serviceåtkomst eller påverkar dokumentation om supportperiod.
2. Begär leverantörsdata innan produktionssläpp: artikelnummer, revision, firmware-version, uppdateringsväg, kanal för säkerhetsmeddelanden och supportslutdatum.
3. Skapa ett CycloneDX 1.6 eller senare dokument med en type: device-post per hårdvarukomponent och en type: firmware-post per firmware-avbildning. Länka dem med dependencies.
4. Registrera uppdateringsbarhet och EOL för kärnkomponenter. Om en kärnmodul inte kan uppdateras eller når EOL innan din produktsupportperiod slutar, dokumentera begränsnings- eller ersättningsvägen.
5. Övervaka leverantörernas säkerhetsmeddelanden, NVD, CISA KEV och sektorflöden för varje kärnkomponent. CVE-databassökningar kan missa hårdvaru- och firmware-problem där identifierare är svaga.
6. Placera den enhetliga SBOM:en, inklusive hårdvaruposter, i din tekniska dokumentation, där den måste vara tillgänglig för marknadskontrollmyndigheter på begäran. Om du hellre inte vill hantera SBOM- och HBOM-inmatning manuellt över produktversioner hanterar CRA Evidence CycloneDX-inmatning och komponentspårning för hela ditt produktportfölj.