Klient chce SBOM: przewodnik dla dostawców komponentów

Ten przewodnik jest dla dostawców w produkcyjnym łańcuchu dostaw: ECU, wyświetlaczy, sterowników, bramek, napędów, stosów wbudowanego Linuxa i modułów firmware. Jeśli sprzedają Państwo oprogramowanie, a klient przysłał jednorazową prośbę, proszę zacząć od jak odpowiedzieć na prośbę klienta o SBOM, gdzie opisano ten przypadek.

Dlaczego OEM-owie pytają właśnie teraz

Prośba OEM o SBOM to zwykle jego własne przepisy, które docierają do Państwa przez umowę. To, o które przepisy chodzi, decyduje, co OEM musi mieć i ile z tego przechodzi na Państwa.

Cyber Resilience Act

Zgodnie z Cyber Resilience Act, rozporządzeniem (UE) 2024/2847, produkt z elementami cyfrowymi obejmuje także komponenty oprogramowania lub sprzętu wprowadzane do obrotu oddzielnie (art. 3 pkt 1). Komponent, który sprzedają Państwo samodzielnie w UE, jest odrębnym produktem, a Państwo są jego producentem, z własnym obowiązkiem SBOM: załącznik I część II pkt 1 wymaga SBOM w powszechnie używanym, nadającym się do odczytu maszynowego formacie, obejmującego co najmniej zależności najwyższego poziomu produktów. Jeśli komponent jest przeznaczony do integracji z innymi produktami, Państwa instrukcje muszą też zawierać informacje potrzebne integratorowi do spełnienia zasadniczych wymagań (załącznik II pkt 8 lit. f)).

OEM ma też obowiązki, które docierają do Państwa. Musi zachować należytą staranność przy integrowaniu komponentów pochodzących od stron trzecich (art. 13 ust. 5), a gdy wykryje podatność w zintegrowanym komponencie, musi zgłosić ją osobie lub podmiotowi, który ten komponent produkuje lub utrzymuje (art. 13 ust. 6). Wytyczne Komisji dotyczące CRA z lipca 2026 mówią, że dowodem należytej staranności może być dokumentacja uzyskana od producenta komponentu, i nie wspominają o SBOM; w praktyce SBOM to często właśnie ta dokumentacja, o którą proszą OEM-owie. Obowiązki zgłaszania obowiązują od 11 września 2026, a rozporządzenie w całości od 11 grudnia 2027. Części zamienne wykonane według tej samej specyfikacji co komponenty, które zastępują, są wyłączone (art. 2 ust. 6). O reszcie rozporządzenia: zob. czym jest CRA i przewodnik po CRA.

Pojazdy

CRA nie ma zastosowania do produktów objętych rozporządzeniem (UE) 2019/2144, czyli rozporządzeniem w sprawie homologacji typu pojazdów (art. 2 ust. 2 lit. c)). Komponenty do pojazdów homologowanych trafiają na rynek na podstawie przepisów dotyczących pojazdów, a te nigdy nie wspominają o SBOM.

Regulamin ONZ nr 155 (cyberbezpieczeństwo) wymaga, by producent gromadził i weryfikował informacje w całym łańcuchu dostaw, aby wykazać, że ryzyka związane z dostawcami są identyfikowane i zarządzane (5.1.1(a)), by pokazał, jak jego system zarządzania cyberbezpieczeństwem będzie zarządzał zależnościami od zakontraktowanych dostawców, usługodawców lub jednostek organizacyjnych producenta (7.2.2.5), oraz by identyfikował i zarządzał ryzykami związanymi z dostawcami dla homologowanego typu pojazdu (7.3.2).
Regulamin ONZ nr 156 (aktualizacje oprogramowania) wymaga, by wszystkie początkowe i zaktualizowane wersje oprogramowania były jednoznacznie identyfikowalne (7.1.1.2), a dla każdego RX Software Identification Number (RXSWIN) prowadzenia podlegającego audytowi rejestru opisującego całe oprogramowanie istotne dla danego RXSWIN (7.1.2.3).
ISO/SAE 21434 organizuje prace nad cyberbezpieczeństwem między OEM a dostawcą jako działania rozproszone, z podziałem uzgodnionym w cybersecurity interface agreement.
Auto-ISAC SBOM Informational Report (luty 2025) zawiera wytyczne samej branży.

W motoryzacji SBOM pojawia się jako wymóg umowny, a nie prawny.

Automatyka przemysłowa

