SBOM: co to jest i jak wdrożyć CycloneDX, SPDX i VEX

SBOM, czyli Software Bill of Materials, to maszynowo czytelny spis komponentów tworzących oprogramowanie: bibliotek, wersji, zależności, dostawców i relacji. Gdy pojawia się krytyczne CVE, dobrze utrzymany SBOM pozwala w kilka minut odpowiedzieć, które produkty zawierają podatny komponent. Bez niego organizacja przeszukuje repozytoria, obrazy i dokumentację ręcznie, często zbyt późno.

Sam plik SBOM nie zapewnia bezpieczeństwa. Musi być generowany z właściwego etapu, aktualny, powiązany z konkretnym artefaktem, podpisany i zintegrowany z procesem obsługi podatności. CycloneDX i SPDX opisują format, VEX dodaje kontekst podatności, a podpis i provenance pomagają udowodnić pochodzenie.

Co to jest SBOM — prosty przykład

Wyobraź sobie aplikację w wersji 4.8.2. Korzysta bezpośrednio z frameworka webowego, klienta bazy oraz biblioteki kryptograficznej. Każdy z tych komponentów ma własne zależności. SBOM zapisuje drzewo w ustandaryzowanej formie:

produkt i jego wersję;
każdy komponent oraz wersję;
unikalne identyfikatory, np. PURL lub CPE;
dostawcę i autora;
relacje zależności;
hashe artefaktów;
licencje;
czas i narzędzie utworzenia dokumentu.

Jeśli biblioteka jest skopiowana do repo, zainstalowana przez manager pakietów, wbudowana w kontener albo dołączona przez system operacyjny, różne metody generowania mogą dać różne wyniki. Dlatego SBOM musi wskazywać, czego dotyczy i jak powstał.

Aktualne Minimum Elements for an SBOM opublikowane przez CISA rozszerzają wcześniejsze podejście do minimalnych danych i automatyzacji. Dokument podkreśla potrzebę identyfikacji komponentów, relacji, wersji i spójnego procesu wymiany.

CycloneDX vs SPDX — który format wybrać

CycloneDX

CycloneDX powstał w społeczności OWASP z naciskiem na bezpieczeństwo łańcucha dostaw. Obsługuje komponenty, usługi, zależności, podatności, licencje, formulation oraz dodatkowe dane operacyjne. Jest popularny w narzędziach AppSec, SCA i kontenerach.

Format występuje w JSON, XML oraz protobuf. Dla większości pipeline JSON jest wygodny do przetwarzania i diffów. CycloneDX może również przenosić informacje VEX, ale trzeba sprawdzić kompatybilność odbiorcy.

SPDX

SPDX jest projektem Linux Foundation i standardem ISO/IEC 5962. Początkowo mocno koncentrował się na licencjach oraz zgodności open source, a obecne wersje obejmują szersze dane łańcucha dostaw. Jest często wymagany przez działy prawne, producentów i sektor publiczny.

Wybór nie powinien być wojną formatów. Zapytaj, co obsługuje ekosystem, klienci, regulator i narzędzia. Możliwe jest generowanie obu z tego samego artefaktu, ale konwersja może utracić część pól. Ustal jeden format kanoniczny i testuj eksport.

Kryterium	CycloneDX	SPDX
Główny rodowód	Bezpieczeństwo aplikacji	Licencje i open source compliance
Typowe użycie	SCA, podatności, usługi, VEX	Licencje, komponenty, wymiana w łańcuchu
Standaryzacja	Standard OWASP/ECMA	ISO/IEC 5962
Formaty	JSON, XML, protobuf	JSON, YAML, RDF, tag-value i inne
Wybór	Gdy pipeline jest security-first	Gdy ważna jest interoperacyjność i compliance

SBOM z kodu, buildu czy środowiska runtime

SBOM z manifestu zależności jest szybki, ale pokazuje deklaracje, niekoniecznie faktyczny artefakt. package-lock.json może zawierać pakiety deweloperskie, których nie ma w produkcji. Z kolei ręcznie skopiowana biblioteka może nie występować w manifeście.

SBOM generowany w buildzie widzi to, co trafia do obrazu lub pakietu. To zwykle najlepszy punkt do powiązania z wydaniem. Skan obrazu kontenera wykrywa również pakiety systemowe. Runtime SBOM obserwuje elementy załadowane lub obecne w środowisku, lecz może pominąć rzadko używane ścieżki.

Dojrzały program łączy perspektywy:

source SBOM dla planowanych zależności;
build SBOM jako dokument wydania;
image/system SBOM dla warstwy systemowej;
runtime inventory dla potwierdzenia wdrożenia.

