Sprzętowy wykaz komponentów (HBOM) a zgodność z CRA

SBOM uwzględnia biblioteki i pakiety oprogramowania, ale co z oprogramowaniem układowym wypalonym w chipie Bluetooth lub mikrokontrolerem stanowiącym serce urządzenia? Sprzętowy wykaz komponentów (HBOM) rozszerza inwentaryzację komponentów o fizyczne układy scalone, moduły i uruchomione na nich oprogramowanie układowe. CRA nie używa pojęcia „HBOM”, ale produkty sprzętowe, osobno wprowadzane na rynek komponenty sprzętowe, należyta staranność wobec komponentów zewnętrznych i inwentaryzacja komponentów SBOM prowadzą do tej samej praktycznej potrzeby: wiedzieć, jaki sprzęt i firmware znajdują się w produkcie.

Dlaczego HBOM ma znaczenie w kontekście CRA

Zakres CRA jest szerszy niż same produkty programowe. Produkty sprzętowe, osobno sprzedawane komponenty sprzętowe i firmware wewnątrz tych komponentów należą do problemu inwentaryzacji produktu.

Ma to znaczenie dla producentów, ponieważ należyta staranność wobec komponentów nie kończy się na bibliotekach open source. Procesor na PCB, moduł łączności na płytce rozwojowej albo secure element w bramie IoT mogą zawierać firmware i wersje istotne dla bezpieczeństwa. Bez inwentaryzacji nie da się zarządzać tym ryzykiem.

Obowiązek SBOM jest prawnym miejscem dla tej pracy: wymaga komponentów zawartych w produktach z elementami cyfrowymi. Moduł ESP32 wprowadza więc do rejestru komponentów zarówno fizyczny moduł, jak i jego stos firmware. HBOM jest praktycznym narzędziem do uchwycenia tej inwentaryzacji.

HBOM a SBOM: porównanie

Wymiar	SBOM	HBOM
Zakres podstawowy	Biblioteki, pakiety i frameworki programowe	Komponenty fizyczne: układy scalone, moduły, bezpieczne elementy
Pokrycie oprogramowania układowego	Może zawierać wpisy type: firmware	Oprogramowanie układowe wymienione obok nadrzędnego komponentu sprzętowego
Rola zgodności	Wyraźny wymóg inwentaryzacji komponentów	Praktyczne rozszerzenie tej samej inwentaryzacji dla produktów sprzętowych
Pokrycie przez BSI TR-03183	Tak, TR-03183-2 (v2.1.0, 2025)	Nie, żadna z trzech części TR-03183 nie obejmuje HBOM
Wsparcie CycloneDX	Wszystkie wersje	type: device od v1.1; type: firmware od v1.2 (maj 2020)
Typowe narzędzie do generowania	Syft, Trivy, cdxgen	Ręcznie lub na podstawie kart katalogowych dostawców sprzętu; brak dojrzałych narzędzi do automatycznego generowania
Miejsce w dokumentacji technicznej	Dokumentacja techniczna, sekcja inwentaryzacji komponentów	Ta sama lokalizacja, jako część ujednoliconej inwentaryzacji komponentów

Pełny opis obowiązku dotyczącego SBOM: Wymogi CRA dotyczące SBOM. Porównanie formatów: CycloneDX vs SPDX.

Co uwzględnić w HBOM

Poniższe kategorie odzwierciedlają praktyczną ocenę inżynierską, a nie ustawowy katalog. CRA nie wymienia kategorii komponentów sprzętowych. Uwzględnij każdy fizyczny komponent, który przetwarza, przechowuje lub przesyła dane cyfrowe, ponieważ takie komponenty mogą wpływać na cyberbezpieczeństwo.

Komponenty przetwarzające i łączności

Wpisy o najwyższym priorytecie, ponieważ ich oprogramowanie układowe jest najprawdopodobniej wektorem podatności:

• Główny procesor aplikacyjny lub SoC (nazwa, producent, wersja/stepping, wersja oprogramowania układowego)
• Moduły bezprzewodowe: Wi-Fi, Bluetooth, Zigbee, LoRa, komórkowe (każdy z wersją oprogramowania układowego)
• Dodatkowe mikrokontrolery obsługujące określone podsystemy

