SBOM (wykaz komponentów oprogramowania) — czego wymaga Cyber Resilience Act

Wykaz komponentów oprogramowania to nudny artefakt o nieproporcjonalnie dużych konsekwencjach. To lista: z jakich komponentów zbudowane jest oprogramowanie produktu, w jakich wersjach, od jakich dostawców, na jakich licencjach. Jeszcze niedawno była wewnętrzną wygodą zespołu inżynierskiego. Wraz z rozporządzeniem (UE) 2024/2847 — Cyber Resilience Act — staje się wymaganiem zasadniczym, i to takim, którego okazania mogą zażądać organy nadzoru rynku.

Powód jest prosty. Kiedy w powszechnie używanej bibliotece zostaje opublikowana podatność, liczy się jedno pytanie: czy nas to dotyczy? Bez wykazu komponentów odpowiedź kosztuje tygodnie ręcznej archeologii po repozytoriach i serwerach budujących. Z wykazem kosztuje jedno zapytanie. CRA zamienia tę operacyjną rzeczywistość w obowiązek prawny — i jak przy większości obowiązków dotyczących danych produktowych, rzecz znacznie mniej polega na jednorazowym napisaniu dokumentu, a znacznie bardziej na utrzymywaniu danych w zgodzie z rzeczywistością przez każde wydanie, przez dekadę. Tej samej dyscypliny wymaga cyfrowy paszport produktu w innych obszarach unijnego prawa produktowego.

Najważniejsze w skrócie

Obowiązek SBOM znajduje się w załączniku I części II CRA, wśród wymagań dotyczących obsługi podatności. Stosuje się w pełni od 11 grudnia 2027.
Próg prawny jest skromny: powszechnie używany, maszynowo czytelny format, obejmujący co najmniej zależności najwyższego poziomu, aktualizowany na bieżąco. Rozporządzenie nie wskazuje konkretnego formatu.
W praktyce oznacza to CycloneDX (OWASP, znormalizowany jako ECMA-424) albo SPDX (Linux Foundation, ISO/IEC 5962:2021). Znaczniki SWID (ISO/IEC 19770-2) to identyfikator na potrzeby zarządzania zasobami oprogramowania, a nie pełny wykaz zależności.
Nie ma obowiązku publikowania SBOM klientom. Trzeba go okazać organom nadzoru rynku na żądanie i stanowi on część dokumentacji technicznej z załącznika VII.
Dokumentację techniczną trzeba trzymać do dyspozycji organów przez co najmniej dziesięć lat od wprowadzenia produktu do obrotu albo przez okres wsparcia, jeśli jest dłuższy.
Niemiecka BSI TR-03183-2 idzie znacznie dalej niż próg CRA: wymaga rekurencyjnego rozwinięcia całego drzewa zależności, skrótów SHA-512 i określonego zestawu pól. Nie jest prawem wiążącym, ale to najbardziej konkretna opublikowana referencja — a kupujący coraz częściej się na nią powołują.
SBOM niepowiązany z konkretną wersją produktu niczego nie dowodzi. Wersjonowanie zamiast nadpisywania to cała istota rzeczy.
CRA nie wymaga SBOM w cyfrowym paszporcie produktu. Wymaga danych produktowych na poziomie wersji, które przetrwają dekadę — ten sam problem, rozwiązywany tym samym narzędziem.

Czym właściwie jest SBOM

Po odjęciu akronimu SBOM to inwentarz z informacją o pochodzeniu. Dla każdego komponentu, który trafia do wydanego produktu, zapisuje przynajmniej: jak komponent się nazywa, jaką ma wersję i kto go dostarczył. Lepsze wykazy dodają licencję, skrót kryptograficzny pozwalający jednoznacznie zidentyfikować komponent oraz relacje zależności — który komponent pociągnął za sobą który.