Nie sklejaj ich bez wskazania źródła. Użytkownik musi rozumieć, czy komponent jest zadeklarowany, zapakowany, wdrożony czy faktycznie załadowany.

Co to jest VEX i dlaczego SBOM bez niego generuje szum

Vulnerability Exploitability eXchange opisuje status produktu względem podatności. CISA Minimum Requirements for VEX wskazuje m.in. identyfikację produktu, podatności, status i uzasadnienie.

Typowe statusy odpowiadają na pytanie: czy produkt jest dotknięty, niedotknięty, naprawiony albo nadal analizowany. Przykład: SBOM zawiera bibliotekę z CVE, ale podatna funkcja nie jest kompilowana, osiągalna ani używana. Producent może wydać VEX „not affected” z konkretnym uzasadnieniem.

VEX nie może być automatycznym usprawiedliwieniem. Status powinien pochodzić od strony zdolnej ocenić produkt i zawierać dowód. Po zmianie konfiguracji, wersji albo ścieżki kodu może się zdezaktualizować.

SBOM mówi „co zawieramy”. Skaner podatności mówi „z czym powiązano CVE”. VEX mówi „jaki jest status w tym produkcie”. Razem znacznie zmniejszają kolejkę fałszywie pilnych alertów.

Minimalny pipeline SBOM w CI/CD

Wygeneruj po rozwiązaniu zależności. Użyj lockfile i narzędzia obsługującego język oraz system pakowania.
Wygeneruj ponownie z artefaktu. Skanuj obraz, binarium lub paczkę, która trafi do wydania.
Nadaj tożsamość. Powiąż SBOM z nazwą produktu, wersją, digestem i commit SHA.
Waliduj schemat. Nie publikuj pliku, którego odbiorca nie potrafi odczytać.
Podpisz i dołącz provenance. Zabezpiecz integralność i pokaż, z którego procesu pochodzi dokument.
Przechowuj z artefaktem. Rejestr kontenerów lub repozytorium wydań powinno przechowywać SBOM obok wersji.
Skanuj ciągle. Nowe CVE pojawia się po wydaniu, więc ponawiaj korelację bez przebudowy produktu.
Twórz VEX. Po analizie publikuj status i uzasadnienie dla klientów oraz zespołów wewnętrznych.
Testuj wyszukiwanie. Przeprowadź ćwiczenie: „znajdź wszystkie wdrożenia komponentu X w wersji Y”.
Ustal retencję. Zachowuj SBOM dla wspieranych i archiwalnych wersji zgodnie z cyklem życia produktu.

SBOM powinien być deterministyczny na tyle, na ile to możliwe. Dwa buildy tego samego artefaktu nie powinny różnić się losowymi identyfikatorami, które uniemożliwiają sensowny diff.

Podpisywanie SBOM, artefaktów i provenance

Napastnik, który przejmie pipeline, może podmienić zarówno artefakt, jak i jego listę składników. Dlatego hash zapisany w niepodpisanym pliku obok obrazu nie daje silnego dowodu.

Podpis kryptograficzny wiąże SBOM z tożsamością producenta. Provenance opisuje, gdzie, z jakiego źródła i przez jaki workflow zbudowano artefakt. Sigstore i SLSA dostarczają wzorce dla podpisów oraz pochodzenia. Szczegóły opisaliśmy w artykule Sigstore i SLSA.

Weryfikacja powinna odbywać się przy pobraniu i wdrożeniu, a nie tylko podczas publikacji. Polityka może blokować artefakt bez zatwierdzonego podpisu, provenance lub SBOM.

Jak używać SBOM po pojawieniu się krytycznego CVE

Procedura reagowania powinna wyglądać następująco:

znormalizuj identyfikator komponentu i wersje podatne;
przeszukaj wszystkie SBOM-y, repozytoria i runtime inventory;
sprawdź relacje: zależność bezpośrednia czy tranzytywna;
potwierdź, które artefakty są rzeczywiście wdrożone;
oceń reachability, konfigurację, ekspozycję i dostępność exploita;
sprawdź VEX oraz advisory producenta;
priorytetyzuj według wpływu, KEV i wartości aktywa;
zbuduj poprawkę, wygeneruj nowy SBOM i wykonaj test regresyjny;
opublikuj advisory lub VEX dla odbiorców;
sprawdź, czy stara wersja zniknęła ze wszystkich środowisk.

To praktyczne uzupełnienie procesu zarządzania podatnościami. SBOM przyspiesza inwentaryzację, ale decyzja o priorytecie nadal wymaga kontekstu.

SBOM w umowie z dostawcą

Wymaganie „dostawca przekaże SBOM” jest zbyt ogólne. Umowa powinna określić:

