HBOM: sprzętowy wykaz komponentów w CRA

SBOM wymienia biblioteki i pakiety oprogramowania. Nie powie jednak, czy moduł radiowy w produkcie jest poza wsparciem, czy bootloader można zaktualizować ani która partia używała zamiennego zestawu chipów.

To zadanie Sprzętowego Wykazu Komponentów (HBOM). CRA nie używa pojęcia „HBOM", lecz produkty sprzętowe, firmware, należyta staranność wobec komponentów zewnętrznych i inwentaryzacja komponentów SBOM wskazują na tę samą praktyczną potrzebę: wiedzieć, jaki sprzęt i oprogramowanie układowe znajdują się w produkcie, i wiedzieć, czy można działać w przypadku pojawienia się podatności.

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 ogranicza się do bibliotek open source. Procesor na PCB, moduł bezprzewodowy na płytce rozwojowej albo bezpieczny element w bramie IoT mogą zawierać firmware, ustawienia bezpieczeństwa i daty wsparcia. Zarządzanie tym ryzykiem bez wylistowania tych elementów jest niemożliwe.

Obowiązek SBOM to miejsce, gdzie ta dokumentacja zwykle trafia. CRA zobowiązuje producentów do identyfikowania i dokumentowania komponentów oraz podatności, w tym za pomocą czytelnego maszynowo SBOM obejmującego co najmniej zależności najwyższego poziomu. Moduł ESP32 wnosi więc do rejestru komponentów zarówno fizyczny moduł, jak i jego stos firmware. HBOM jest praktycznym narzędziem do uchwycenia tej sprzętowej części inwentaryzacji.

Okresy wsparcia to element tego samego obrazu. CRA pozwala uwzględniać okresy wsparcia podstawowych komponentów zewnętrznych. Dokumentacja techniczna musi następnie zawierać informacje użyte do ustalenia okresu wsparcia produktu. Jeśli zestaw chipów lub moduł kończy wsparcie przed upływem okresu wsparcia produktu, HBOM jest miejscem, gdzie ten fakt powinien po raz pierwszy stać się widoczny.

Jak HBOM wygląda w rzeczywistym łańcuchu dostaw

Importer z UE kupuje podłączoną bramę od producenta ODM z Shenzhen. Importer nie potrzebuje każdego rezystora. Potrzebuje danych o budowie, które zmieniają ryzyko cybernetyczne: moduł radiowy, bazowy firmware, status wsparcia i zatwierdzone zamienniki.

Kluczowa różnica to zapis rzeczywistego wykonania. Projektowy BOM wskazuje, co zespół inżynieryjny zamierzał użyć. HBOM powinien też uchwycić to, co fabryka faktycznie wysłała.

HBOM a SBOM: porównanie

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

Co uwzględnić i gdzie się zatrzymać

CRA nie podaje ustawowego wykazu pól HBOM. Nie wymaga też wylistowania każdej pasywnej części fizycznej. Poziom bazowy inwentaryzacji komponentów ustala próg zależności najwyższego poziomu dla SBOM, a strona sprzętowa powinna stosować tę samą logikę ryzyka.

Kryterium jest następujące: wylistuj sprzęt, który może zmienić ryzyko cybernetyczne produktu, status podatności, ścieżkę aktualizacji lub dokumentację okresu wsparcia.

Zacznij od komponentów pełniących jedno z tych zadań:

• Przetwarzają dane: główne procesory, SoC, mikrokontrolery, FPGA i ASICi związane z bezpieczeństwem.
• Przechowują kod lub tajemnice: flash, eMMC, układy TPM (Trusted Platform Module), bezpieczne elementy i kontrolery pamięci.
• Przesyłają dane: moduły Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, komórkowe i GNSS.
• Uruchamiają lub aktualizują produkt: menedżery rozruchu, bootloadery, UEFI, BIOS, firmware kontrolera zarządzania płytą główną (BMC) i kontrolery aktualizacji.
• Egzekwują bezpieczeństwo: akceleratory kryptograficzne, sprzętowe korzenie zaufania, magazyny kluczy i bezpieczne enklawy.
• Udostępniają dostęp do usług: produkcyjne porty debugowania, JTAG, UART, SWD lub interfejsy zarządzania, w przypadku których stan blokady produkcyjnej ma znaczenie.

Pasywne części, takie jak zwykłe rezystory i kondensatory, zazwyczaj nie wchodzą do HBOM, chyba że mają funkcję bezpieczeństwa, tożsamość cyfrową, oprogramowanie układowe lub znane ryzyko substytucji. Test praktyczny jest prosty: jeśli podatność, komunikat bezpieczeństwa, powiadomienie o EOL lub zamiana dostawcy dla danej części zmieniłyby decyzję o ryzyku produktu, wylistuj ją.

