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. Rozporządzenie (UE) 2024/2847 definiuje „produkt z elementami cyfrowymi" w Artykule 3 ust. 1, obejmując nim produkty sprzętowe, a „sprzęt" w Artykule 3 ust. 5 jako „fizyczny elektroniczny system informacyjny lub jego części zdolne do przetwarzania, przechowywania lub przekazywania danych cyfrowych". Rozporządzenie nie używa nigdzie pojęcia „HBOM", jednak obowiązek dokumentowania i zachowania należytej staranności wobec wszystkich komponentów, w tym sprzętowych, wynika wprost z Artykułu 3 ust. 1, Artykułu 13 ust. 5 i Załącznika I, Część II, pkt 1.
Najważniejsze informacje
- HBOM to ustrukturyzowana inwentaryzacja fizycznych komponentów produktu, obejmująca oprogramowanie układowe każdego komponentu
- CRA nie nakłada obowiązku sporządzenia HBOM pod tą nazwą, jednak Artykuł 3 ust. 1 rozciąga zakres CRA na produkty sprzętowe, Artykuł 13 ust. 5 wymaga zachowania należytej staranności wobec wszystkich komponentów zewnętrznych, a Załącznik I, Część II, pkt 1 nakazuje dokumentowanie „komponentów zawartych w produktach z elementami cyfrowymi"
- Oprogramowanie układowe jest oprogramowaniem w rozumieniu Artykułu 3 ust. 4: „składa się z kodu komputerowego" i musi figurować w SBOM obok wpisów dotyczących komponentów sprzętowych
- CycloneDX to praktyczny, ujednolicony format:
type: deviceobejmuje fizyczny sprzęt,type: firmwareobejmuje oprogramowanie wbudowane, a oba typy mogą współistnieć w jednym dokumencie CycloneDX 1.6 - BSI TR-03183 nie obejmuje obecnie koncepcji HBOM; wszystkie trzy części dotyczą wykazów komponentów oprogramowania i zgłoszeń podatności
- Komisja może określić format i elementy SBOM w drodze aktów wykonawczych (Artykuł 13 ust. 24), jednak w tekście CRA nie istnieje analogiczny nakaz dotyczący odrębnego formatu HBOM
Dlaczego HBOM ma znaczenie w kontekście CRA
Zakres CRA jest szerszy niż „produkty programowe". Artykuł 3 ust. 1 definiuje „produkt z elementami cyfrowymi" jako:
„produkt z elementami cyfrowymi" oznacza oprogramowanie komputerowe lub sprzęt komputerowy oraz powiązane z nimi rozwiązania w zakresie zdalnego przetwarzania danych, w tym komponenty oprogramowania lub sprzętu, które są oddzielnie wprowadzane do obrotu
Artykuł 3 ust. 5 definiuje „sprzęt" jako:
„sprzęt" oznacza fizyczny elektroniczny system informacyjny lub jego części zdolne do przetwarzania, przechowywania lub przekazywania danych cyfrowych
Ta definicja obejmuje procesor na płytce PCB, moduł bezprzewodowy na płytce deweloperskiej i bezpieczny element w bramce IoT. Komponenty te nie są marginalnym zagadnieniem w kontekście zgodności z CRA, lecz wchodzą bezpośrednio w jego zakres.
Artykuł 13 ust. 5 nakłada na producenta konkretny obowiązek:
W celu wypełnienia obowiązku określonego w ust. 1 producenci dokładają należytej staranności przy integrowaniu z produktami z elementami cyfrowymi komponentów pochodzących od stron trzecich, aby komponenty takie nie naruszały cyberbezpieczeństwa produktu z elementami cyfrowymi, w tym w przypadku zintegrowania komponentów wolnego i otwartego oprogramowania, które nie zostały udostępnione na rynku w ramach działalności komercyjnej
Producent nie może zachować należytej staranności wobec komponentów sprzętowych, których nie zinwentaryzował. Załącznik I, Część II, pkt 1 idzie dalej: SBOM musi obejmować „podatności i komponenty zawarte w produktach z elementami cyfrowymi". Produkt zawierający moduł ESP32 zawiera stos oprogramowania układowego tego modułu jako swój komponent. HBOM jest praktycznym narzędziem do uchwycenia tej inwentaryzacji.
CRA nie zawiera przepisu nakazującego sporządzenia dokumentu zwanego HBOM. Obowiązek dotyczy inwentaryzacji wszystkich komponentów, w tym sprzętowych, w ramach istniejącego obowiązku prowadzenia SBOM wynikającego z Załącznika I, Część II, pkt 1. HBOM to praktyczne podejście do wypełnienia tego obowiązku w przypadku produktów intensywnie korzystających ze sprzętu, nie zaś odrębny dokument zgodności.
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 |
| Nakaz CRA | Wyraźny, Załącznik I, Część II, pkt 1 | Pośredni, poprzez zakres Artykułu 3 ust. 1 i należytą staranność z Artykułu 13 ust. 5 |
| 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 | Załącznik VII, pkt 2(b) i pkt 8 | 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. Inwentaryzacji należy poddać każdy komponent fizyczny, który przetwarza, przechowuje lub przesyła dane cyfrowe, bo właśnie to obejmuje Artykuł 3 ust. 5.
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.
Znaczna część podatności urządzeń IoT dotyczy oprogramowania układowego, które nigdy nie jest aktualizowane po wysyłce. Dokumentowanie wersji oprogramowania układowego w HBOM jest warunkiem wstępnym monitorowania i usuwania podatności. Nie można śledzić tego, czego się nie wylistowało. Szerszy kontekst: typowe błędy w SBOM.
Jak oprogramowanie układowe wpisuje się w definicję oprogramowania z CRA
Oprogramowanie układowe (firmware) bywa traktowane jako odrębna kategoria, inna niż sprzęt i oprogramowanie. CRA nie tworzy tej trzeciej kategorii. Artykuł 3 ust. 4 definiuje oprogramowanie jako:
„oprogramowanie" oznacza część elektronicznego systemu informacyjnego, która składa się z kodu komputerowego
Oprogramowanie układowe składa się z kodu komputerowego. Tym samym, na gruncie CRA, jest oprogramowaniem. To nie jest interpretacja wykraczająca poza tekst; wynika wprost z definicji.
Słowo „firmware" nie pojawia się nigdzie w tekście rozporządzenia CRA. Jest to celowe: definicja z Artykułu 3 ust. 4 jest wystarczająco szeroka, by je objąć, więc osobna klasyfikacja nie jest potrzebna.
Praktyczna implikacja jest prosta. Oprogramowanie układowe uruchomione na chipie w produkcie stanowi komponent programowy produktu z elementami cyfrowymi. Musi figurować w inwentaryzacji komponentów. Jeśli zawiera podatność, podlega ona tym samym obowiązkom zgłaszania wynikającym z Artykułu 14, co każda podatność w oprogramowaniu.
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 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.
Najczęściej zadawane pytania
Czy CRA wprost wymaga sporządzenia HBOM?
Nie, CRA nigdzie nie używa pojęcia „HBOM". Obowiązek dokumentowania komponentów sprzętowych wynika pośrednio: Artykuł 3 ust. 1 obejmuje produkty sprzętowe zakresem CRA, Artykuł 13 ust. 5 wymaga należytej staranności wobec wszystkich komponentów zewnętrznych, a Załącznik I, Część II, pkt 1 nakazuje dokumentowanie „komponentów zawartych w produktach z elementami cyfrowymi". HBOM to praktyczne podejście do wypełnienia tych obowiązków w przypadku produktów sprzętowych, nie zaś nazwany wymóg regulacyjny.
Czy oprogramowanie układowe w chipie Bluetooth jest oprogramowaniem w rozumieniu CRA?
Tak. Artykuł 3 ust. 4 definiuje oprogramowanie jako „część elektronicznego systemu informacyjnego, która składa się z kodu komputerowego". Oprogramowanie układowe składa się z kodu komputerowego, więc mieści się w tej definicji. Słowo „firmware" nie pojawia się w CRA i nie musi, bo definicja z Artykułu 3 ust. 4 już je obejmuje. Każde oprogramowanie układowe uruchomione na komponencie w produkcie jest komponentem programowym produktu z elementami cyfrowymi i musi figurować w inwentaryzacji komponentów.
Czy BSI TR-03183 obejmuje HBOM?
Nie. BSI TR-03183 składa się z trzech części: Część 1 (Wymagania ogólne), Część 2 (SBOM) i Część 3 (Zgłoszenia podatności). Żadna z nich nie obejmuje HBOM jako strukturalnej koncepcji. TR-03183-2 wspomina oprogramowanie układowe wyłącznie jako typ pliku komponentu w ramach wykazu komponentów oprogramowania, korzystając z pola software_additionalPurpose: firmware. Jeśli dokumentowanie komponentów sprzętowych dla celów zgodności z CRA jest konieczne, producent musi posłużyć się własną oceną inżynierską i natywnymi typami sprzętowymi CycloneDX, nie zaś wytycznymi TR-03183 w tej części inwentaryzacji.
Która wersja CycloneDX obsługuje zarówno komponenty programowe, jak i sprzętowe?
type: device jest dostępny w CycloneDX od wersji v1.1 (2018 lub wcześniej). type: firmware dodano w v1.2, wydanej w maju 2020 r. Oba typy są zatem dostępne w każdej nowszej wersji CycloneDX. W pracach związanych z CRA należy wybrać v1.6 lub nowszą: BSI TR-03183-2 v2.1.0 (sierpień 2025 r.) podniósł minimalny wymóg CycloneDX do 1.6, a najnowsze stabilne wydanie to 1.7 (październik 2025 r.). W żadnej wersji CycloneDX nie istnieje type: hardware; dla komponentów fizycznych należy używać type: device.