Komponenty zabezpieczające

Sprzęt zabezpieczający wymaga osobnych wpisów, ponieważ podatności w tej warstwie niosą największe konsekwencje:

• Układy TPM (Trusted Platform Module)
• Bezpieczne elementy i sprzętowe moduły bezpieczeństwa
• Akceleratory kryptograficzne
• Każdy komponent przechowujący klucze, certyfikaty lub poświadczenia w stanie spoczynku

Komponenty pamięciowe

Pamięć ma znaczenie, gdy przechowuje kod, konfigurację lub dane wrażliwe:

• Pamięć flash przechowująca bootloader lub oprogramowanie układowe
• Moduły eMMC lub SD, jeśli służą do trwałego przechowywania danych
• EEPROM przechowujące konfigurację urządzenia

Dla każdego wpisu należy odnotować co najmniej: nazwę komponentu, producenta, wersję sprzętową lub stepping oraz wersję oprogramowania układowego (jeśli dotyczy). Każdy wpis sprzętowy należy powiązać z odpowiednim wpisem oprogramowania układowego za pomocą relacji zależności CycloneDX.

Jak oprogramowanie układowe wpisuje się w definicję oprogramowania z CRA

Oprogramowanie układowe bywa traktowane jako osobna kategoria, inna niż sprzęt i oprogramowanie. W pracy z CRA traktuj firmware jako oprogramowanie, ponieważ jest kodem komputerowym działającym w elektronicznym systemie informacyjnym.

Praktyczna konsekwencja jest prosta. Firmware działający na chipie w produkcie jest komponentem programowym produktu z elementami cyfrowymi. Musi znaleźć się w inwentaryzacji komponentów. Jeśli zawiera podatność, ta podatność przechodzi przez ten sam proces obsługi i zgłaszania co każda inna podatność oprogramowania.

CycloneDX jako ujednolicony format SBOM i HBOM

CycloneDX obsługuje komponenty sprzętowe i programowe w jednym dokumencie. Odrębny format pliku dla HBOM nie jest potrzebny.

Historia typów komponentów (istotna dla sprzętu)

Wersja CycloneDX	Data wydania	Istotna zmiana
1.1 lub wcześniejsza	2018	Wprowadzenie type: device
1.2	2020-05-26	Dodanie type: firmware
1.5	2023-06-26	Dodanie type: device-driver
1.6	2024	Aktualne zalecenie zgodności z CRA
1.7	Październik 2025	Najnowsze stabilne wydanie

W żadnej wersji CycloneDX nie istnieje typ type: hardware. Właściwy typ dla fizycznego układu scalonego lub modułu to type: device.

Wskazówki ze specyfikacji CycloneDX v1.2 dotyczące modelowania sprzętu z oprogramowaniem układowym:

"A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device."

Te wskazówki bezpośrednio odpowiadają podejściu CRA: fizyczne urządzenie i jego oprogramowanie układowe to powiązane, lecz odrębne komponenty, każdy z własną tożsamością i wersją.

Dla nowych prac nad HBOM należy wybrać CycloneDX 1.6. BSI TR-03183-2 v2.1.0 (2025-08-20) podniósł minimalny wymóg CycloneDX do wersji 1.6. Wyrównanie do 1.6 pozwala utrzymać SBOM i HBOM w jednym dokumencie oraz spełnia wymogi TR-03183.

Przykład: urządzenie ESP32 ze stosem oprogramowania układowego

Poniższy przykład przedstawia realistyczny komponent sprzętowy (ESP32-WROOM-32E), jego oprogramowanie układowe (ESP-IDF) i bibliotekę w tym oprogramowaniu (mbedtls), wszystkie w jednym dokumencie CycloneDX 1.6 lub nowszym z relacjami zależności:

{
  "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"] }
  ]
}

Tablica dependencies jawnie określa relację między sprzętem a oprogramowaniem układowym. Gdy mbedtls opublikuje poprawkę dla CVE, można prześledzić, które urządzenie jest zagrożone i którą wersję oprogramowania układowego zaktualizować.

Porównanie formatów i wybór narzędzi: CycloneDX vs SPDX.

Co zrobić dalej