HBOM dla Zgodności CRA: Przewodnik po Zestawieniu Materiałów Sprzętowych

Podczas gdy SBOM (Software Bill of Materials) przyciąga najwięcej uwagi, produkty z elementami cyfrowymi często mają znaczące komponenty sprzętowe, każdy potencjalnie zawierający firmware z własnymi podatnościami. HBOM (Hardware Bill of Materials) zapewnia widoczność tych fizycznych komponentów i ich wbudowanego oprogramowania.

Ten przewodnik wyjaśnia HBOM w kontekście CRA.

Czym jest HBOM?

Definicja

Zestawienie Materiałów Sprzętowych (HBOM) to ustrukturyzowany inwentarz fizycznych komponentów w produkcie, zazwyczaj obejmujący:

• Identyfikację komponentów (numery części, producenci)
• Wersje/rewizje sprzętowe
• Wersje firmware (wbudowane w komponenty)
• Atrybuty istotne dla bezpieczeństwa
• Informacje o łańcuchu dostaw

HBOM vs. Tradycyjna BOM

TRADYCYJNA BOM (Produkcja):
Focus: Produkcja i zaopatrzenie
Zawartość: Części, ilości, dostawcy, koszty
Użycie: Produkcja, inwentarz, zakupy

HBOM (Zorientowana na bezpieczeństwo):
Focus: Bezpieczeństwo i przejrzystość
Zawartość: Komponenty, firmware, atrybuty bezpieczeństwa
Użycie: Zarządzanie podatnościami, bezpieczeństwo łańcucha dostaw

NAKŁADANIE SIĘ:
Obie wymieniają fizyczne komponenty
HBOM dodaje informacje istotne dla bezpieczeństwa
HBOM łączy z zawartością firmware/oprogramowania

HBOM vs. SBOM

SBOM:
- Komponenty oprogramowania
- Biblioteki i zależności
- Komponenty systemu operacyjnego
- Kod aplikacji

HBOM:
- Komponenty sprzętowe
- Chipy i moduły
- Firmware w komponentach
- Fizyczne funkcje bezpieczeństwa

RELACJA:
┌─────────────────────────────────────────────┐
│ Pełna Przejrzystość Produktu                │
│                                             │
│  ┌─────────────┐    ┌─────────────┐        │
│  │    SBOM     │    │    HBOM     │        │
│  │             │    │             │        │
│  │ Aplikacja   │    │ PCB         │        │
│  │ Biblioteki  │◄──►│ Chipy       │        │
│  │ OS          │    │ Moduły      │        │
│  │ Firmware*   │    │ Firmware*   │        │
│  └─────────────┘    └─────────────┘        │
│                                             │
│  *Firmware pojawia się w obu, to           │
│   oprogramowanie działające na sprzęcie   │
└─────────────────────────────────────────────┘

Dlaczego HBOM ma Znaczenie dla CRA

Wymagania CRA i Sprzęt

Chociaż CRA koncentruje się na "produktach z elementami cyfrowymi", te produkty są często urządzeniami sprzętowymi:

Definicja CRA Artykuł 3(1):

"'produkt z elementami cyfrowymi' oznacza produkt programowy lub sprzętowy i jego rozwiązania zdalnego przetwarzania danych..."

Sprzęt Zawiera Oprogramowanie:

• Mikrokontrolery mają firmware
• Chipy sieciowe mają wbudowany kod
• Moduły bezpieczeństwa mają oprogramowanie kryptograficzne
• Sensory mogą mieć firmware przetwarzający

Wymóg Śledzenia Podatności

CRA wymaga od producentów:

• Nie mieć znanych podatności możliwych do wykorzystania
• Obsługiwać podatności w komponentach produktu
• Dostarczać aktualizacje bezpieczeństwa

Dla produktów sprzętowych oznacza to:

• Śledzenie podatności w firmware komponentów
• Wiedzę, co znajduje się wewnątrz waszego sprzętu
• Zdolność do aktualizacji lub łagodzenia podatności komponentów

Identyfikowalność Łańcucha Dostaw

Artykuł 13(5) CRA wymaga odpowiedniej należytej staranności dla komponentów:

"Producenci zachowują należytą staranność przy integracji komponentów pozyskiwanych od stron trzecich..."