Najważniejsza różnica dotyczy głębokości. Wykaz najwyższego poziomu wymienia to, co kod deklaruje bezpośrednio: dwanaście bibliotek z pliku manifestu. Wykaz tranzytywny rozwija to, co te dwanaście ze sobą przynosi, i co przynoszą tamte, aż do liści drzewa. W rzeczywistych aplikacjach z dwunastu zadeklarowanych zależności rutynowo robi się kilkaset faktycznych. Podatności siedzą równie chętnie cztery poziomy niżej, co na samej górze — i właśnie dlatego różnica między progiem z CRA a zawartością użytecznego SBOM nie jest akademicka.

Druga różnica to moment powstania. SBOM wygenerowany z kodu źródłowego opisuje to, co zamierzyli programiści. SBOM wygenerowany z wyniku budowania opisuje to, co faktycznie zostało wydane — łącznie z komponentami wstrzykniętymi przez system budujący, bazowy obraz kontenera albo binarną paczkę dostawcy. Te dwa rozjeżdżają się częściej, niż zespoły się spodziewają, a dowodem jest tylko ten drugi.

Czego CRA wymaga — a czego nie

Załącznik I część II rozporządzenia (UE) 2024/2847 opisuje wymagania dotyczące obsługi podatności, które producent musi spełniać przez cały okres wsparcia. Pierwsze z nich to wykaz komponentów: producenci muszą zidentyfikować i udokumentować komponenty zawarte w produkcie, w tym poprzez sporządzenie wykazu komponentów oprogramowania w powszechnie używanym, maszynowo czytelnym formacie, obejmującego co najmniej zależności najwyższego poziomu, oraz utrzymywać go w aktualności.

Trzy elementy tego zdania warto przeczytać uważnie.

„Powszechnie używany, maszynowo czytelny format”. Rozporządzenie celowo nie wskazuje formatu. To standardowa praktyka w unijnym prawie produktowym: tekst prawny nazywa właściwość, a normy zharmonizowane uzupełniają szczegół techniczny. W praktyce pole zagęściło się do dwóch formatów i wybór każdego z nich da się obronić.

„Co najmniej zależności najwyższego poziomu”. To próg, nie cel. Prawo nie zobowiązuje do rozwinięcia pełnego drzewa tranzytywnego. Nie powstrzymuje też organu, jednostki certyfikującej ani dużego klienta korporacyjnego przed żądaniem więcej — i nie sprawia, że wykaz ograniczony do najwyższego poziomu jest użyteczny do celu, dla którego istnieje. Próg traktuj jako minimum zgodności, a drzewo tranzytywne jako wymóg operacyjny.

„Utrzymywać w aktualności”. Obowiązek jest ciągły i biegnie przez okres wsparcia. Wykaz sporządzony raz do akt technicznych i nigdy nieodtworzony rozjeżdża się z rzeczywistością przy pierwszym wydaniu poprawkowym.

Równie ważne jest to, czego CRA nie wymaga:

Brak obowiązku publikacji. Upublicznienie SBOM to decyzja handlowa. Obowiązek prawny brzmi: okazać organom nadzoru rynku na żądanie. Niektóre branże i duzi kupujący będą tego wymagać kontraktowo — to inna presja, nie prawna.
Brak narzuconego formatu i profilu. Żadnego nakazu CycloneDX kontra SPDX, żadnej minimalnej listy pól w samym rozporządzeniu.
Brak SBOM w paszporcie produktu. CRA nie tworzy paszportu, nośnika danych ani rejestru.

Formaty: CycloneDX, SPDX i SWID

	CycloneDX	SPDX	Znaczniki SWID
Pochodzenie	OWASP	Linux Foundation	ISO/IEC
Norma	ECMA-424	ISO/IEC 5962:2021	ISO/IEC 19770-2
Zaprojektowany do	bezpieczeństwa aplikacji	zgodności licencyjnej i pochodzenia	zarządzania zasobami oprogramowania
Typowa siła	procesy podatnościowe, CI/CD, VEX	poziom pliku i fragmentu kodu, zakupy	identyfikacja zainstalowanego oprogramowania
Pełny wykaz zależności	tak	tak	nie taki jest cel

