Ten artykuł powstał częściowo z pomocą sztucznej inteligencji.
W skrócie: SBOM (software bill of materials) to wykaz komponentów oprogramowania, czyli lista bibliotek, modułów i ich wersji, z których zbudowano produkt. Od 11 grudnia 2027 r. Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi sporządzenia SBOM w powszechnie używanym formacie odczytywalnym maszynowo, obejmującym co najmniej zależności najwyższego poziomu. Wykaz nie musi być publiczny, ale musi być częścią dokumentacji technicznej. Dla producentów urządzeń to także warunek dotrzymania 24-godzinnego terminu zgłoszenia podatności, który obowiązuje już dziś.
Ten tekst uzupełnia nasz przewodnik o tym, czego NIS2 i CRA wymagają od firm z oprogramowaniem.
Najważniejsze fakty:
Taki wykaz to dla oprogramowania to, czym lista składników jest dla produktu spożywczego. Pokazuje, z jakich gotowych elementów zbudowano oprogramowanie: biblioteki open source, komponenty od dostawców, systemy operacyjne czasu rzeczywistego, sterowniki. Dla każdego elementu podaje nazwę, wersję, dostawcę i zależności.
Producent potrzebuje wykazu komponentów z trzech powodów. Po pierwsze, wymaga go Cyber Resilience Act. Po drugie, bez niego nie da się szybko odpowiedzieć na pytanie, czy nowa podatność w popularnej bibliotece dotyczy produktu, a od 11 września 2026 r. aktywnie wykorzystywaną podatność trzeba zgłosić w 24 godziny; opisujemy to w tekście o tym, jak działa 24-godzinny termin zgłoszenia z CRA. Po trzecie, klienci objęci NIS2 coraz częściej pytają dostawców o taki wykaz w ramach oceny łańcucha dostaw.
Według rozporządzenia (UE) 2024/2847 producent musi identyfikować i dokumentować podatności i komponenty produktu, w tym sporządzić SBOM w powszechnie używanym formacie odczytywalnym maszynowo, obejmujący co najmniej zależności najwyższego poziomu. Wykaz jest częścią dokumentacji technicznej, którą producent przechowuje i udostępnia organom nadzoru rynku na żądanie.
Przepisy nie narzucają formatu, ale w praktyce wybór sprowadza się do SPDX i CycloneDX. Minimalny zestaw danych dobrze opisuje dokument NTIA o minimalnych elementach SBOM: nazwa dostawcy, nazwa komponentu, wersja, unikalny identyfikator, relacje zależności, autor danych i znacznik czasu.
SPDX rozwija Linux Foundation; format ma status normy międzynarodowej ISO/IEC 5962:2021 i jest mocny w opisie licencji. CycloneDX powstał w ramach OWASP i jest nastawiony na bezpieczeństwo: dobrze obsługuje informacje o podatnościach i dokumenty VEX, w których producent wyjaśnia, że dana podatność nie dotyczy produktu. Oba formaty spełniają wymóg „powszechnie używanego formatu odczytywalnego maszynowo”. Wybór zwykle zależy od narzędzi, których firma już używa, i od tego, czego oczekują klienci.
W aplikacjach webowych wykaz da się wygenerować z menedżera pakietów w kilka minut. W urządzeniach i maszynach jest trudniej:
Dlatego wykaz warto generować automatycznie przy każdym budowaniu wersji, a nie ręcznie raz w roku. Agencja CISA zebrała materiały o SBOM, w tym o dokumentach VEX i o udostępnianiu wykazu klientom.
Pierwsze połączenie wykazu komponentów z bazą podatności zwykle kończy się zaskoczeniem: setki alertów dla jednego produktu. Większość z nich nie oznacza realnego zagrożenia. Biblioteka może zawierać podatną funkcję, której produkt nie używa, albo podatność dotyczy konfiguracji, której w urządzeniu nie ma.
Do opisywania takich sytuacji służy VEX (Vulnerability Exploitability eXchange), czyli dokument, w którym producent dla każdej znanej podatności podaje status, na przykład „nie dotyczy”, „dotyczy, poprawka w przygotowaniu” albo „naprawiono w wersji X”. VEX oszczędza czas zespołu i klientów, którzy dostają wykaz, bo nie muszą sami analizować każdego alertu. Format CycloneDX obsługuje VEX bezpośrednio, a materiały CISA opisują minimalne wymagania dla takich dokumentów.
Ważne, żeby decyzje „nie dotyczy” miały uzasadnienie zapisane w dokumentacji. Jeśli podatność okaże się jednak wykorzystywana, organ nadzoru rynku zapyta, na jakiej podstawie producent ją wcześniej odrzucił.
Cyber Resilience Act nie wymaga publikowania wykazu komponentów, ale klienci przemysłowi, szczególnie objęci NIS2, coraz częściej pytają o niego przy ocenie dostawców. W praktyce stosuje się trzy modele. Pierwszy: wykaz tylko w dokumentacji technicznej, udostępniany organom nadzoru na żądanie. Drugi: wykaz dla klientów na podstawie umowy o poufności, na przykład w portalu klienta. Trzeci: wykaz publiczny, co ma sens głównie dla oprogramowania open source albo produktów, w których przejrzystość jest argumentem sprzedażowym.
Niezależnie od modelu wykaz powinien być powiązany z konkretną wersją produktu i aktualizowany przy każdym wydaniu. Wykaz sprzed dwóch lat dla urządzenia, które od tego czasu dostało pięć aktualizacji, jest gorszy niż jego brak, bo daje fałszywe poczucie wiedzy o produkcie.
Każdy z tych błędów da się uniknąć na etapie projektowania procesu. Najwięcej kosztuje naprawianie ich pod presją czasu, na przykład w dniu, w którym trzeba w 24 godziny ustalić, czy nowa podatność dotyczy produktu sprzedanego trzy lata temu.
Producent sterowników ogrzewania sprzedaje trzy generacje urządzeń. Najnowsza ma firmware oparty na systemie czasu rzeczywistego, stos sieciowy od producenta układu i kilkanaście bibliotek open source, w tym bibliotekę TLS. Do tego dochodzi aplikacja mobilna i backend w chmurze, z którego urządzenia pobierają aktualizacje.
Pełny obraz wymaga kilku wykazów: dla firmware każdej wspieranej generacji, dla aplikacji mobilnej i dla backendu. Firmware jest najtrudniejszy, bo część bibliotek skopiowano do repozytorium lata temu, a SDK od producenta układu zawiera pliki binarne. Zespół generuje je więc automatycznie w systemie budowania, a brakujące komponenty uzupełnia na podstawie dokumentacji SDK i ręcznego przeglądu katalogów z kodem zewnętrznym.
Efekt widać przy pierwszym poważnym alercie. Gdy w bibliotece TLS pojawia się krytyczna podatność, zespół w kilkanaście minut ustala, że dotyczy ona dwóch z trzech generacji, sprawdza, czy podatna funkcja jest używana, i przygotowuje dokument VEX dla klientów. Bez wykazu ta sama analiza wymagałaby przeszukiwania repozytoriów i dopytywania byłych pracowników, która wersja biblioteki trafiła do której wersji firmware.
Producent, który sprzedaje urządzenia firmom energetycznym, wodociągom czy zakładom produkcyjnym, będzie coraz częściej słyszał pytanie o wykaz komponentów od klientów. Firmy objęte NIS2 muszą oceniać bezpieczeństwo swoich dostawców, w tym jakość ich produktów i procedur bezpiecznego wytwarzania. SBOM i dokumenty VEX są prostym sposobem, żeby to wykazać. Producent, który ma je gotowe, skraca proces oceny dostawcy i zyskuje przewagę w przetargach, w których wymagania bezpieczeństwa należą do kryteriów wyboru.
Sanddev wdraża automatyczne generowanie wykazu komponentów w procesie budowania, porządkuje zależności w starszym kodzie i łączy wykaz z monitorowaniem podatności. Opisujemy to na stronie o tym, jak wygląda budowa i rozwój oprogramowania na zamówienie.
SBOM (software bill of materials) to wykaz komponentów oprogramowania: lista bibliotek, modułów i ich wersji, z których zbudowano produkt, wraz z dostawcami i zależnościami. Pozwala szybko ustalić, czy nowa podatność dotyczy produktu.
Tak. Od 11 grudnia 2027 r. Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi sporządzenia SBOM w formacie odczytywalnym maszynowo, obejmującego co najmniej zależności najwyższego poziomu, jako części dokumentacji technicznej.
Nie. Cyber Resilience Act nie wymaga publikowania wykazu. Producent przechowuje go w dokumentacji technicznej i udostępnia organom nadzoru rynku na żądanie; może też zdecydować się udostępnić go klientom.
Oba formaty spełniają wymagania CRA. SPDX jest normą ISO/IEC 5962:2021 i dobrze opisuje licencje, a CycloneDX (ECMA-424) jest nastawiony na bezpieczeństwo i obsługuje dokumenty VEX. Wybór zależy od narzędzi i oczekiwań klientów.
CRA wymaga co najmniej zależności najwyższego poziomu. W praktyce pełniejszy wykaz, obejmujący także zależności pośrednie, lepiej sprawdza się przy ocenie, czy nowa podatność dotyczy produktu.
OWASP Top 10 to lista najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowana przez fundację OWASP i używana jako punkt odniesienia przez zespoły bezpieczeństwa i audytorów. Aplikacje zbudowane z pomocą AI, na przykład w Lovable z bazą Supabase, najczęściej zawodzą w tych samych miejscach, co opisuje OWASP Top 10, przede wszystkim w kontroli dostępu.
SZBI, czyli system zarządzania bezpieczeństwem informacji, to główny obowiązek podmiotów kluczowych i ważnych według znowelizowanej ustawy o KSC; trzeba go wdrożyć do 3 kwietnia 2027 r.
Cyber Resilience Act (CRA, po polsku akt o cyberodporności) od 11 września 2026 r. nakłada na producentów produktów z elementami cyfrowymi obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
