Czym jest SBOM?

Co oznacza skrót SBOM?

SBOM to skrót od software bill of materials, czyli zestawienia komponentów oprogramowania. Termin pochodzi z produkcji, gdzie bill of materials wymienia części składające się na produkt. CISA opisuje SBOM jako zagnieżdżony inwentarz, listę składników tworzących komponenty oprogramowania.

Większość kodu we współczesnej aplikacji napisał ktoś inny, a większość tego kodu trafia do niej pośrednio: dodają Państwo jeden pakiet, a on wprowadza dziesiątki zależności przechodnich. SBOM zapisuje to wszystko, dzięki czemu na pytanie „czy to nas dotyczy?” można odpowiedzieć bez czytania choćby jednego repozytorium.

Co zawiera SBOM?

Użyteczny SBOM składa się z dwóch części: danych o samym SBOM i danych o każdym komponencie. 2026 Minimum Elements, opublikowane przez CISA, NSA i FBI wraz z partnerami międzynarodowymi 29 lipca 2026 r., zastępują listę NTIA z 2021 r. i wyznaczają punkt odniesienia, na który powołuje się dziś większość kupujących.

Część	Pola
O samym SBOM	Autor i podpis autora, znacznik czasu, nazwa i wersja formatu danych, nazwa i wersja narzędzia, wersja SBOM oraz kontekst generowania
O każdym komponencie	Nazwa, wersja, producent, identyfikatory takie jak package URL, wartość skrótu i algorytm, licencja oraz relacje zależności

Kontekst generowania ma większe znaczenie, niż się wydaje. Mówi, kiedy powstał SBOM: przed buildem, w trakcie buildu, z gotowego artefaktu albo po nim. Właśnie dlatego dwa SBOM-y tego samego wydania mogą się różnić. Jak te pola wyglądają w prawdziwym pliku, pokazują przykłady SBOM.

Formaty SBOM

Dwa formaty obejmują niemal wszystkie używane SBOM-y. CycloneDX z OWASP wywodzi się z obszaru bezpieczeństwa i opisuje także podatności oraz usługi. SPDX z Linux Foundation wywodzi się ze zgodności licencyjnej. Oba mogą zawierać elementy minimalne, a większość narzędzi zapisuje oba. Jak wybrać, wyjaśnia porównanie CycloneDX vs SPDX.

Dlaczego SBOM-y są ważne

• Szybsza reakcja na incydenty. Gdy pojawia się podatność taka jak Log4Shell, pytanie brzmi, które Państwa produkty ją zawierają. Z SBOM-ami to kwestia wyszukania. Bez nich to cały projekt.
• Monitorowanie podatności po wydaniu. Oprogramowanie, które w chwili dostarczenia było czyste, jutro może być podatne. Ponowne sprawdzanie przechowywanych SBOM-ów względem nowych biuletynów wychwytuje to bez ponownego budowania czegokolwiek.
• Ryzyko licencyjne. Deklarowana licencja każdego komponentu ujawnia warunki copyleft lub komercyjne, zanim trafią do produktu.
• Pytania klientów i regulatorów. Kupujący coraz częściej proszą o SBOM w procesie zakupowym, a kilka ram regulacyjnych oczekuje inwentarza komponentów.

Komu potrzebny jest SBOM?

Każdemu, kto dostarcza oprogramowanie, i każdemu, kto musi odpowiadać za jego zawartość. Wymóg zwykle pojawia się w jednym z tych obszarów:

• Wyroby medyczne. Sekcja 524B FDA wymaga SBOM dla urządzeń cybernetycznych (cyber devices) we wnioskach składanych przed wprowadzeniem na rynek.
• Produkty sprzedawane w UE. Cyber Resilience Act wymaga od producentów SBOM. Zob. wymagania CRA dotyczące SBOM i narzędzia.
• Zamówienia federalne w USA. Memorandum OMB M-26-05 ze stycznia 2026 r. pozostawia każdej agencji decyzję, czy go wymagać, dlatego trzeba się z tym liczyć zależnie od przypadku.
• Oprogramowanie płatnicze. Wymaganie 6.3.2 standardu PCI DSS 4.0 dotyczy inwentarza oprogramowania tworzonego na zamówienie i jego komponentów zewnętrznych. Nie nakazuje SBOM, ale SBOM spełnia tę potrzebę.

Jak wygenerować SBOM