CycloneDX wyrósł ze środowiska bezpieczeństwa aplikacji i od początku był budowany pod zastosowania bezpieczeństwa. Praktyczną przewagą jest ekosystem wokół niego: rozszerza się na wykazy sprzętowe, SaaS, uczenia maszynowego i kryptografii, a także niesie VEX — Vulnerability Exploitability eXchange — który pozwala stwierdzić, że znana podatność w wymienionym komponencie w twoim produkcie w ogóle nie jest możliwa do wykorzystania. Dla producenta z obowiązkami obsługi podatności z CRA możliwość powiedzenia „obecna, ale niewykorzystywalna, oto dlaczego” w formie maszynowo czytelnej jest warta bardzo dużo zaoszczędzonej pracy.

SPDX wywodzi się ze zgodności licencyjnej i niesie to dziedzictwo jako głębokość: potrafi opisać oprogramowanie aż do pojedynczych plików i fragmentów kodu, i jest naturalnym wyborem tam, gdzie wymaganie napędzają zakupy, przegląd prawny i dokumentacja formalna.

Znaczniki SWID pojawiają się w większości porównań formatów i w części oficjalnych wytycznych, ale rozwiązują inny problem — identyfikację oprogramowania zainstalowanego na maszynie. Nie zastępują wykazu zależności.

Uczciwa odpowiedź co do wyboru: oba wiodące formaty się do siebie zbliżają, narzędzia obsługują oba, konwertery istnieją. Wybierz ten, który twoja istniejąca linia narzędziowa generuje najbardziej niezawodnie, i wystandaryzuj się na nim. Zepsuty SBOM w „lepszym” formacie jest gorszy niż poprawny w którymkolwiek.

Pola danych — trzy punkty odniesienia

CRA daje próg. Trzy opublikowane dokumenty mówią, co poważny SBOM faktycznie zawiera.

Referencja niemiecka: BSI TR-03183-2

Niemiecki federalny urząd ds. bezpieczeństwa informacji publikuje Wytyczną techniczną TR-03183: Wymagania cyberodporności dla producentów i produktów, część 2: wykaz komponentów oprogramowania (SBOM). Nie jest prawem wiążącym, ale to najbardziej konkretna publiczna specyfikacja napisana wprost pod CRA i coraz częściej cytowana w niemieckich kwestionariuszach dla dostawców. Wersja 2.1.0 ukazała się w sierpniu 2025.

Wymaga serializacji w JSON albo XML, w CycloneDX w wersji 1.6 lub wyższej albo SPDX w wersji 3.0.1 lub wyższej. Pola dzielą się na trzy kategorie: wymagane (zawsze), dodatkowe (obowiązkowe, gdy dana istnieje) i opcjonalne.

Wymagane na poziomie dokumentu:

twórca SBOM — adres e-mail albo URL identyfikujący wytwórcę,
znacznik czasu w formacie ISO 8601.

Wymagane dla każdego komponentu:

nazwa komponentu,
wersja komponentu,
twórca komponentu, czyli dostawca,
nazwa pliku komponentu,
zależności od innych komponentów — rozwinięte rekurencyjnie,
licencje dystrybucyjne,
skrót komponentu w postaci wdrażalnej, SHA-512,
czy komponent jest wykonywalny, czy jest archiwum, czy jest ustrukturyzowany.

Zwróć uwagę na dystans między tym a tekstem CRA. Rekurencyjne rozwinięcie całego drzewa zależności to istotnie więcej pracy niż zależności najwyższego poziomu, a wymóg SHA-512 wymusza generowanie SBOM z rzeczywistych artefaktów budowania, nie z pliku manifestu. Jeśli sprzedajesz na rynek niemiecki, planuj pod tę referencję, a nie pod próg z rozporządzenia.

Bazowa linia amerykańska: minimalne elementy NTIA

