Wymagania SBOM w ramach unijnego Cyber Resilience Act: Praktyczny Przewodnik

Lista materiałów oprogramowania (SBOM) stała się kamieniem węgielnym nowoczesnego bezpieczeństwa łańcucha dostaw oprogramowania. Zgodnie z unijnym Cyber Resilience Act (CRA), SBOM to nie tylko dobra praktyka — to wymóg regulacyjny. Ten przewodnik wyjaśnia, co producenci muszą wiedzieć o zgodności SBOM w ramach CRA.

Co CRA mówi o SBOM

CRA odnosi się do SBOM w kilku kluczowych obszarach:

Załącznik I: Wymagania Zasadnicze

"Producenci identyfikują i dokumentują podatności i komponenty zawarte w produktach, w tym sporządzając listę materiałów oprogramowania w powszechnie stosowanym formacie nadającym się do odczytu maszynowego."

To oznacza:

• SBOM są obowiązkowe, nie opcjonalne
• Muszą być w formacie nadającym się do odczytu maszynowego (nie PDF ani arkusze kalkulacyjne)
• Muszą obejmować wszystkie komponenty, w tym zależności przechodnie

Załącznik VII: Dokumentacja Techniczna

Dokumentacja techniczna musi zawierać informacje SBOM umożliwiające:

• Śledzenie podatności na poziomie komponentu
• Identyfikację dostawców
• Weryfikację zgodności licencji
• Planowanie końca życia produktu

Akceptowane Formaty SBOM

CRA wymaga formatów "powszechnie stosowanych i nadających się do odczytu maszynowego". W praktyce oznacza to:

Oba formaty są akceptowane, ale CycloneDX jest coraz bardziej preferowany dla przypadków użycia związanych z bezpieczeństwem ze względu na natywne wsparcie dla:

• Vulnerability Exploitability eXchange (VEX)
• Powiadomień bezpieczeństwa
• Grafów zależności

BSI TR-03183: Niemiecki Standard

Niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji (BSI) opublikował TR-03183, który zawiera szczegółowe wymagania jakościowe SBOM wykraczające poza minimum CRA. Kluczowe wymagania obejmują:

Pola Obowiązkowe

• Nazwa i wersja komponentu
• Informacje o dostawcy/producencie
• Unikalne identyfikatory (PURL, CPE)
• Relacje zależności
• Informacje o licencji

Wskaźniki Jakości

TR-03183 definiuje poziomy jakości:

Choć TR-03183 jest niemieckim standardem, staje się de facto punktem odniesienia jakości dla zgodności z CRA w całej UE.

Częste Błędy SBOM do Uniknięcia

1. Niepełne Drzewa Zależności

Wiele narzędzi przechwytuje tylko bezpośrednie zależności. CRA wymaga zależności przechodnich — komponentów, od których zależą twoje zależności.

Twój Produkt
├── Biblioteka A (bezpośrednia) ✓
│   ├── Biblioteka B (przechodnia) ← Często brakuje!
│   └── Biblioteka C (przechodnia) ← Często brakuje!
└── Biblioteka D (bezpośrednia) ✓

2. Brak Informacji o Wersji

SBOM bez dokładnych informacji o wersji jest prawie bezużyteczny do dopasowywania podatności. Upewnij się, że każdy komponent ma:

• Dokładne numery wersji (nie zakresy)
• Wartości hash dla komponentów binarnych
• Identyfikatory PURL gdzie to możliwe

3. Nieaktualne SBOM

SBOM wygenerowany podczas budowania, ale nigdy nieaktualizowany, tworzy fałszywe poczucie bezpieczeństwa. Wdróż:

• Integrację CI/CD dla automatycznego generowania SBOM
• Kontrolę wersji dla artefaktów SBOM
• Regularne wykrywanie odchyleń między kompilacjami

4. Ignorowanie Firmware i Hardware

Dla produktów z wbudowanymi komponentami pamiętaj o uwzględnieniu:

• Wersji i komponentów firmware
• Listy materiałów sprzętowych (HBOM) gdzie ma to zastosowanie
• Komponentów bootloadera i jądra

Zarządzanie Cyklem Życia SBOM

Zgodna praktyka SBOM wymaga ciągłego zarządzania:

Generowanie

Kod Źródłowy → System Budowania → Generowanie SBOM → Walidacja

Zintegruj generowanie SBOM ze swoim pipeline CI/CD używając narzędzi takich jak:

• Syft (CycloneDX/SPDX)
• Trivy (CycloneDX)
• cdxgen (CycloneDX)

Walidacja

Przed publikacją zwaliduj swój SBOM:

• Zgodność ze schematem (poprawny CycloneDX/SPDX)
• Kompletność (wszystkie komponenty uwzględnione)
• Dokładność (wersje odpowiadają rzeczywistości)

Przechowywanie i Dostęp

SBOM powinny być:

• Przechowywane bezpiecznie z kontrolą dostępu
• Zachowane przez okres wsparcia produktu (minimum 5 lat zgodnie z CRA)
• Dostępne do oceny zgodności
• Dostępne dla klientów downstream (dla produktów B2B)

Ciągły Monitoring

Połącz swój SBOM z bazami danych podatności:

• NVD (National Vulnerability Database)
• OSV (Open Source Vulnerabilities)
• GitHub Advisory Database
• CISA KEV (znane wykorzystywane podatności)

Praktyczne Kroki na Początek

1. Zbadaj swój obecny stan: Czy generujesz SBOM dzisiaj? Jaki format? Jakie pokrycie?

2. Wybierz swój format: CycloneDX dla fokusa na bezpieczeństwie, SPDX dla zgodności licencji (lub oba)

3. Zautomatyzuj generowanie: Integracja z CI/CD, nie procesy ręczne

4. Zwaliduj jakość: Sprawdź zgodność z wymaganiami TR-03183

5. Wdróż monitoring: Połącz SBOM ze skanowaniem podatności

6. Zaplanuj aktualizacje: Ustanów procesy utrzymania SBOM

Jak Pomaga CRA Evidence

CRA Evidence zapewnia kompleksowe zarządzanie SBOM:

• Upload i Walidacja: Wsparcie dla CycloneDX i SPDX z oceną jakości TR-03183
• Skanowanie Podatności: Automatyczne dopasowywanie do NVD, OSV i innych baz danych
• Śledzenie Wersji: Historia SBOM i wykrywanie odchyleń między wersjami produktu
• Eksport: Dołącz zwalidowane SBOM do dokumentacji technicznej Załącznika VII

Prawidłowe ustawienie praktyki SBOM jest fundamentalne dla zgodności z CRA. Zacznij budować te możliwości już teraz, aby być gotowym na termin 2027.

Powiązane Przewodniki

Generowanie: Dowiedz się, jak zautomatyzować tworzenie SBOM w naszym przewodniku generowania SBOM.

Jakość: Poznaj wymagania jakościowe SBOM w naszym przewodniku BSI TR-03183.

VEX: Uzupełnij swój SBOM o dane o podatnościach za pomocą dokumentów VEX.

Dokumentacja Techniczna: Zobacz, jak SBOM wpisują się w dokumentację techniczną CRA (Załącznik VII).

Ten artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania konkretnych wskazówek dotyczących zgodności skonsultuj się z wykwalifikowanym radcą prawnym.