IEC 62443-4-1 ma zastosowanie do dostawców produktów dla przemysłowych systemów automatyki i sterowania. Nie wymienia SBOM, ale practice 6, zarządzanie problemami związanymi z bezpieczeństwem (DM-1 do DM-6), i practice 7, zarządzanie aktualizacjami bezpieczeństwa (SUM-1 do SUM-5, w tym SUM-3, „Dependent component or operating system security update documentation”), to miejsca, w których SBOM służy jako dowód.

Maszyny

Rozporządzenie w sprawie maszyn (UE) 2023/1230 stosuje się od 20 stycznia 2027 i nie wspomina o SBOM. Jego zasadnicze wymagania dotyczące ochrony przed uszkodzeniem (załącznik III, 1.1.9) wymagają, by oprogramowanie krytyczne dla zgodności było zidentyfikowane i chronione, by maszyna mogła identyfikować zainstalowane na niej oprogramowanie niezbędne do bezpiecznego działania oraz by gromadzone były dowody ingerencji w to oprogramowanie. Maszyny z elementami cyfrowymi podlegają też CRA, inaczej niż pojazdy homologowane, i dlatego producenci maszyn już teraz proszą dostawców o SBOM. Zob. CRACI dla producentów maszyn i przemysłowy IoT.

NIS2 i certyfikowani klienci

Jeśli dostarczają Państwo produkty podmiotom kluczowym lub ważnym, na przykład w branży półprzewodników, art. 21 ust. 2 lit. d) NIS2 wymaga, by Państwa klient zajął się bezpieczeństwem łańcucha dostaw. Nie wymienia SBOM. Klienci zamieniają go w kwestionariusze, a kontrole 5.21 i 8.8 z załącznika A do ISO/IEC 27001 to miejsca, w których SBOM służy jako dowód. Zob. SBOM jako dowód dla ISO 27001, SOC 2 i NIS2.

Porównanie reżimów

Reżim	Dotyczy	Czy wymienia SBOM?	Co dociera do dostawcy
Cyber Resilience Act	Produktów z elementami cyfrowymi na rynku UE, w tym komponentów sprzedawanych oddzielnie	Tak, załącznik I część II (1)	Bezpośrednio, jeśli wprowadzają Państwo komponent do obrotu; przez należytą staranność OEM (art. 13 ust. 5) i zgłoszenia podatności (art. 13 ust. 6)
UN R155 i R156	Producentów pojazdów ubiegających się o homologację typu	Nie	Zarządzanie ryzykiem dostawców (R155 7.2.2.5, 7.3.2) i identyfikacja oprogramowania (R156), przez umowy
ISO/SAE 21434	Inżynierii cyberbezpieczeństwa pojazdów drogowych, OEM-ów i dostawców	Nie w publicznym opisie	Działania rozproszone i cybersecurity interface agreement
IEC 62443-4-1	Dostawców produktów dla przemysłowych systemów automatyki i sterowania	Nie	Bezpośrednio, jeśli są Państwo dostawcą produktu; SBOM-y służą jako dowód dla DM i SUM
Rozporządzenie w sprawie maszyn	Maszyn i produktów powiązanych na rynku UE	Nie	Identyfikacja i ochrona oprogramowania (załącznik III 1.1.9); CRA stosuje się równolegle
NIS2	Podmiotów kluczowych i ważnych	Nie	Kwestionariusze bezpieczeństwa łańcucha dostaw i postanowienia umowne (art. 21 ust. 2 lit. d), art. 21 ust. 3)

Niezależnie od drogi klient potrzebuje tego samego: dokładnego SBOM dla każdej dostarczanej wersji oprogramowania.

O co zwykle proszą OEM-owie

Wymagania różnią się między OEM-ami, ale zbiegają się do tej samej listy. Proszę sprawdzić z nią swój SBOM przed pierwszą dostawą.

Wymaganie	Typowe oczekiwanie
Format	CycloneDX lub SPDX, JSON lub XML, z minimalną wersją specyfikacji. BSI TR-03183-2 ustala CycloneDX 1.6 lub nowszy albo SPDX 3.0.1 lub nowszy.
Pola	Zgodne z CISA 2026 Minimum Elements lub BSI TR-03183-2: autor, znacznik czasu, a dla każdego komponentu nazwa, wersja, producent i identyfikatory
Identyfikatory	Package URL wszędzie, gdzie ekosystem go ma, CPE tam, gdzie nie, aby komponenty można było dopasować do baz podatności
Licencje	Identyfikatory licencji SPDX. Specjalista OEM ds. licencji czyta je, by ocenić copyleft i inne ryzyka licencyjne.
Skróty	Skrót każdego dostarczonego pliku binarnego, aby OEM mógł potwierdzić, że SBOM opisuje otrzymany plik. BSI wymaga SHA-512.
Głębokość	Zależności przechodnie, nie tylko najwyższy poziom
Szczegółowość	Jeden SBOM na dostarczoną wersję oprogramowania lub numer części
Dostarczanie i reakcja	Kanał dostarczania i czasy odpowiedzi na pytania o podatności

