SBOM a CRA — od pliku CycloneDX lub SPDX do decyzji i dowodu

Cyber Resilience Act wymaga identyfikowania i dokumentowania podatności oraz komponentów zawartych w produktach z elementami cyfrowymi, w tym sporządzenia Software Bill of Materials (SBOM) w powszechnie używanym, maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu.

To nie oznacza jednak, że wygenerowanie pliku kończy pracę. SBOM ma wartość dopiero wtedy, gdy zespół potrafi przejść od komponentu do konkretnego wydania, podatności, decyzji, poprawki i dowodu weryfikacji.

Co CRA mówi o SBOM

Załącznik I część II wymaga od producenta identyfikowania i dokumentowania podatności oraz komponentów produktu, w tym przez sporządzenie SBOM.

Załącznik VII wiąże SBOM z dokumentacją procesów obsługi podatności. Organ nadzoru rynku może też na uzasadnione żądanie otrzymać SBOM, jeżeli jest potrzebny do sprawdzenia zgodności z wymaganiami.

Ważne rozróżnienie: rozporządzenie nie mówi, że każdy producent ma publikować pełny SBOM publicznie dla każdego użytkownika. Załącznik II opisuje informację o miejscu dostępu do SBOM jeżeli producent zdecyduje się go udostępnić użytkownikowi.

Format to tylko pierwsza decyzja

CycloneDX i SPDX są powszechnie używanymi formatami ekosystemu SBOM. Wybór formatu nie rozwiązuje problemu zarządzania.

Dla każdego artefaktu SBOM zapisz co najmniej:

produkt;
wersję/release;
czas wygenerowania;
narzędzie i proces generujący;
zakres skanowania;
wersję formatu;
miejsce przechowania;
identyfikator lub hash artefaktu;
status walidacji.

Bez powiązania z wydaniem nie wiadomo później, czy znaleziony komponent był rzeczywiście dostarczony klientowi.

Przepływ, który daje wartość

komponent → wersja komponentu → wydanie produktu → podatność → ocena wpływu → decyzja → działanie → poprawka → test → dowód → komunikacja

Przykład:

narzędzie wykrywa bibliotekę X w wydaniu 4.8.1;
pojawia się informacja o podatności dotyczącej określonych wersji X;
zespół potwierdza, czy podatny kod jest obecny i osiągalny w produkcie;
powstaje ocena wpływu i decyzja o priorytecie;
poprawka trafia do zadania i konkretnego wydania;
test weryfikuje rezultat;
dowód testu zostaje powiązany ze sprawą;
jeżeli spełnione są przesłanki art. 14, uruchamiany jest oddzielny proces raportowania CRA.

Sam CVE i sam SBOM nie podejmują za zespół decyzji o wpływie na produkt.

SBOM i dostawcy

Komponent może pochodzić z open source, od komercyjnego dostawcy albo z innego zespołu. Dlatego dojrzały proces łączy zależność z:

dostawcą lub źródłem komponentu;
warunkami utrzymania;
źródłem informacji o podatnościach;
osobą odpowiedzialną za aktualizację;
alternatywą, jeżeli komponent przestanie być wspierany.

To ma znaczenie również dla okresu wsparcia produktu. CRA pozwala przy jego ustalaniu brać pod uwagę m.in. okresy wsparcia kluczowych komponentów pochodzących od stron trzecich.

Nie buduj kolejnego skanera GRC

Pulsar nie powinien konkurować z narzędziami SCA, skanerami zależności i generatorami SBOM. Ich zadaniem jest wykrywać i opisywać komponenty.

Rolą GRC jest wykorzystać te dane w procesie decyzyjnym:

powiązać artefakt z produktem i wydaniem;
przypisać ryzyko i działanie;
wskazać właściciela i termin;
zachować decyzję;
dołączyć dowód naprawy i testu;
wykazać historię podczas przeglądu.

Obecne repo Pulsara potwierdza obszary ryzyk, działań, dostawców, dokumentów, dowodów i raportów. Import CycloneDX/SPDX nie jest w tym pakiecie potwierdzony jako działająca funkcja — nie reklamuj go, dopóki implementacja nie ma dowodu w produkcie.

Co sprawdzić w swoim procesie dziś

Czy potrafisz wskazać SBOM dla konkretnego release?
Czy wynik jest reprodukowalny?
Czy komponent ma właściciela?
Czy podatność można powiązać z wydaniem produktu?
Czy decyzja o akceptacji ryzyka ma autora i termin przeglądu?
Czy poprawka ma dowód testu?
Czy wiadomo, kiedy sprawa przechodzi do procesu raportowania CRA?

Zobacz Pulsar GRC na jednym procesie dowodowym

Powiązane materiały

Źródła

Stan źródeł: 12 września 2026 r.