SBOM 2026: co kryje oprogramowanie Twojej firmy?

Czym jest SBOM i dlaczego wszyscy o nim mówią?

Wyobraź sobie, że kupujesz gotowe danie w restauracji. Masz prawo wiedzieć, co zawiera – z jakich składników zostało przyrządzone, czy nie ma w nim alergenów. Analogicznie działa SBOM (Software Bill of Materials) – to cyfrowy spis składników każdego programu komputerowego.

SBOM zawiera pełną listę komponentów, bibliotek open source, zależności i ich wersji wchodzących w skład danego oprogramowania. Nowoczesna aplikacja biznesowa może składać się z setek, a nawet tysięcy takich elementów – pisanych przez różnych autorów, utrzymywanych przez różne organizacje na całym świecie. System ERP, platforma e-commerce, oprogramowanie kadrowe – każde z nich to złożona układanka cudzego kodu.

Termin SBOM funkcjonuje od lat, jednak prawdziwy przełom nastąpił po kilku głośnych incydentach bezpieczeństwa, które pokazały, że firmy używają oprogramowania, nie wiedząc, co tak naprawdę jest w środku. Dziś SBOM staje się narzędziem zarządzania ryzykiem dostępnym dla każdej organizacji – nie tylko dla deweloperów.

Log4Shell i SolarWinds: dlaczego brak SBOM kosztował miliardy

Dwa incydenty zmieniły podejście całej branży IT do bezpieczeństwa łańcucha dostaw oprogramowania i sprawiły, że SBOM trafił na agendy rządów.

SolarWinds (2020) – hakerzy powiązani z rosyjskim wywiadem wstrzyknęli złośliwy kod do aktualizacji oprogramowania SolarWinds Orion, używanego przez tysiące firm i instytucji rządowych. Przez wiele miesięcy ofiary nie wiedziały, że w ich środowiskach działa backdoor – bo nikt nie weryfikował zawartości aktualizacji. Wśród poszkodowanych były agencje federalne USA, wielkie korporacje i firmy technologiczne.

Log4Shell (2021) – krytyczna luka w bibliotece Log4j wstrząsnęła światem IT. Problem? Niemal nikt nie wiedział, że używa tej biblioteki – była ona ukryta głęboko w zależnościach dziesiątek popularnych aplikacji. Gdyby firmy posiadały aktualny SBOM swoich systemów, mogłyby w ciągu godzin zidentyfikować, które aplikacje są zagrożone. Zamiast tego – weryfikacja trwała tygodnie, a naprawianie luki całe miesiące.

Szacuje się, że globalne koszty reakcji na Log4Shell wyniosły dziesiątki miliardów dolarów. To właśnie te dwa incydenty sprawiły, że rządy i regulatorzy po obu stronach Atlantyku zaczęli poważnie traktować SBOM jako obowiązkowy element bezpieczeństwa IT.

Formaty SBOM: SPDX, CycloneDX i co je różni

SBOM to nie jeden standard – istnieje kilka formatów, z których najważniejsze to SPDX i CycloneDX. Jeśli będziesz wymagać SBOM od dostawców oprogramowania, warto rozumieć różnicę.

• SPDX (Software Package Data Exchange) – opracowany przez Linux Foundation, jest oficjalnym standardem ISO (ISO/IEC 5962:2021). Skupia się głównie na informacjach o licencjach komponentów i ich proweniencji, czyli skąd pochodzi dany kod. Popularny w środowiskach open source i przy audytach licencyjnych.
• CycloneDX – rozwijany przez OWASP, koncentruje się na bezpieczeństwie. Zawiera informacje o znanych podatnościach (CVE), stosowanych technikach kryptograficznych i zależnościach między komponentami. Preferowany w kontekście zgodności z regulacjami bezpieczeństwa, takimi jak Cyber Resilience Act czy NIS2.

Oba formaty można eksportować jako pliki XML, JSON lub w formacie tekstowym. Coraz więcej narzędzi deweloperskich – GitHub, GitLab, Snyk, JFrog Artifactory – generuje SBOM automatycznie podczas procesu budowania oprogramowania.

Dla firmy MŚP kluczowe jest jedno: możliwość zażądania SBOM od dostawcy i posiadanie narzędzia do jego analizy pod kątem znanych podatności. Reszta to domena programistów.

Regulacje: Cyber Resilience Act i nowe obowiązki prawne

SBOM przestaje być dobrowolną dobrą praktyką. Regulacje po obu stronach Atlantyku czynią go coraz częściej wymogiem prawnym, który dotknie każdą firmę kupującą lub wdrażającą oprogramowanie.