Wielu OEM-ów sprawdza to automatycznie przy odbiorze. Co sprawdzi Państwa klient i jakich narzędzi użyje, opisuje lista kontrolna jakości SBOM, a jak pola wyglądają w pliku, pokazują przykłady SBOM.

Państwa SBOM, gdy open source jest niewiele lub wcale

ECU lub sterownik typu bare-metal z własnościowym firmware z modelowego generowania kodu ma uczciwy SBOM, który może być krótki: własnościowa aplikacja, Państwa bootloader, biblioteki lub kalibracja producenta krzemu i ewentualny open source, np. biblioteka kryptograficzna. To poprawna odpowiedź. Zasady:

Komponenty własnościowe proszę wymieniać z własnymi identyfikatorami: nazwa, wersja i Państwo jako producent.
Proszę podać znane niewiadome, np. bibliotekę dostawcy, której zawartości Państwo nie widzą.
Nigdy nie należy sztucznie powiększać SBOM, by wyglądał na dokładny, ani pomijać biblioteki open source, bo jest mała.

W przypadku wyświetlaczy i bramek z Linuxem jest odwrotnie: setki lub tysiące komponentów, w tym jądro, bootloader i pakiety systemu bazowego (zob. urządzenia podłączone do sieci). SBOM, który wymienia tylko Państwa aplikację i kilka bibliotek, to pierwsza rzecz, którą oznaczy zespół odbiorczy. Jeśli budują Państwo z Yocto, zob. dlaczego skanery pomijają to, co jest w buildach Yocto.

Umowy: co uzgodnić przed pierwszą dostawą

Postanowienie	Dlaczego to ważne
Objęte produkty i wersje oprogramowania	Żeby nikt później nie spierał się, czy wariant lub wydanie serwisowe wymagało SBOM
Format i wersja specyfikacji	Ich pipeline odbiorczy może odrzucić wszystko inne
Pola i rama, której przestrzegają	„BSI TR-03183-2 v2.1.0” lub „CISA 2026 Minimum Elements” da się przetestować; „kompletnego SBOM” nie
Zdarzenie wyzwalające dostawę	Każde wydanie, każda wersja oprogramowania wysłana do OEM i każda poprawka
Kanał dostarczania	Portal dostawców OEM, bezpieczna wymiana plików lub e-mail w ramach NDA
Poufność	NDA lub istniejąca umowa dostawy, wskazująca SBOM jako informację poufną
Ograniczenia użycia	Tylko zarządzanie podatnościami i zgodność, bez dalszego udostępniania bez zgody
Powiadamianie o podatnościach, w obie strony	OEM zgłasza podatności wykryte w Państwa komponencie (CRA art. 13 ust. 6); Państwo zgłaszają mu swoje
Oczekiwania wobec VEX	Jaki format i jak szybko oceniają Państwo nową CVE
Przechowywanie	Jak długo przechowują Państwo SBOM każdej wersji, w dopasowaniu do okresu wsparcia produktu
Dokładność i znane niewiadome	Uczciwe postanowienie o tym, co SBOM może, a czego nie może obejmować, chroni obie strony

SBOM Sharing Primer CISA opisuje przypadek motoryzacyjny tak samo: prośby o SBOM byłyby włączane do standardowych umów o wymianie informacji, np. umowy o zachowaniu poufności, cybersecurity interface agreement lub development interface agreement.

Udostępnianie bez ujawniania własności intelektualnej

SBOM to nie Państwa kod źródłowy. Wymienia nazwy komponentów, wersje, producentów, licencje, skróty i relacje. Nie zawiera Państwa kodu, algorytmów, danych kalibracyjnych ani projektu.

CRA nie zobowiązuje producentów do publikowania SBOM (motyw 77). Trafia on do organu nadzoru rynku na uzasadniony wniosek (załącznik VII pkt 8).
Wytyczne CISA dotyczące udostępniania opisują typowe kanały dla oprogramowania własnościowego: e-mail w ramach NDA, portal dostawców klienta lub bezpieczną wymianę dokumentów albo własny portal z kontrolą dostępu, przy czym poufność i dostęp regulują umowy.
Praktyczne opcje: jeden pełny SBOM na OEM w ramach umowy; identyfikatory części własnościowych, które nie ujawniają wewnętrznych nazw projektów; oraz osobny dokument VEX, aby móc zaktualizować status podatności bez ponownego wysyłania SBOM.