HBOM wspiera to dokumentując:

• Jakie komponenty są w waszym produkcie
• Kto je dostarcza
• Jakie wersje firmware są obecne
• Jakie funkcje bezpieczeństwa mają

Co Uwzględnić w HBOM

Podstawowe Informacje o Komponentach

STRUKTURA WPISU KOMPONENTU HBOM

IDENTYFIKACJA:
- Typ komponentu (MCU, moduł radiowy, sensor, itp.)
- Nazwa producenta
- Numer części / Model
- Rewizja sprzętowa

INFORMACJE O FIRMWARE:
- Wersja firmware
- Dostawca firmware (jeśli inny niż HW)
- Możliwość aktualizacji
- Stan znanych podatności

ATRYBUTY BEZPIECZEŃSTWA:
- Wsparcie secure boot
- Sprzętowy moduł bezpieczeństwa
- Odporność na manipulację
- Możliwości kryptograficzne
- Unikalny ID / numer seryjny

ŁAŃCUCH DOSTAW:
- Bezpośredni dostawca
- Kraj pochodzenia (jeśli znany)
- Status końca życia

Kategorie Komponentów do Śledzenia

KATEGORIE KOMPONENTÓW HBOM

PRZETWARZANIE:
- Główny procesor / MCU
- Ko-procesory
- FPGA / logika programowalna
- Procesory aplikacyjne

ŁĄCZNOŚĆ:
- Moduły WiFi
- Moduły Bluetooth
- Modemy komórkowe
- Kontrolery Ethernet
- Radia LoRa / Zigbee / Thread

BEZPIECZEŃSTWO:
- TPM / Elementy bezpieczne
- Sprzętowe moduły bezpieczeństwa
- Akceleratory crypto
- Pamięć bezpieczna

PRZECHOWYWANIE:
- Pamięć Flash
- EEPROM
- Kontrolery kart SD

SENSORY:
- Sensory środowiskowe
- Sensory ruchu
- Sensory biometryczne
- Sensory obrazowania

ZASILANIE:
- Układy zarządzania zasilaniem
- Zarządzanie baterią

INTERFEJS:
- Kontrolery wyświetlacza
- Kontrolery USB
- Kodeki audio

Rozważania o Głębokości

POZIOMY GŁĘBOKOŚCI HBOM

POZIOM 1: Główne Komponenty
- Główny procesor
- Moduły łączności
- Elementy bezpieczeństwa
- Komponenty z aktualizowalnym firmware

POZIOM 2: Komponenty Drugorzędne
- Wspierające układy scalone
- Sensory
- Chipy pamięci
- Zarządzanie zasilaniem

POZIOM 3: Komponenty Pasywne/Proste
- Zazwyczaj NIE w HBOM
- Rezystory, kondensatory
- Proste złącza
- Komponenty nieprogramowalne

REKOMENDACJA DLA CRA:
Focus na Poziom 1 (krytyczny)
Uwzględnij Poziom 2 jeśli wykonalne
Poziom 3 rzadko istotny dla bezpieczeństwa

Opcje Formatu HBOM

CycloneDX HBOM

CycloneDX natywnie wspiera komponenty sprzętowe:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:...",
  "version": 1,
  "metadata": {
    "component": {
      "type": "device",
      "name": "Smart Sensor Pro",
      "version": "2.0"
    }
  },
  "components": [
    {
      "type": "device",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": {
        "name": "Espressif Systems"
      },
      "description": "Moduł SoC WiFi+BT",
      "properties": [
        {
          "name": "firmware-version",
          "value": "4.4.1"
        },
        {
          "name": "secure-boot",
          "value": "supported"
        }
      ]
    }
  ]
}

Ujednolicony SBOM+HBOM

Najlepsza praktyka to często ujednolicona BOM łącząca oprogramowanie i sprzęt z ich zależnościami.

Tworzenie i Utrzymanie HBOM

Początkowe Tworzenie HBOM

PROCES TWORZENIA HBOM

KROK 1: INWENTARYZACJA SPRZĘTU
- Przegląd schematu / BOM od inżynierii
- Identyfikacja komponentów programowalnych
- Zanotowanie komponentów z firmware