Dokument NTIA Minimum Elements for a Software Bill of Materials z 2021 roku zdefiniował siedem pól bazowych, pod które celuje do dziś większość narzędzi: nazwa dostawcy, nazwa komponentu, wersja, inne unikalne identyfikatory, relacja zależności, autor danych SBOM i znacznik czasu. Wytyczne amerykańskie zostały od tego czasu zmienione — CISA przeprowadziła konsultacje publiczne nad zaktualizowanym zestawem minimalnych elementów, dodającym pola takie jak skrót komponentu, licencja i kontekst wygenerowania. Jeśli już produkujesz SBOM dla amerykańskich klientów federalnych, jesteś blisko progu CRA — ale jeszcze nie przy referencji niemieckiej.

Normy zharmonizowane, wciąż w toku

Wniosek normalizacyjny Komisji dotyczący CRA został przyjęty przez CEN, CENELEC i ETSI 3 kwietnia 2025 i obejmuje program norm horyzontalnych i wertykalnych. Istotna jest tu horyzontalna seria EN 40000, w szczególności norma o obsłudze podatności, w której praktyka SBOM zostanie doprecyzowana. W chwili pisania normy te są nadal w fazie projektowania i zatwierdzania, a Komisja zasygnalizowała przesunięcie terminów dostarczenia.

Praktyczny wniosek: nie czekaj na normę zharmonizowaną. Jej treść powstaje pod ten sam tekst załącznika I, a praca operacyjna — oprzyrządowanie procesu budowania tak, by wypuszczał SBOM przy każdym wydaniu — nie zmienia się w zależności od tego, która lista pól wygra. Czekanie kosztuje rok historii wydań, którą inaczej już by się miało.

Gdzie SBOM-y się sypią w praktyce

Robione ręcznie, raz

Najczęstsza porażka to arkusz zestawiony na potrzeby akt technicznych, wyeksportowany do JSON-a i nigdy więcej nietknięty. W dniu powstania jest poprawny, przy pierwszym podbiciu wersji zależności — błędny. Obowiązek z CRA brzmi: utrzymywać wykaz w aktualności, więc nieaktualny SBOM nie jest częściowym spełnieniem, tylko udokumentowanym naruszeniem obowiązku ciągłego.

Niepowiązany z wersją

SBOM bez jednoznacznego wskazania, który produkt, którą wersję i które budowanie opisuje, niczego nie dowodzi. Kiedy organ zapyta, czy egzemplarze wysłane w marcu 2028 zawierały podatną bibliotekę, potrzebujesz wykazu dla tamtego budowania, nie bieżącego. To najczęstszy błąd strukturalny — i problem modelowania danych, a nie bezpieczeństwa.

Budowany z kodu, nie z artefaktu

Pliki manifestu opisują zamiar. Wydany artefakt zawiera to, co wyprodukowało budowanie: obraz bazowy, statycznie zlinkowaną bibliotekę, SDK dostawcy wrzucone jako binarka. SBOM-y generowane wyłącznie z kodu źródłowego konsekwentnie zaniżają stan, a pomijane komponenty to nieproporcjonalnie często właśnie te, których nikt nie łata.

Brak komponentów obcych i wbudowanych

Jeśli dostawca dostarcza ci moduł, jego komponenty są w twoim produkcie. CRA nie interesuje, że nie ty je napisałeś. Pozyskanie SBOM od dostawców to problem zakupowy o długim czasie realizacji — trzeba zmienić umowy, a mali dostawcy często w ogóle nie mają takiej zdolności. Od tego warto zacząć najwcześniej.

Nie ma gdzie tego trzymać

SBOM na każde wydanie, przechowywany dziesięć lat albo przez okres wsparcia, w przekroju rodzin produktów, to wersjonowany zbiór danych, który musi przetrwać migracje narzędzi, przeprowadzki repozytoriów i odejście osoby, która to ustawiła. Artefakt budowania w systemie CI, który za trzy lata zostanie wymieniony, nie jest strategią przechowywania.