Jak często i co dzieje się po dostawie

Nowy SBOM dla każdej dostarczanej wersji oprogramowania, pod tym samym identyfikatorem, który OEM wgrywa lub rejestruje. W pojazdach wiąże się to z identyfikacją oprogramowania według R156.
Poprawiony SBOM, gdy znajdą Państwo błąd w wysłanym.
Oświadczenie VEX lub biuletyn, gdy ocenili Państwo podatność.

Pytanie uzupełniające, „czy dotyczy Państwa CVE-X?”, przychodzi wraz z następną dużą podatnością. Proszę być gotowym odpowiedzieć na nie dla każdej dostarczonej wersji, co jest możliwe tylko wtedy, gdy zachowali Państwo SBOM każdej z nich.

VEX: czego klient będzie oczekiwał w następnej kolejności

Dokument VEX mówi, czy produkt jest dotknięty podatnością. Minimum Requirements for VEX CISA (kwiecień 2023) definiują cztery statusy: not_affected, affected, fixed i under_investigation. Oświadczenie not_affected powinno podawać jedno z pięciu uzasadnień albo, w przeciwnym razie, impact statement:

component_not_present
vulnerable_code_not_present
vulnerable_code_not_in_execute_path
vulnerable_code_cannot_be_controlled_by_adversary
inline_mitigations_already_exist

Oświadczenie affected wymaga action statement: co klient powinien zrobić. VEX występuje w trzech formatach: profil VEX w CSAF 2.0, CycloneDX VEX i OpenVEX. Wyjście SPDX 3.0 z Yocto domyślnie zawiera dane VEX (zmienna SPDX_INCLUDE_VEX).

Przykład. Wyświetlacz oparty na Linuxie jest dostarczany z OpenSSL 3.0.8. CVE-2023-0464 opisuje nadmierne zużycie zasobów przy weryfikacji łańcuchów certyfikatów X.509 zawierających ograniczenia polityk. Przetwarzanie polityk jest domyślnie wyłączone, a oprogramowanie wyświetlacza nigdy go nie włącza. Dostawca wysyła przykładowe oświadczenie OpenVEX:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Powtarzalne tworzenie SBOM

Jak Państwo budują	Realistyczny sposób na SBOM
Oprogramowanie budowane w CI	Generowanie SBOM w buildzie, który wytwarza dostarczane oprogramowanie, i przechowywanie go razem z wydaniem
Wbudowany Linux oparty na Yocto	Własne wyjście SPDX z Yocto (`create-spdx`), sprawdzone pod kątem tego, co pomija, lub zapis buildu Yocto
Firmware bare-metal z narzędzi modelowych	Biblioteka lub narzędzie generatora, nigdy edytor tekstu, utrzymywane z każdym wydaniem i walidowane przed wysłaniem
Integrowane pliki binarne stron trzecich	Prośba do własnego dostawcy o jego SBOM; analiza binarna jako zastępstwo, dopóki nie dotrze

Niezależnie od drogi proszę zwalidować plik przed wysłaniem. Lista kontrolna jakości SBOM wymienia walidatory, które klient prawdopodobnie uruchomi, CycloneDX vs SPDX pomaga w wyborze formatu, a standaryzacja generowania SBOM opisuje, jak ujednolicić go między zespołami.

Gdzie pasuje CRACI

Dla dostawców, którzy budują w GitHub Actions, CRACI zastępuje runnery hostowane przez GitHub i rejestruje SBOM z każdego buildu, więc każda dostarczona wersja już go ma.

SBOM wymienia to, co build faktycznie pobrał, w tym zależności przechodnie, z package URL dla każdego pakietu i zadeklarowaną licencją każdego komponentu.
SBOM każdego zadania ma stan kompletności, więc wiedzą Państwo, co wysyłają, zanim to wyślą.
SBOM-y eksportują się jako CycloneDX lub SPDX, a CRACI obsługuje VEX.
Monitorowane SBOM-y są oceniane ponownie, gdy publikowane są nowe podatności, a historia buildów pokazuje, które buildy zawierały podatną zależność, w ramach Państwa okresu przechowywania.
Buildy Yocto działają na runnerach CRACI i są udokumentowane.
Można dodawać SBOM-y stron trzecich, aby kupowane komponenty były monitorowane razem z Państwa własnymi buildami.

