SBOM w CRA — czego rozporządzenie faktycznie wymaga

Co CRA mówi o SBOM: minimum zależności najwyższego poziomu, format maszynowy, CycloneDX i SPDX oraz kto może żądać zestawienia.

Michał Jaśniewski 21 października 2026 7 min czytania

CRA wymaga SBOM, ale wymaga mniej, niż sugeruje rynkowa narracja i więcej, niż zakłada większość zespołów. Załącznik I część II pkt 1 nakazuje producentowi identyfikować i dokumentować podatności oraz komponenty produktu, w tym przez sporządzenie zestawienia komponentów oprogramowania „w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującym co najmniej zależności najwyższego poziomu produktu”. Rozporządzenie nie wskazuje CycloneDX ani SPDX z nazwy, nie wymaga publikowania SBOM i nie wymaga jego przekazywania klientom — wymaga posiadania go, utrzymywania w czasie i przekazania na uzasadniony wniosek organu nadzoru rynku.

Trzy miejsca, w których SBOM pojawia się w rozporządzeniu

Mylące jest to, że obowiązek jest rozproszony.

Załącznik I część II pkt 1 — źródło obowiązku. SBOM jest narzędziem wykonania szerszego wymogu: identyfikowania i dokumentowania komponentów oraz podatności produktu.

Załącznik VII pkt 2 i pkt 8 — SBOM jest elementem dokumentacji technicznej: w pkt 2 jako część specyfikacji procesów obsługi podatności, w pkt 8 jako odrębna pozycja przekazywana na uzasadniony wniosek organu nadzoru rynku.

Art. 13 ust. 24 i 25 — przyszłość i nadzór. Ust. 24 daje Komisji prawo określenia w akcie wykonawczym formatu i elementów SBOM. Ust. 25 pozwala ADCO zdecydować o przeprowadzeniu unijnej oceny zależności dla wybranych kategorii produktów; organy nadzoru rynku mogą wtedy żądać SBOM od producentów i przekazywać ADCO informacje zanonimizowane i zagregowane, a ADCO raportuje je Grupie Współpracy NIS2.

Z art. 13 ust. 25 wynika praktyczny komfort: SBOM trafia do organów, nie do publicznego obiegu, a dalej idzie wyłącznie w formie zanonimizowanej i zagregowanej. Obawa o ujawnienie stosu technologicznego konkurencji jest w tym mechanizmie adresowana.

„Co najmniej zależności najwyższego poziomu" — co to znaczy

To najczęściej przeszacowywany fragment. Minimum regulacyjne to zależności bezpośrednie produktu, nie pełne drzewo tranzytywne.

Dla aplikacji w Node.js oznacza to pakiety wymienione w package.json, nie 1800 pakietów z package-lock.json. Dla obrazu kontenera — obraz bazowy i zainstalowane pakiety, nie każda biblioteka systemowa osobno.

Ale minimum regulacyjne nie jest tym samym co minimum użyteczne. Jeśli SBOM ma służyć do czegokolwiek poza okazaniem organowi — na przykład do odpowiedzi na pytanie „czy dotyczy nas luka w bibliotece X” — potrzebne jest drzewo tranzytywne, bo właśnie tam siedzą podatności wykorzystywane w praktyce.

Argument biznesowy za głębszym SBOM jest więc inny niż zgodność: skraca czas odpowiedzi na zapytanie klienta i na własne zdarzenie bezpieczeństwa. Zegary z art. 14 (24 godziny na wczesne ostrzeżenie) działają wyłącznie wtedy, gdy wiadomo, które produkty i wersje zawierają podatny komponent.

Format: rozporządzenie milczy, rynek nie

CRA wymaga „powszechnie używanego formatu nadającego się do odczytu maszynowego”. Nie nazywa standardu. Dopóki Komisja nie skorzysta z art. 13 ust. 24, wybór należy do producenta.

Dwa formaty mają status standardów międzynarodowych:

Praktyczna różnica dla producenta oprogramowania: CycloneDX wyrósł z potrzeb bezpieczeństwa (ma natywne modele podatności, VEX i relacji zależności), SPDX z zarządzania licencjami i zgodnością prawną open source. Większość łańcuchów narzędziowych generuje oba, więc wybór „albo-albo” rzadko jest realnym ograniczeniem.