format i wersję schematu;
częstotliwość oraz moment dostarczenia;
identyfikację artefaktu i wspieranych wersji;
minimalne pola oraz kompletność zależności tranzytywnych;
podpis i sposób weryfikacji;
kanał przekazywania VEX oraz advisory;
SLA dla krytycznych podatności;
zasady poufności i dalszego udostępniania;
obowiązek aktualizacji po zmianie komponentu;
możliwość testu jakości i zgodności z artefaktem.

SBOM może ujawniać szczegóły architektury i podatne wersje, więc dostęp powinien być kontrolowany. Jednocześnie traktowanie każdego SBOM-u jak tajemnicy uniemożliwia klientom zarządzanie ryzykiem. Potrzebna jest proporcjonalna polityka, nie automatyczne publikowanie wszystkiego albo całkowita odmowa.

Ten wymóg powinien być elementem TPRM, a nie dokumentem zbieranym raz podczas zakupu.

Najczęstsze błędy wdrożenia

Generowanie tylko na żądanie klienta. Plik przygotowany ręcznie po miesiącach nie jest wiarygodnym elementem wydania.

Brak wersji i digestu produktu. Nie wiadomo, którego artefaktu dotyczy dokument.

Skan wyłącznie manifestu. Pomija biblioteki vendored, pakiety systemowe i różnice buildu.

Brak zależności tranzytywnych. Najgroźniejszy komponent często nie jest deklarowany bezpośrednio.

Traktowanie każdego CVE jako krytycznego. Bez VEX, reachability i ekspozycji powstaje szum.

Brak podpisu. Nie da się potwierdzić integralności i pochodzenia listy.

Brak procesu odbioru. Organizacja zbiera tysiące plików, ale nie potrafi ich przeszukać podczas incydentu.

Brak właściciela. DevOps generuje dokument, security skanuje, legal analizuje licencje, lecz nikt nie odpowiada za jakość całości.

Jak mierzyć jakość SBOM

Nie licz tylko plików. Mierz:

procent artefaktów produkcyjnych z SBOM;
procent dokumentów powiązanych digestem i podpisem;
pokrycie zależności bezpośrednich oraz tranzytywnych;
czas znalezienia wszystkich wdrożeń wskazanego komponentu;
odsetek alertów z aktualnym statusem VEX;
różnicę między SBOM buildu a skanem obrazu;
czas publikacji nowego SBOM po wydaniu;
odsetek dostawców spełniających ustalony profil.

Najlepszym testem jest ćwiczenie na znanej bibliotece. Jeśli zespół nie potrafi w godzinę wskazać produktów, właścicieli i wdrożeń, sam wskaźnik „mamy SBOM” niewiele znaczy.

Najczęstsze pytania

Czy SBOM zawiera kod źródłowy? Nie. Zawiera metadane komponentów i relacji. Może jednak ujawniać technologie, wersje i strukturę, dlatego potrzebuje polityki dostępu.

Czy SBOM zastępuje skaner podatności? Nie. Dostarcza inwentarz. Skaner koreluje go z bazami CVE, a zespół ocenia reachability, ekspozycję i wpływ.

Czy wybrać CycloneDX czy SPDX? Wybierz format obsługiwany przez odbiorców i narzędzia. CycloneDX jest często wygodny dla security, SPDX dla licencji i interoperacyjności. Ważniejsza od etykiety jest kompletność i automatyzacja.

Czy VEX może powiedzieć, że CVE nas nie dotyczy? Tak, jeśli istnieje uzasadnienie i właściwy autorytet. Status musi być aktualizowany po zmianie produktu oraz sprawdzalny.

Czy publikować SBOM publicznie? To decyzja ryzyka i modelu dystrybucji. Można udostępniać klientom przez kontrolowany kanał. Publiczność nie naprawia braków jakości, a poufność nie powinna blokować zarządzania podatnościami.

Podsumowanie

SBOM jest fundamentem widoczności łańcucha dostaw: mówi, z czego zbudowano konkretny artefakt. CycloneDX i SPDX zapewniają interoperacyjny format, VEX dodaje status podatności, a podpis oraz provenance wzmacniają zaufanie.

Wartość powstaje dopiero w procesie. Generuj SBOM automatycznie w buildzie, porównuj z artefaktem i runtime, podpisuj, przechowuj, skanuj po każdym nowym CVE i ćwicz wyszukiwanie. Jeśli chcesz ocenić obecny pipeline i wymagania wobec dostawców, porozmawiajmy o audycie łańcucha dostaw.

Źródła i dalsza lektura: CISA — Minimum Elements for an SBOM 2025, CISA — Minimum Requirements for VEX, CycloneDX, SPDX, NIST SSDF.