Kiedy CRACI nie jest odpowiedzią

Nie mają Państwo CI albo budują w GitLab, Jenkins lub na serwerze buildów. CRACI obsługuje obecnie tylko GitHub Actions; inne systemy CI są w planach rozwoju.
Firmware jest generowany z narzędzi modelowych bez pobierania pakietów. Rejestrator buildu niewiele tu wnosi.
Muszą Państwo udostępniać SBOM-y wielu OEM-om w portalu lub podpisywać SBOM-y. CRACI nie oferuje żadnej z tych funkcji.
Buildy muszą działać na Państwa własnej infrastrukturze. Runnery hostowane przez klienta są w planach rozwoju.
Klient chce dowodu na zarządzanie bezpieczeństwem w Państwa organizacji, np. certyfikatu ISO 27001 lub odpowiedzi na kwestionariusz NIS2. SBOM jest dowodem dla części tego, a nie certyfikacją. Własny certyfikat ISO 27001 CRACI obejmuje usługę CRACI, nie Państwa.

SBOM dla dostawców: najczęściej zadawane pytania

Mój klient, OEM, poprosił o SBOM. Czy mam obowiązek go dostarczyć?

Często wymaga tego umowa, a nie prawo. Jeśli sami wprowadzają Państwo do obrotu na rynku UE komponent z elementami cyfrowymi, Cyber Resilience Act wymaga Państwa własnego SBOM. W przeciwnym razie obowiązek spoczywa na OEM, który przenosi go na Państwa przez należytą staranność i umowę dostawy.

Czy CRA dotyczy komponentów, które sprzedaję producentowi?

Jeśli wprowadzają Państwo komponent do obrotu w UE oddzielnie, tak: art. 3 pkt 1 obejmuje komponenty oprogramowania lub sprzętu wprowadzane do obrotu oddzielnie. Jeśli trafia on na rynek tylko w produkcie OEM, producentem jest OEM i musi zachować należytą staranność wobec Państwa komponentu (art. 13 ust. 5). Komponenty pojazdów homologowanych są poza CRA (art. 2 ust. 2 lit. c)).

Czy UN R155 lub ISO/SAE 21434 wymaga SBOM?

Nie. R155 nigdy nie wspomina o SBOM; wymaga od producenta pojazdu zarządzania ryzykami związanymi z dostawcami. ISO/SAE 21434 organizuje prace nad cyberbezpieczeństwem z dostawcami przez interface agreements. W motoryzacji SBOM-y pojawiają się jako wymóg umowny.

Jakiego formatu i jakich pól oczekuje OEM?

Zwykle CycloneDX lub SPDX w JSON lub XML, zgodnie z CISA 2026 Minimum Elements lub BSI TR-03183-2: autor i znacznik czasu, a dla każdego komponentu nazwa, wersja, producent, package URL lub CPE, licencja i skrót, wraz z zależnościami przechodnimi.

Jak często muszę wysyłać zaktualizowany SBOM?

Dla każdej dostarczanej wersji oprogramowania, przy każdej poprawce błędu oraz z oświadczeniem VEX lub biuletynem, gdy ocenili Państwo podatność. Zdarzenie wyzwalające proszę uzgodnić w umowie.

Czy udostępnienie SBOM ujawni naszą własność intelektualną?

Nie. SBOM wymienia nazwy komponentów, wersje, producentów, licencje, skróty i relacje, a nie kod źródłowy, algorytmy czy dane kalibracyjne. Proszę udostępniać go w ramach NDA lub umowy dostawy, z użyciem ograniczonym do zarządzania podatnościami i zgodności. CRA nie wymaga jego publikacji.

Czym jest VEX i czy klient o niego poprosi?

VEX mówi, czy produkt jest dotknięty podatnością: not_affected, affected, fixed lub under_investigation, z uzasadnieniem dla not_affected. Proszę spodziewać się takiej prośby po następnej szeroko nagłośnionej podatności w dostarczanym przez Państwa komponencie.

Nasz firmware ECU nie zawiera open source. Jak wygląda nasz SBOM?

Krótko i uczciwie: własnościowa aplikacja, bootloader, ewentualne biblioteki lub kalibracja producenta krzemu oraz ewentualny open source, np. biblioteka kryptograficzna, każdy z Państwa własnymi identyfikatorami, plus znane niewiadome. Bez sztucznego powiększania.

Klient chce SBOM: przewodnik dla dostawców komponentów i oprogramowania