Rekomendacja operacyjna, nie prawna: generować w jednym formacie kanonicznym, przechowywać wersjonowane artefakty na wydanie, a konwersję traktować jako czynność wyjściową na żądanie odbiorcy.

SBOM nie jest dokumentem — jest artefaktem builda

Najczęstszy błąd wdrożeniowy: SBOM wygenerowany raz, ręcznie, dla wersji, która już nie jest sprzedawana.

Załącznik VII pkt 1 wymaga wskazania w dokumentacji wersji oprogramowania mających wpływ na zgodność, a art. 31 ust. 2 — aktualizowania dokumentacji co najmniej przez okres wsparcia. SBOM musi więc istnieć per wersja produktu objęta wsparciem, nie per produkt.

To przesądza o miejscu w procesie: generowanie w pipeline, przy tym samym kroku co budowa artefaktu wydaniowego, z zapisem do rejestru niemodyfikowalnego. SBOM wygenerowany po fakcie, ze skanu środowiska produkcyjnego, opisuje stan wdrożenia, nie stan wydania — i nie odpowiada na pytanie, co producent wprowadził do obrotu.

Drugi wniosek: SBOM warto wiązać z podpisem artefaktu. Załącznik I część II pkt 7 wymaga bezpiecznej dystrybucji aktualizacji, a Załącznik VII pkt 2 — udokumentowania technicznego rozwiązania, które to zapewnia. Podpisany artefakt plus przypisany do niego SBOM pokrywają oba wymagania jednym mechanizmem.

Komponenty obce: obowiązek wykracza poza listę

SBOM jest listą. CRA wymaga działania na jej podstawie.

Art. 13 ust. 5 — producent zachowuje należytą staranność przy integrowaniu komponentów pochodzących od stron trzecich, tak by nie naruszały cyberbezpieczeństwa produktu. Obowiązek obejmuje wprost komponenty wolnego i otwartego oprogramowania, które nie są udostępniane odpłatnie.

Art. 13 ust. 6 — gdy producent zidentyfikuje podatność w zintegrowanym komponencie (również open source), zgłasza ją producentowi lub podmiotowi utrzymującemu ten komponent i usuwa ją zgodnie z częścią II Załącznika I. Jeśli opracował poprawkę, przekazuje temu podmiotowi odpowiedni kod lub dokumentację — w stosownych przypadkach w formacie nadającym się do odczytu maszynowego.

Art. 13 ust. 7 — dokumentowanie istotnych aspektów cyberbezpieczeństwa, proporcjonalnie do ryzyka, w tym znanych podatności i istotnych informacji od stron trzecich, z aktualizacją oceny ryzyka.

Łącznie oznacza to, że SBOM bez procesu triage’u podatności nie spełnia celu części II Załącznika I. Samo posiadanie listy komponentów nie jest „identyfikowaniem i dokumentowaniem podatności”.

Czego CRA nie wymaga

Lista negatywna oszczędza budżet i czas:

Rozdzielenie tych czterech punktów od wymogów faktycznych jest konkretną oszczędnością — redukuje zakres wdrożenia do tego, co rozporządzenie naprawdę nakłada, i zmniejsza ryzyko ujawnienia informacji, do którego CRA nie zobowiązuje.

Co to znaczy dla producenta oprogramowania

Trzy decyzje do podjęcia przed 11 grudnia 2027 r., gdy obowiązki dokumentacyjne i oznakowanie CE zaczynają obowiązywać:

Efekt ubocznym jest zwykle sprzedażowy: ten sam artefakt odpowiada na pytania z ankiet bezpieczeństwa klientów enterprise, które dziś blokują kontrakty, zanim CRA zdąży cokolwiek wymagać.

Źródła

Materiał informacyjny, nie opinia prawna. Opisuje warstwę techniczną i procesową obowiązków wynikających z rozporządzenia (UE) 2024/2847; pełna zgodność wymaga także działań organizacyjnych i prawnych po stronie podmiotu i nie zastępuje opinii prawnej ani formalnej oceny zgodności. Stan na październik 2026 r.

CRASBOMSupply Chain Security