Kategorie sprzętu o wysokim priorytecie

Poniższe kategorie nie stanowią ustawowego wykazu. To wpisy, które z największym prawdopodobieństwem będą istotne w dokumentacji CRA, ponieważ zawierają firmware, klucze, interfejsy lub zależności od wsparcia dostawcy.

Dla każdego wpisu odnotuj co najmniej: nazwę komponentu, producenta, wersję sprzętową lub stepping oraz wersję firmware tam, gdzie ma zastosowanie. Połącz każdy wpis sprzętowy z odpowiadającym wpisem firmware za pomocą relacji zależności CycloneDX.

Warstwy firmware, o których często się zapomina

Pojedyncze pole „wersja firmware" często jest zbyt płytkie. Wiele produktów zawiera kilka warstw firmware o różnych właścicielach, ścieżkach aktualizacji i źródłach podatności.

Do często pomijanych warstw należą:

• Firmware rozruchowy: boot ROM, bootloader, menedżer rozruchu i konfiguracja bezpiecznego rozruchu.
• Firmware radiowy: Wi-Fi, Bluetooth, pasmo bazowe komórkowe, Zigbee, Thread, LoRaWAN i NFC firmware.
• Firmware platformy: UEFI, BIOS, BMC, opcjonalne ROM i mikrokod CPU. NIST SP 800-193 traktuje firmware platformy jako podstawowy sprzęt i oprogramowanie układowe potrzebne do uruchomienia i działania systemu.
• Firmware kontrolerów: kontrolery pamięci, karty sieciowe, kontrolery zasilania, koncentratory czujników i kontrolery wbudowane.
• Firmware bezpieczeństwa: firmware TPM, systemy operacyjne bezpiecznych elementów, aplety bezpiecznych elementów, obrazy środowiska zaufanego wykonania (TEE) i firmware HSM.
• Logika programowalna: bitstreamsy FPGA i konfiguracja ASIC lub FPGA związana z bezpieczeństwem.
• Binarne pakiety dostawcy: pakiety firmware dostarczone przez SDK, dołączone do obrazu produktu, lecz utrzymywane przez dostawcę chipa lub modułu.

Każda warstwa powinna być osobnym komponentem, gdy ma własną wersję, ścieżkę aktualizacji, opiekuna lub źródło komunikatów bezpieczeństwa. To pozwala odpowiedzieć na przydatne pytanie: które dokładnie wersje produktu są objęte tym komunikatem bezpieczeństwa dotyczącym firmware?

Pola, które czynią HBOM przydatnym

Ustawowy próg jest węższy niż przydatny HBOM. Nie wszystkie pola poniżej są obowiązkowe na podstawie CRA. To dokumentacja, która pozwala obsługiwać podatności, zmiany dostawców i decyzje o okresie wsparcia bez zaczynania od zera.

Jak firmware wpisuje się w definicję oprogramowania z CRA

Firmware bywa traktowany jako osobna kategoria, inna niż sprzęt i oprogramowanie. W pracy z CRA traktuj firmware jako oprogramowanie, ponieważ jest kodem komputerowym działającym wewnątrz elektronicznego systemu informacyjnego.

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.

Gdy firmware nie może być aktualizowany

Część firmware nie może być aktualizowana w terenie. Boot ROM może być programowany maską. Kod bezpiecznego elementu może być kontrolowany przez dostawcę. Moduł radiowy może nie udostępniać klientowi ścieżki aktualizacji. Nie sprawia to, że komponent znika z dokumentacji CRA.

CRA oczekuje, że podatności będą możliwe do usunięcia za pomocą aktualizacji zabezpieczeń, tam gdzie ma to zastosowanie. Jeśli komponent sprzętowy nie może otrzymywać aktualizacji, odnotuj ten fakt w HBOM i ocenie ryzyka.

Odnotuj:

• Status aktualizacji: aktualizowalny w terenie, tylko przez dostawcę, tylko w fabryce lub niezmienny.
• Przyczyna: ROM, pamięć jednorazowo programowalna, zablokowany moduł dostawcy, ograniczenie certyfikacji lub brak widocznego kanału aktualizacji.
• Środki wyrównawcze: izolacja, wyłączona funkcja, ograniczenie sieci, dodatkowe uwierzytelnianie lub ograniczenie na poziomie produktu.
• Ścieżka reakcji: aktualizacja firmware, wymiana modułu, odzyskanie jednostki, komunikat dla klienta lub oświadczenie VEX not_affected, gdy ścieżka podatności jest nieosiągalna.
• Zakres dotkniętych: wersja produktu, rewizja PCB, partia lub zakres numerów seryjnych.