Wpięcie SBOM w proces wydawniczy — pięć kroków

Generuj z budowania, automatycznie. Dodaj generowanie SBOM do etapu pipeline’u, który wytwarza artefakt do wydania, tak żeby SBOM nie mógł powstać bez budowania, a budowanie bez SBOM. Generowanie ręczne zawsze się rozjeżdża.
Powiąż SBOM z tożsamością. Produkt, wersja, identyfikator budowania, znacznik czasu. To zamienia plik w dowód i jest krokiem, który zespoły pomijają najczęściej.
Ustal głębokość i format, i to zapisz. Zdecyduj: CycloneDX albo SPDX, zdecyduj czy rozwijasz tranzytywnie (powinieneś) i udokumentuj decyzję, żeby sześć cykli wydawniczych później nikt jej po cichu nie zmienił.
Przepchnij wymóg w górę łańcucha dostaw. Zmień umowy z dostawcami tak, by wymagały SBOM na każdą dostarczoną wersję, w wybranym formacie. Zacznij od dostawców komponentów, których nie możesz sam obejrzeć.
Trzymaj tam, gdzie będzie czytelne za dekadę. Wersjonowane, indeksowane po produkcie i wydaniu, dostępne bez oryginalnego systemu budującego. Przechowywanie to wymóg, który przeżyje każde narzędzie użyte do jego spełnienia.

Szerszy program danych, w którym to siedzi, opisuje nasza checklista wdrożenia DPP.

Co to znaczy dla danych produktowych

Postawmy granicę jasno: CRA nie umieszcza SBOM w cyfrowym paszporcie produktu. W rozporządzeniu nie ma obowiązku paszportowego i żadna wykładnia nie robi z wykazu komponentów pola publicznego. Obowiązki paszportowe biorą się z ESPR i z aktów sektorowych, które je wprost nakazują.

Wspólny obu reżimom jest kształt. Oba wymagają danych, które są:

przypisane do wersji, nie do linii produktowej. SBOM zmienia się z każdym wydaniem, dokładnie tak jak dane paszportowe zmieniają się z każdą korektą specyfikacji. Systemy nadpisujące bieżący rekord nie odpowiedzą na pytanie o egzemplarz sprzedany trzy lata temu;
maszynowo czytelne z założenia. Nie PDF, który przypadkiem zawiera tabelę, tylko ustrukturyzowany dokument, który inny system przetworzy bez człowieka w środku;
przechowywane przez dekadę. Dziesięć lat dokumentacji technicznej z CRA to to samo zobowiązanie infrastrukturalne co długoterminowa dostępność paszportu wynikająca z ESPR;
spójne między kanałami. Data końca wsparcia, punkt kontaktowy do zgłaszania podatności i informacje o aktualizacjach muszą mówić to samo w twoim sklepie, u dystrybutora i w dokumentacji.

Dla elektroniki argument się kumuluje. Ten sam produkt leży jednocześnie w zasięgu ESPR, dyrektywy RoHS, dyrektywy WEEE i CRA. Firma trzymająca dane o substancjach w jednym systemie, dane o naprawialności w drugim, a dane o komponentach oprogramowania w trzecim, prowadzi cztery rejestry o jednym produkcie. Punktem wyjścia do ich scalenia jest nasz artykuł o cyfrowym paszporcie produktu dla elektroniki, a leżąca u podstaw argumentacja stoi w DPP a PIM.

Uczciwa uwaga o tym, gdzie platforma paszportowa się kończy: myDPP nie generuje SBOM, nie skanuje kodu ani kontenerów, nie weryfikuje wykazu komponentów względem budowania, nie prowadzi analizy podatności i nie ocenia zgodności z CRA. To należy do twojej linii narzędziowej, a tam gdzie wymagane — do jednostki notyfikowanej. Platforma paszportowa przechowuje wersjonowane dane produktowe, utrzymuje je dostępnymi przez lata i publikuje te części, które mają być publiczne. Odpowiedzialność za zgodność zostaje przy producencie.