Cyber Resilience Act (CRA) w UE – rozporządzenie wchodzi w życie etapami, z pełną obowiązkowością od końca 2027 roku. Nakłada na producentów oprogramowania i urządzeń połączonych z siecią obowiązek dokumentowania komponentów oraz aktywnego zarządzania lukami przez cały cykl życia produktu. Choć CRA kieruje się przede wszystkim do producentów, jego skutki odczują wszyscy nabywcy – bo będą mogli żądać SBOM jako elementu weryfikacji przed zakupem.

Dyrektywa NIS2 – już wdrożona w Polsce, w ramach wymogów dotyczących bezpieczeństwa łańcucha dostaw de facto zobowiązuje organizacje objęte dyrektywą do weryfikacji ryzyk związanych ze stosowanym oprogramowaniem. SBOM jest naturalnym narzędziem tej weryfikacji.

USA – Executive Order 14028 (2021) – rozporządzenie prezydenta Bidena zobowiązało wszystkich dostawców oprogramowania dla rządu federalnego USA do dostarczania SBOM. Standardy rządowe szybko przenikają do sektora prywatnego, zwłaszcza w branżach regulowanych.

Praktyczne przesłanie dla MŚP: jeśli zamawiasz oprogramowanie na zamówienie lub kupujesz rozwiązania dla sektorów finansowych, medycznych lub infrastruktury krytycznej – zapytaj dostawcę o SBOM. Za rok lub dwa może to być wymóg formalny, nie prośba.

Co SBOM oznacza praktycznie dla firmy MŚP?

Większość małych i średnich firm nie tworzy własnego oprogramowania – używa gotowych rozwiązań od zewnętrznych dostawców. Czy SBOM ich dotyczy? Tak, choć w inny sposób niż deweloperów.

Oto co SBOM oznacza w praktyce:

1. Świadomy zakup oprogramowania – możesz wymagać od dostawcy dokumentacji komponentów, zanim podpiszesz umowę. To szczególnie ważne przy systemach ERP, CRM lub oprogramowaniu branżowym integrującym się z danymi firmy.
2. Szybka reakcja na nowe podatności – gdy pojawi się nowa krytyczna luka (kolejny Log4Shell), firma posiadająca SBOM swoich systemów może w minuty sprawdzić, czy jest narażona. Bez SBOM ta sama weryfikacja trwa tygodnie.
3. Due diligence przy zakupach i fuzjach – SBOM staje się elementem audytów IT w procesach M&A. Brak dokumentacji oprogramowania może obniżyć wycenę firmy lub opóźnić transakcję.
4. Zgodność z regulacjami – w sektorach objętych NIS2 lub DORA organy nadzoru zaczną weryfikować, czy firma zarządza ryzykami łańcucha dostaw oprogramowania. SBOM to dowód, że to robi.

Dobra wiadomość: nie musisz tworzyć SBOM samodzielnie dla każdego produktu z osobna. Wystarczy wiedzieć, jak go zażądać od dostawców i co z nim zrobić po otrzymaniu.

Jak przygotować firmę na erę SBOM – pierwsze kroki

Firmy MŚP, które chcą wyprzedzić regulacje i zmniejszyć ryzyko ataków w łańcuchu dostaw, powinny podjąć kilka praktycznych kroków – nie wymagają one dużych nakładów, ale wymagają systematyczności.

• Zrób inwentaryzację oprogramowania – zanim zaczniesz wymagać SBOM od dostawców, musisz wiedzieć, jakie oprogramowanie w ogóle używasz. Lista aplikacji, systemów i usług chmurowych to absolutny punkt wyjścia.
• Dodaj zapisy o SBOM do nowych umów z dostawcami – uwzględnij klauzulę zobowiązującą dostawcę do dostarczenia SBOM w formacie SPDX lub CycloneDX oraz do jego aktualizacji przy każdej nowej wersji produktu.
• Wdrożyć skanowanie podatności – narzędzia takie jak OWASP Dependency-Track pozwalają załadować SBOM i automatycznie wykrywać, które komponenty mają znane luki CVE.
• Przeszkol osobę odpowiedzialną za IT – administrator IT lub osoba ds. bezpieczeństwa powinna rozumieć, czym jest SBOM, jak go czytać i jak interpretować wyniki skanowania.
• Powiąż SBOM z procesem zarządzania podatnościami – SBOM jest wartościowy wyłącznie wtedy, gdy jest aktualny i analizowany regularnie, a nie odkładany do szuflady po jednorazowym audycie.

Jeśli nie wiesz, od czego zacząć, audyt bezpieczeństwa IT pomoże ocenić obecny stan środowiska i wskazać priorytety. Specjaliści NovaSys wspierają firmy MŚP z Wrocławia i okolic w analizie ryzyk łańcucha dostaw i przygotowaniu do wymogów Cyber Resilience Act oraz NIS2.