Poznaj nasze usługi z zakresu
Cyber Resilience Act (CRA)Produkujesz termostaty do systemów grzewczych lub sterowniki do bram garażowych?. A może panele sterowania do maszyn przemysłowych lub zabawki interaktywne dla dzieci? Na pierwszy rzut oka to produkty fizyczne – metal, plastik, elektronika. Ale jest coś, czego możesz nie być w pełni świadomy: wewnątrz każdego z tych urządzeń pracuje oprogramowanie, które składa się z dziesiątek, a często setek komponentów, pochodzących od różnych twórców z całego świata.
Rozporządzenie Cyber Resilience Act wprowadza nowy obowiązek: musisz wiedzieć, z czego składa się to oprogramowanie i udokumentować to w formalnym dokumencie. Ten dokument nazywa się SBOM – Software Bill of Materials, czyli zestawienie materiałów oprogramowania.
Jeśli teraz myślisz: ale ja nie jestem firmą programistyczną, tylko producentem urządzeń, więc CRA mnie nie dotyczy – to właśnie do Ciebie kieruję ten przewodnik. W prostych słowach wyjaśnię Ci czym jest SBOM, dlaczego CRA tego wymaga, jak go stworzyć (nawet jeśli nie masz działu IT)oraz co grozi za brak tego dokumentu.
Czym jest SBOM i dlaczego Cię dotyczy?
Zacznijmy od podstaw. Współczesne urządzenia elektroniczne – nawet te pozornie proste – zawierają oprogramowanie. Termostat, który komunikuje się z aplikacją na telefonie? Ma oprogramowanie. Brama garażowa sterowana pilotem? Ma oprogramowanie. Zabawka, która reaguje na głos dziecka? Ma oprogramowanie. Nawet zwykła żarówka LED, którą można ściemniać przez aplikację, ma w sobie mały program komputerowy.
To oprogramowanie nie powstaje od zera. Twórcy (czy to Twój zespół, czy zewnętrzna firma, której zlecasz rozwój produktu) korzystają z gotowych komponentów – bibliotek, frameworków, modułów. To trochę jak budowanie domu: nie wyrabiasz sam cegieł, tylko kupujesz gotowe materiały od różnych dostawców. Problem w tym, że w przypadku oprogramowania tych komponentów mogą być setki, a każdy z nich może zawierać błędy bezpieczeństwa.
SBOM to lista składników Twojego oprogramowania
SBOM (Software Bill of Materials), czyli zestawienie materiałów oprogramowania to dokument, który wymienia wszystkie komponenty wchodzące w skład oprogramowania w Twoim produkcie.
Pomyśl o tym jak o liście składników na opakowaniu żywności.: kupując jogurt możesz sprawdzić, czy zawiera mleko, cukier, kultury bakterii i ewentualnie substancje, na które masz alergię. SBOM robi to samo dla oprogramowania: mówi, z jakich elementów się składa, kto je stworzył, w jakiej wersji i na jakich zasadach można ich używać.
Dlaczego to ważne? Bo gdy w jednym z tych komponentów zostanie odkryty błąd bezpieczeństwa (a takie błędy są odkrywane codziennie), musisz szybko odpowiedzieć na pytanie: czy mój produkt używa tego komponentu? Bez SBOM odpowiedź na to pytanie może zająć dni lub tygodnie, natomiast z SBOM – minuty.
Cyber Resilience Act (CRA) – Przewodnik dla producentów i importerów
Dowiedz się, jak dostosować swoją firmę do pierwszej w historii Unii Europejskiej horyzontalnej regulacji cyberbezpieczeństwa.
Co znajdziesz w środku?
- Kogo dotyczy CRA? Sprawdź, czy jako producent, importer lub dystrybutor podlegasz nowym obowiązkom.
- Kategorie produktów: Dowiedz się, czy Twój produkt należy do kategorii standardowej (90% rynku), ważnej czy krytycznej.
- Kluczowe daty: Od obowiązku raportowania (wrzesień 2026) do pełnego stosowania przepisów (grudzień 2027).
- Zasadnicze wymogi: Co oznaczają w praktyce pojęcia takie jak SBOM, polityka CVD czy Security by Design.
- Kary za brak zgodności: Jak uniknąć sankcji sięgających nawet 15 milionów euro lub 2,5% światowego obrotu.
Wymogi CRA w zakresie SBOM
Obowiązek sporządzenia SBOM wynika z Załącznika I, Część II, pkt 1 rozporządzenia CRA. Przepis wymaga, abyś identyfikował i dokumentował podatności i komponenty zawarte w produktach z elementami cyfrowymi, w tym poprzez sporządzanie zestawienia materiałów oprogramowania w powszechnie stosowanym i nadającym się do odczytu maszynowego formacie.
Co to oznacza w praktyce?
Przede wszystkim SBOM musi mieć formę, którą można automatycznie przetwarzać – nie wystarczy zwykła lista przygotowana w Wordzie czy PDF. Dokument powinien obejmować co najmniej bezpośrednie komponenty oprogramowania, czyli tzw. zależności najwyższego poziomu. Producent musi również być gotowy do przedstawienia SBOM organom nadzoru rynku na ich żądanie.wystarczy lista w wordzie czy pliku PDF.
Ważne: nie musisz publikować SBOM na swojej stronie internetowej ani dołączać go do produktu. To dokument wewnętrzny, część Twojej dokumentacji technicznej. Ale musisz go mieć i aktualizować przez cały okres wsparcia produktu.
Trzy poziomy szczegółowości – co wybrać?
- Minimum wymagane przez CRA to dokumentowanie bezpośrednich komponentów (top-level dependencies). Jeśli Twoje oprogramowanie bezpośrednio używa biblioteki X, Y i Z – to one muszą być w SBOM;
- Rekomendacja BSI (niemieckiego urzędu ds. bezpieczeństwa) idzie dalej: zaleca dokumentowanie również komponentów używanych przez komponenty – aż do momentu, gdy dotrzesz do elementów spoza Twojej kontroli;
- Najlepsza praktyka branżowa to pełne drzewo zależności – wszystkie komponenty, łącznie z tymi głęboko ukrytymi. To daje najlepszą widoczność, ale wymaga odpowiednich narzędzi.
Moja rekomendacja: zacznij od minimum wymaganego przez CRA, ale dąż do pełniejszego SBOM. Błędy bezpieczeństwa często kryją się w komponentach, o których istnieniu nawet nie wiesz.
Konsekwencje braku SBOM
Brak SBOM lub niezgodność z wymogami CRA może skutkować karami administracyjnymi do 15 milionów euro lub 2,5% całkowitego rocznego światowego obrotu przedsiębiorstwa (w zależności od tego, która kwota jest wyższa). Dodatkowo organy nadzoru rynku mogą nakazać wycofanie produktu z rynku lub zakazać jego wprowadzania. To realne konsekwencje biznesowe, nie teoretyczne zagrożenie.
Formaty SBOM: SPDX czy CycloneDX?
CRA wymaga, aby SBOM był w formacie nadającym się do odczytu maszynowego, ale nie narzuca konkretnego standardu. W praktyce masz do wyboru dwa główne formaty: SPDX i CycloneDX. Oba są akceptowane przez organy nadzoru i oba spełniają wymogi CRA.
- SPDX (Software Package Data Exchange) to standard opracowany przez Linux Foundation, uznany za normę ISO. Jego mocną stroną jest szczegółowe dokumentowanie licencji – przydatne, jeśli zależy Ci na zgodności prawnej użycia komponentów open source.
- CycloneDX to standard opracowany przez OWASP (organizację zajmującą się bezpieczeństwem aplikacji). Jest prostszy w użyciu i lepiej zintegrowany z narzędziami bezpieczeństwa – przydatny, jeśli priorytetem jest wykrywanie podatności.
Który wybrać?
Jeśli nie masz silnych preferencji – wybierz CycloneDX. Jest prostszy, lepiej wspierany przez darmowe narzędzia i zorientowany na bezpieczeństwo, co jest głównym celem CRA. Możesz też generować SBOM w obu formatach – narzędzia to umożliwiają.
Oba formaty zapisują dane w plikach JSON lub XML – to pliki tekstowe, które można otworzyć i przejrzeć, ale przede wszystkim przetworzyć automatycznymi narzędziami.
Jak wygenerować SBOM?
Jeśli zlecasz rozwój oprogramowania na zewnątrz
Wielu producentów urządzeń nie tworzy oprogramowania samodzielnie – zleca to zewnętrznym firmom programistycznym. Jeśli tak jest w Twoim przypadku, masz dwie opcje:
- Wymagaj SBOM od dostawcy oprogramowania. Dodaj do umowy zapis, że wykonawca musi dostarczyć aktualny SBOM w formacie CycloneDX lub SPDX przy każdym wydaniu oprogramowania. To najprostsze rozwiązanie – odpowiedzialność za generowanie SBOM spoczywa na kimś, kto rozumie strukturę kodu.
- Wygeneruj SBOM samodzielnie z dostarczonego kodu. Jeśli dostajesz kod źródłowy, możesz użyć narzędzi opisanych poniżej. Wymaga to pewnej wiedzy technicznej, ale jest wykonalne.
Jeśli nie masz dostępu do kodu źródłowego
Czasem dostajesz od dostawcy tylko gotowy plik binarny (skompilowane oprogramowanie), bez kodu źródłowego. W takiej sytuacji generowanie pełnego SBOM jest trudniejsze, ale nie niemożliwe. Narzędzia takie jak Syft potrafią analizować pliki binarne i identyfikować przynajmniej część komponentów. Wynik będzie mniej dokładny niż SBOM z kodu źródłowego, ale lepszy niż nic.
Najlepszym rozwiązaniem jest jednak wymaganie SBOM od dostawcy oprogramowania. Jeśli dostawca odmawia lub nie potrafi dostarczyć SBOM – to sygnał ostrzegawczy o jakości jego procesów.
Narzędzia do generowania SBOM
Jeśli masz dostęp do kodu źródłowego lub obrazu oprogramowania, możesz wygenerować SBOM automatycznie. Oto najpopularniejsze darmowe narzędzia:
- Syft (firma Anchore) – narzędzie uruchamiane z linii poleceń, analizuje kod źródłowy lub obrazy kontenerów i generuje SBOM. Obsługuje wiele języków programowania. Przykład użycia: syft dir:/sciezka/do/kodu -o cyclonedx-json > sbom.json
- Trivy (firma Aqua Security) – oprócz generowania SBOM potrafi też skanować pod kątem znanych podatności. Dwa narzędzia w jednym. Przykład: trivy fs /sciezka/do/kodu –format cyclonedx –output sbom.json
- cdxgen – oficjalne narzędzie projektu CycloneDX. Szczególnie dobre dla projektów w językach Java, JavaScript, Python.
Wszystkie te narzędzia są darmowe i open source. Wymagają podstawowej znajomości linii poleceń, ale nie trzeba być programistą, żeby ich użyć.
Zarządzanie komponentami zewnętrznymi
CRA nakłada odpowiedzialność na producenta za cały produkt, włącznie z komponentami zewnętrznymi. Nie możesz zwolnić się z odpowiedzialności, argumentując, że błąd jest w bibliotece, którą stworzył ktoś inny. Jeśli Twój produkt używa tej biblioteki – to za ewenualne dalsze korzystanie z niego ponosisz odpowiedzialność.
Dlatego samo wygenerowanie SBOM to dopiero początek. Musisz również monitorować, czy w komponentach z Twojego SBOM nie zostały odkryte nowe błędy bezpieczeństwa, i reagować, gdy się pojawią.
Przykładowe narzędzia do monitorowania:
- Dependency-Track (projekt OWASP, darmowy) – wgrywasz do niego SBOM, a system automatycznie sprawdza, czy któryś z komponentów ma znane podatności. Gdy pojawi się nowa podatność – dostajesz powiadomienie. To jak monitoring bezpieczeństwa dla Twojego oprogramowania.
- Grype (firma Anchore, darmowy) – skaner podatności, który przyjmuje SBOM jako dane wejściowe. Możesz go uruchamiać regularnie (np. raz dziennie) i sprawdzać, czy pojawiły się nowe zagrożenia.
Co robić, gdy znajdziesz podatność?
Gdy narzędzie monitorujące wykryje podatność w jednym z Twoich komponentów, masz kilka opcji:
- zaktualizować komponent do nowszej wersji, w której błąd jest naprawiony,
- zastąpić komponent innym, bezpieczniejszym,
- jeśli aktualizacja nie jest możliwa – ocenić, czy podatność faktycznie dotyczy Twojego przypadku użycia i udokumentować tę ocenę.
Pamiętaj: CRA wymaga, abyś przez cały okres wsparcia produktu dostarczał aktualizacje bezpieczeństwa. SBOM i monitoring to narzędzia, które pozwalają wykrywać, co trzeba zaktualizować.
Automatyzacja – jak to robić na bieżąco
SBOM nie jest dokumentem, który tworzysz raz i zapominasz. Każda zmiana w oprogramowaniu oznacza potencjalną zmianę w SBOM. Dlatego generowanie SBOM powinno być zautomatyzowane i odbywać się przy każdym wydaniu oprogramowania.
Jeśli masz własny zespół programistyczny, poproś o włączenie generowania SBOM do procesu budowania oprogramowania.
Jeśli zlecasz rozwój na zewnątrz, dodaj do umowy wymóg dostarczania aktualnego SBOM przy każdym wydaniu. Określ format (CycloneDX JSON lub SPDX JSON), minimalną zawartość i termin dostarczenia.
Istotna modyfikacja produktu a SBOM
CRA wprowadza pojęcie istotnej modyfikacji. Jeśli Twój produkt przechodzi taką modyfikację – np. znaczącą zmianę architektury, dodanie funkcji komunikacji sieciowej, wymianę głównych komponentów – jest traktowany jak nowy produkt i wymaga nowej oceny zgodności, w tym nowego SBOM.
Zwykłe aktualizacje bezpieczeństwa i drobne poprawki nie stanowią istotnej modyfikacji. Ale każda znacząca zmiana powinna być oceniona pod tym kątem.
Ekspert radzi
Praktyczna wskazówka:
Prowadź rejestr zmian oprogramowania i przy każdej większej zmianie zadaj sobie pytanie – czy to wpływa na bezpieczeństwo produktu na tyle, że wymaga aktualizacji dokumentacji technicznej?
Zobacz więcej →SBOM to lista składników oprogramowania w Twoim produkcie. CRA wymaga, abyś taką listę posiadał, utrzymywał ją aktualną i był gotów przedstawić organom nadzoru.
Najważniejsze punkty:
- Nawet jeśli nie jesteś firmą programistyczną – jeśli Twój produkt zawiera oprogramowanie, CRA Cię dotyczy;
- SBOM możesz uzyskać od dostawcy oprogramowania lub wygenerować samodzielnie darmowymi narzędziami;
- Samo posiadanie SBOM to za mało – musisz monitorować, czy komponenty nie mają podatności;
- Kary za brak zgodności są realne: do 15 mln EUR lub 2,5% obrotu;
- Termin pełnej zgodności to 11 grudnia 2027, ale warto zacząć teraz – tym bardziej, iż od 11 września 2026 roku wchodzi obowiązek zgłaszania podatności, które można wychwydzić właśnie poprzez posiadanie i monitorowanie SBOM.
SBOM nie jest celem samym w sobie. To narzędzie, które pozwala Ci wiedzieć, co jest w Twoim produkcie, i reagować, gdy coś pójdzie nie tak. W świecie, gdzie cyberataki są codziennością, ta wiedza jest bezcenna.
Jak możemy pomóc?
Wdrożenie SBOM i dostosowanie do wymogów CRA może wydawać się skomplikowane, szczególnie dla firm, które nie mają własnych zespołów IT. Wspieramy producentów urządzeń z elementami cyfrowymi w przygotowaniu do Cyber Resilience Act – od analizy, które produkty podlegają regulacji, przez przygotowanie dokumentacji technicznej, po wdrożenie procedur zarządzania podatnościami.
Skontaktuj się z nami i uzyskaj kompleksowe wsparcie w zakresie CRA
FAQ
SBOM, czyli Software Bill of Materials, to zestawienie materiałów oprogramowania. W praktyce jest to lista komponentów, bibliotek i modułów, z których składa się oprogramowanie w produkcie z elementami cyfrowymi. Dzięki SBOM producent wie, jakie składniki znajdują się w urządzeniu i może szybciej zidentyfikować i reagować na wykryte podatności.
Obowiązek dotyczy producentów produktów z elementami cyfrowymi, czyli nie tylko firm tworzących typowe oprogramowanie, ale też producentów urządzeń takich jak termostaty, sterowniki do bram, zabawki interaktywne, panele sterowania czy inteligentne oświetlenie. Jeżeli w produkcie działa oprogramowanie, temat SBOM i CRA najpewniej dotyczy także Twojej firmy.
Tak. Nawet jeśli produkujesz głównie sprzęt, a oprogramowanie jest tylko częścią urządzenia, nadal odpowiadasz za zgodność produktu z wymogami CRA, w tym za posiadanie i utrzymywanie aktualnego SBOM.
SBOM powinien wskazywać co najmniej komponenty użyte w oprogramowaniu, ich wersje oraz informacje pozwalające je jednoznacznie zidentyfikować. Minimum wymagane przez CRA obejmuje bezpośrednie komponenty, czyli tzw. top-level dependencies. W praktyce im bardziej kompletny SBOM, tym większa kontrola nad bezpieczeństwem produktu.
SBOM powinien być przygotowany w powszechnie stosowanym formacie nadającym się do odczytu maszynowego. W praktyce najczęściej stosuje się SPDX albo CycloneDX. Zwykła lista w Wordzie, Excelu lub PDF nie spełnia tego celu w takim stopniu jak ustrukturyzowany plik JSON lub XML.
Oba formaty są używane w praktyce i oba mogą wspierać zgodność z CRA. SPDX jest mocny od strony licencyjnej, a CycloneDX jest często wybierany przy bezpieczeństwie i zarządzaniu podatnościami. Jeśli priorytetem jest prostsze wdrożenie i integracja z narzędziami security warto wybrać CycloneDX.
Nie. SBOM ma charakter wewnętrzny i stanowi część dokumentacji technicznej produktu. Producent powinien mieć go gotowego i przedstawić organom nadzoru na żądanie, ale nie musi publikować go publicznie.