KROK 2: ZBIERANIE INFORMACJI
- Karty katalogowe producentów
- Numery części i rewizje
- Wersje firmware od dostawców
- Informacje o funkcjach bezpieczeństwa

KROK 3: OCENA ISTOTNOŚCI DLA BEZPIECZEŃSTWA
- Czy komponent ma firmware?
- Czy firmware może być aktualizowany?
- Czy obsługuje funkcje bezpieczeństwa?
- Czy jest podłączony do sieci?

KROK 4: STRUKTURYZACJA DANYCH
- Wybór formatu (CycloneDX rekomendowany)
- Wprowadzenie informacji o komponentach
- Połączenie z SBOM firmware gdzie stosowne
- Dokumentacja atrybutów bezpieczeństwa

KROK 5: WALIDACJA
- Weryfikacja krzyżowa z BOM inżynieryjną
- Weryfikacja wersji firmware
- Potwierdzenie informacji od dostawców

Ciągła Konserwacja

PROCES KONSERWACJI HBOM

WYZWALACZ: Rewizja Sprzętowa
- Aktualizacja wpisów komponentów
- Zanotowanie zmian wersji
- Aktualizacja wersji firmware

WYZWALACZ: Aktualizacja Firmware
- Aktualizacja wersji firmware w HBOM
- Połączenie ze zaktualizowanym SBOM dla firmware
- Śledzenie zmian statusu CVE

WYZWALACZ: Koniec Życia Komponentu
- Oznaczenie statusu komponentu
- Dokumentacja planu zastąpienia
- Ocena wpływu na bezpieczeństwo

WYZWALACZ: Odkryta Podatność
- Sprawdzenie HBOM dla dotkniętych komponentów
- Ocena możliwości wykorzystania
- Planowanie remediacj

REGULARNA PRZEGLĄD:
- Kwartalne sprawdzenie dokładności HBOM
- Roczny przegląd łańcucha dostaw
- Monitorowanie EOL komponentów

Lista Kontrolna HBOM

LISTA KONTROLNA WDROŻENIA HBOM

INWENTARZ:
[ ] Wszystkie komponenty programowalne zidentyfikowane
[ ] Wersje firmware udokumentowane
[ ] Funkcje bezpieczeństwa zanotowane
[ ] Dostawcy zarejestrowani

FORMAT:
[ ] Standardowy format wybrany (CycloneDX rekomendowany)
[ ] Schemat zwalidowany
[ ] Połączony z SBOM gdzie stosowne
[ ] Kontrolowany wersyjnie

PROCES:
[ ] Proces tworzenia udokumentowany
[ ] Wyzwalacze aktualizacji zdefiniowane
[ ] Odpowiedzialność przypisana
[ ] Harmonogram przeglądów ustalony

INTEGRACJA:
[ ] Włączony do dokumentacji technicznej
[ ] Połączony z zarządzaniem podatnościami
[ ] Część wymagań dla dostawców
[ ] Dostępny dla audytów

KONSERWACJA:
[ ] Zmiany komponentów śledzone
[ ] Aktualizacje firmware odzwierciedlone
[ ] Status EOL monitorowany
[ ] Regularne przeglądy dokładności

Jak CRA Evidence Pomaga

CRA Evidence wspiera zarządzanie HBOM:

• Ujednolicona BOM: Zarządzaj SBOM i HBOM razem
• Śledzenie komponentów: Śledź komponenty sprzętowe przez produkty
• Linkowanie firmware: Łącz sprzęt z SBOM firmware
• Korelacja podatności: Dopasuj CVE do komponentów sprzętowych
• Integracja dokumentacji technicznej: Włącz HBOM do dokumentacji zgodności

Rozpocznij swoją zgodność CRA na app.craevidence.com.

Powiązane Artykuły

• SBOM dla Zgodności z CRA: Kompletny Przewodnik po Software Bill of Materials -- Dowiedz się, jak tworzyć i zarządzać SBOM, obowiązkowym uzupełnieniem HBOM.
• Plik Techniczny CRA: Co Zawrzeć i Jak Przygotować -- Zrozum, jak HBOM wpisuje się w całościową dokumentację techniczną CRA.

Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. W celu uzyskania konkretnych wskazówek dotyczących zgodności, skonsultuj się z wykwalifikowanym prawnikiem.