Jeśli podatność możliwa do wykorzystania nie może być naprawiona ani ograniczona, obowiązki CRA w zakresie działań naprawczych mogą wymusić środki naprawcze, wycofanie z obrotu lub odzyskanie produktu. HBOM powinien wskazywać zakres dotkniętych produktów, zanim ta decyzja stanie się pilna.

EOL komponentu a okres wsparcia

Okres wsparcia produktu to nie tylko obietnica wobec klienta. Jest częścią modelu obsługi podatności CRA.

CRA pozwala uwzględnić okresy wsparcia zintegrowanych podstawowych komponentów zewnętrznych przy ustalaniu okresu wsparcia produktu. Dokumentacja techniczna musi następnie zawierać informacje użyte do ustalenia tego okresu wsparcia. Wskazówki CRA dotyczące przykładów długo używanego sprzętu obejmują płyty główne, mikroprocesory, routery, modemy, przełączniki i przemysłowe systemy sterowania, które są często używane przez ponad pięć lat.

To sprawia, że EOL komponentu jest polem HBOM, a nie tylko notatką zakupową.

Dla podstawowych komponentów odnotuj:

• Data końca wsparcia dostawcy: miesiąc i rok, jeśli dostępne.
• Data ostatniej wersji firmware: najpóźniejsza data, w której dostawca dostarczył aktualizację firmware istotną dla bezpieczeństwa.
• Źródło komunikatów bezpieczeństwa: strona PSIRT, feed CSAF, lista mailingowa lub kontakt z dostawcą.
• Ścieżka wymiany: część kompatybilna pinami, plan przeprojektowania, decyzja o ostatnim zakupie lub decyzja o EOL produktu.
• Pokrycie umowne: czy obowiązki dostawcy w zakresie łatek i powiadomień obejmują zadeklarowany okres wsparcia produktu.

Jeśli podstawowy moduł kończy wsparcie przed produktem, decyzję należy podjąć przed wprowadzeniem na rynek. Możliwości to: rozszerzyć pokrycie dostawcy, wybrać inną część, ograniczyć okres wsparcia produktu tam, gdzie jest to uzasadnione, lub udokumentować plan wymiany.

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)

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 CycloneDX dotyczące typów komponentów traktują fizyczne urządzenie i oprogramowanie na nim działające jako osobne komponenty. Procesor lub zestaw chipów należy reprezentować jako device, a kod na nim działający jako firmware lub operating-system, zależnie od przypadku.

Te wskazówki bezpośrednio odpowiadają podejściu CRA: fizyczne urządzenie i jego firmware 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 lub nowszej pozwala utrzymać SBOM i HBOM w jednym dokumencie oraz spełnia wymogi TR-03183.

CycloneDX oferuje też oficjalne właściwości cdx:device:* dla szczegółów sprzętowych, takich jak funkcja, lokalizacja na płytce, typ urządzenia, numer seryjny, numer partii i identyfikatory GS1. Używaj tych nazw tam, gdzie pasują. Jeśli dodajesz właściwości niestandardowe dla aktualizowalności lub stanu bezpieczeństwa, nadaj im wyraźną przestrzeń nazw, aby czytelnicy nie mylili ich z oficjalną taksonomią CycloneDX.

Przykład: urządzenie ESP32 ze stosem firmware

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

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

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

Przykład celowo pomija sprzętowe CPE. Ciągi CPE bazy danych NVD są specyficzne dla produktu, a identyfikatory na poziomie modułu i matrycy nie zawsze są zgodne. Dodaj pole cpe tylko po zweryfikowaniu dokładnego wpisu NVD dla komponentu. Porównanie formatów i wybór narzędzi: CycloneDX vs SPDX.

Dopasowywanie podatności sprzętowych: inne podejście

Skanery podatności oprogramowania często dopasowują według Package URL (PURL), Common Platform Enumeration (CPE) lub metadanych pakietu. W przypadku sprzętu jest to bardziej skomplikowane.

PURL jest zbudowany wokół ekosystemów pakietów oprogramowania, takich jak npm, Maven, PyPI, Debian i RPM. Jest przydatny dla pakietów firmware lub bibliotek, gdzie oprogramowanie jest dystrybuowane jak pakiet. Nie jest właściwym identyfikatorem dla fizycznego chipa.

CPE może reprezentować sprzęt poprzez part=h, a CycloneDX ma pole cpe na poziomie komponentu. Używaj go, gdy istnieje zweryfikowane CPE z NVD. Nie zakładaj jednak, że każdy chip, moduł lub obraz firmware je ma.