Są trzy sposoby na jego utworzenie, a metoda decyduje o tym, co znajdzie się w pliku.

Metoda	Co odczytuje	Typowa luka
Skanowanie źródeł	Manifesty i lockfile w repozytorium	Wszystko, co build pobiera, a czego nie wymienia żaden lockfile
Skanowanie wyniku	Gotowy obraz kontenera lub plik binarny	Skompilowany kod jest niejednoznaczny, a narzędzia buildu nie zostawiają śladu
Rejestrowanie buildu	To, co build faktycznie pobrał w trakcie działania	Ruch omijający rejestrator, który powinien zostać oznaczony

Generatory open source, takie jak Syft, Trivy i cdxgen, korzystają z dwóch pierwszych metod. Dla tego samego commita dają różne wyniki, ponieważ każdy ma własne zasady tego, co odczytywać. Opcje zestawione obok siebie znajdą Państwo w zestawieniu najlepszych narzędzi SBOM.

SBOM vs SCA vs VEX

• SBOM to inwentarz. Mówi, co się w oprogramowaniu znajduje, a nie czy jest to bezpieczne.
• Analiza składu oprogramowania (SCA) to właśnie analiza. Znajduje komponenty i sprawdza, czy niosą ryzyko, a wiele narzędzi SCA przy okazji tworzy SBOM.
• VEX to oświadczenie o wpływie. Mówi, czy znana podatność faktycznie dotyczy Państwa produktu, co ogranicza szum generowany przez sam SBOM.

Wygenerowanie SBOM to ta łatwiejsza część

Plik, którego nikt nie czyta, niczego nie zmienia. Wartość bierze się z utrzymywania jednego SBOM na wydanie, monitorowania ich i możliwości odnalezienia ich, gdy jest to istotne. Ta praca to zarządzanie SBOM, a sposób jej prowadzenia opisują dobre praktyki SBOM.

Jak CRACI tworzy SBOM-y

CRACI to runner GitHub Actions, który rejestruje każdy pakiet pobrany przez każde zadanie, na każdym poziomie drzewa, łącznie z pakietami przywróconymi z cache CI. Wynikiem jest SBOM buildu, który wytworzył wydanie, ze stanem kompletności określającym, czego zadanie nie mogło zobaczyć. Eksportuje się go w formacie CycloneDX lub SPDX, a CRACI na bieżąco ponownie go ocenia w miarę publikowania nowych podatności. Zob. generowanie SBOM w czasie buildu.

SBOM: najczęściej zadawane pytania

Czym jest SBOM w prostych słowach?

SBOM to lista składników oprogramowania. Wymienia każdy komponent produktu wraz z wersją, producentem i licencją, w formacie czytelnym dla maszyn.

Co oznacza skrót SBOM?

SBOM to skrót od software bill of materials, czyli zestawienia komponentów oprogramowania.

Dlaczego SBOM jest potrzebny?

Aby szybko ustalić, czy nowo opublikowana podatność dotyczy tego, co Państwo dostarczają, zobaczyć ryzyko licencyjne przed wydaniem i odpowiedzieć klientom oraz regulatorom, którzy pytają, co zawiera Państwa produkt.

Jakie są dwa główne formaty SBOM?

CycloneDX i SPDX. CycloneDX pochodzi z OWASP i wywodzi się z obszaru bezpieczeństwa. SPDX pochodzi z Linux Foundation i wywodzi się ze zgodności licencyjnej. Oba mogą zawierać elementy minimalne.

Czy SBOM jest wymagany przez prawo?

To zależy od produktu i rynku. Sekcja 524B FDA wymaga go dla urządzeń cybernetycznych (cyber devices), a unijny Cyber Resilience Act wymaga go od producentów. W zamówieniach federalnych w USA decyduje dziś każda agencja. Dla wielu innych firm jest to wymóg klientów, a nie prawa.

Jak często należy aktualizować SBOM?

Nowy SBOM należy generować dla każdego wydania, ponieważ każdy build może pobrać inne wersje. SBOM danego wydania później się nie zmienia, ale trzeba go nadal sprawdzać względem nowych podatności.

Kto tworzy SBOM?

Zwykle zespół, który buduje oprogramowanie, najlepiej w CI, tak aby każde wydanie otrzymywało go automatycznie. Kupowane oprogramowanie powinno mieć SBOM od dostawcy.