Harmonogram

Data	Co się dzieje
10 grudnia 2024	rozporządzenie (UE) 2024/2847 wchodzi w życie
3 kwietnia 2025	CEN, CENELEC i ETSI przyjmują wniosek normalizacyjny
11 czerwca 2026	zaczynają obowiązywać przepisy o jednostkach notyfikowanych
11 września 2026	zaczynają obowiązywać obowiązki zgłoszeniowe — także dla produktów już na rynku
11 grudnia 2027	pełne stosowanie — wymóg SBOM z załącznika I staje się wiążący

Obowiązek zgłoszeniowy przychodzi ponad rok przed obowiązkiem SBOM i ta kolejność jest pouczająca. Od września 2026 możesz musieć zgłosić aktywnie wykorzystywaną podatność w ciągu 24 godzin. Odpowiedź na pytanie „które z naszych produktów zawierają ten komponent” w tym oknie to dokładnie ten problem, dla którego SBOM istnieje — co przesuwa praktyczny termin posiadania go znacznie przed termin prawny.

Najczęstsze pytania

Czy muszę publikować swój SBOM?

Nie. CRA zobowiązuje do jego sporządzenia, utrzymywania w aktualności i okazania organom nadzoru rynku na żądanie. Staje się on częścią dokumentacji technicznej. Publikacja wobec klientów to wybór handlowy — i coraz częściej wymaganie umowne dużych kupujących, co należy oddzielić od obowiązku prawnego.

Czy wystarczy lista zależności najwyższego poziomu?

Spełnia literę załącznika I części II. Nie spełnia niemieckiej BSI TR-03183-2, która wymaga rekurencyjnego rozwinięcia drzewa zależności, i nie odpowie na pytanie, na które faktycznie musisz odpowiedzieć, gdy podatność wypłynie cztery poziomy niżej. Najwyższy poziom traktuj jako próg, tranzytywny jako cel.

CycloneDX czy SPDX?

Pod CRA, który nie wskazuje formatu, oba da się obronić. CycloneDX ma silniejszy ekosystem bezpieczeństwa i niesie VEX; SPDX ma więcej głębi do pracy licencyjnej i nad pochodzeniem. BSI TR-03183-2 akceptuje CycloneDX od 1.6 albo SPDX od 3.0.1. Decydujące powinno być to, co twoja istniejąca linia narzędziowa generuje niezawodnie.

Jak długo muszę przechowywać SBOM-y?

SBOM jest częścią dokumentacji technicznej, którą trzeba trzymać do dyspozycji organów nadzoru rynku przez co najmniej dziesięć lat od wprowadzenia produktu do obrotu albo przez okres wsparcia, jeśli jest dłuższy. Ponieważ przy każdym wydaniu powstaje nowy SBOM, jest to archiwum wersjonowane, a nie pojedynczy plik.

Czy SBOM należy do cyfrowego paszportu produktu?

Z punktu widzenia prawa nie. CRA nie tworzy obowiązku paszportowego, a żaden obowiązujący akt paszportowy nie wymaga wykazu komponentów jako pola danych. Wspólna jest infrastruktura: oba potrzebują maszynowo czytelnych danych produktowych na poziomie wersji, przechowywanych dekadę i osiągalnych przez stabilny identyfikator.

Czytaj dalej

Źródła

Rozporządzenie (UE) 2024/2847 — Cyber Resilience Act — EUR-Lex
Cyber Resilience Act — podsumowanie tekstu prawnego — Komisja Europejska
BSI TR-03183-2: Software Bill of Materials (SBOM) — Bundesamt für Sicherheit in der Informationstechnik
CycloneDX — ECMA-424 — OWASP
SPDX — ISO/IEC 5962:2021 — Linux Foundation
Minimum Elements for a Software Bill of Materials — CISA