Dla wpisów sprzętowych bez wiarygodnego CPE zachowaj ślad dopasowania czytelny dla człowieka:

• dokładna nazwa producenta
• numer katalogowy producenta
• rewizja sprzętowa lub stepping
• nazwa i wersja firmware
• komunikat bezpieczeństwa dostawcy lub URL PSIRT
• kontakt z dostawcą
• identyfikator GS1, jeśli dostępny, z użyciem odpowiedniej właściwości cdx:device:gs1:*

Następnie monitoruj źródła, które faktycznie publikują komunikaty bezpieczeństwa dotyczące sprzętu i firmware: stronę PSIRT dostawcy, NVD, CISA Known Exploited Vulnerabilities, komunikaty CISA ICS tam, gdzie jest to właściwe, oraz branżowe kanały informacyjne dla produktów przemysłowych, medycznych lub radiowych. Używaj VEX lub równoważnej dokumentacji, gdy komponent jest obecny, ale podatna funkcja nie jest osiągalna w produkcie. Opis procesu zgłaszania: Zgłaszanie podatności i incydentów CRA.

Co pytać dostawców i producentów kontraktowych

Producent ponosi odpowiedzialność za należytą staranność wobec komponentów. W przypadku sprzętu oznacza to żądanie danych bezpieczeństwa i cyklu życia przed ostatecznym wybraniem części.

Od dostawców i producentów kontraktowych należy żądać:

• Dokładna tożsamość wysłanego komponentu: numer katalogowy producenta, rewizja sprzętowa, wersja firmware i wszelkie zatwierdzone zamienniki.
• Ścieżka aktualizacji: czy firmware jest aktualizowalny w terenie, tylko przez dostawcę, tylko w fabryce lub niezmienny.
• Bezpieczeństwo aktualizacji: szczegóły podpisywania, uwierzytelniania, ochrony przed cofnięciem i bezpiecznej dystrybucji.
• Daty wsparcia: EOL komponentu, ostatni zakup, ostatnie wydanie firmware i data końca wsparcia.
• Kanał komunikatów bezpieczeństwa: strona PSIRT, lista mailingowa bezpieczeństwa, feed CSAF, portal wsparcia lub wskazana osoba kontaktowa.
• Status znanych podatności: bieżące komunikaty bezpieczeństwa, wersje firmware z poprawkami i wszelkie oświadczenia VEX lub CSAF.
• Identyfikowalność produkcyjna: powykonawczy BOM na serię produkcyjną, partię lub zakres numerów seryjnych, gdzie mogą wystąpić zamiany.
• Ścieżka łańcucha dostaw: autoryzowany dystrybutor lub źródło od oryginalnego producenta komponentu, gdzie ryzyko podróbek lub szarego rynku ma znaczenie.

Projektowy BOM nie wystarczy, gdy oryginalny producent projektu (ODM) lub producent kontraktowy może zamieniać moduły podczas produkcji. Producent potrzebuje powykonawczego rejestru komponentów dla jednostek wprowadzanych na rynek UE.

Co zrobić dalej

1. Ustal próg HBOM: uwzględnij sprzęt, który przetwarza, przechowuje, przesyła, uruchamia, aktualizuje, egzekwuje bezpieczeństwo, udostępnia dostęp do usług lub wpływa na dokumentację okresu wsparcia.
2. Zażądaj danych od dostawcy przed wydaniem produkcyjnym: numer katalogowy, rewizja, wersja firmware, ścieżka aktualizacji, kanał komunikatów bezpieczeństwa i data końca wsparcia.
3. Sporządź dokument CycloneDX 1.6 lub nowszy z jednym wpisem type: device na komponent sprzętowy i jednym wpisem type: firmware na obraz firmware. Połącz je relacjami dependencies.
4. Odnotuj aktualizowalność i EOL dla podstawowych komponentów. Jeśli podstawowy moduł nie może być aktualizowany lub osiąga EOL przed upływem okresu wsparcia produktu, udokumentuj ograniczenie lub ścieżkę wymiany.
5. Monitoruj komunikaty bezpieczeństwa dostawców, NVD, CISA KEV i branżowe kanały informacyjne dla każdego podstawowego komponentu. Wyszukiwania w bazie CVE mogą pomijać problemy ze sprzętem i firmware, gdzie identyfikatory są słabe.
6. Umieść ujednolicony SBOM, w tym wpisy sprzętowe, w dokumentacji technicznej, gdzie musi być gotowy do udostępnienia organom nadzoru rynku na żądanie. Jeśli ręczne zarządzanie danymi SBOM i HBOM w kolejnych wersjach produktów jest niecelowe, CRA Evidence obsługuje intake CycloneDX i śledzenie komponentów w całym portfolio produktów.