Software Bill of Materials (SBOM)

Software Bill of Materials (SBOM), czyli „lista składników oprogramowania”, to czytelny dla maszyn spis wszystkich komponentów, bibliotek i zależności, z których zbudowany jest dany program. Przy każdej pozycji znajdują się dane o jej pochodzeniu, wersji i licencji. SBOM działa jak spis składników na opakowaniu produktu spożywczego: pokazuje dokładnie, co jest w środku — łącznie z zależnościami tranzytywnymi, czyli komponentami, które wciąga pośrednio inny komponent. To podstawowe narzędzie do panowania nad ryzykiem w łańcuchu dostaw oprogramowania i do szybkiego znajdowania podatnych elementów.

Co zawiera SBOM?

Amerykańska agencja NTIA (National Telecommunications and Information Administration) opisała tzw. minimum elements — minimalny zestaw pól, które powinien mieć każdy komponent w SBOM. Należą do nich:

• Nazwa dostawcy (supplier name) — kto stworzył lub zidentyfikował komponent.
• Nazwa komponentu (component name) — nazwa danej jednostki oprogramowania.
• Wersja (version) — wskazuje konkretne wydanie. Dzięki temu da się odróżnić wersję podatną od już załatanej.
• Inne unikalne identyfikatory — np. Package URL (purl), CPE czy tagi SWID. Pozwalają jednoznacznie połączyć komponent z bazami podatności.
• Relacja zależności (dependency relationship) — informacja, który komponent zawiera się w którym, czyli całe drzewo zależności.
• Autor danych SBOM — kto wygenerował sam dokument (niekoniecznie ten sam podmiot, co dostawca komponentu).
• Znacznik czasu (timestamp) — data i godzina utworzenia rekordu.

Poza polami z danymi NTIA wskazuje też wymagania dotyczące automatyzacji (generowanie i przekazywanie w formacie czytelnym dla maszyn) oraz praktyk i procesów (jak często aktualizować, jak głęboko schodzić w drzewo zależności, jak obsługiwać tzw. known unknowns — znane luki w wiedzy, kontrola dostępu, obsługa błędów). W praktyce SBOM bywa wzbogacany o sumy kontrolne komponentów (hash) oraz odwołania do znanych podatności (CVE).

Jakie są formaty SBOM? (SPDX, CycloneDX, SWID)

SBOM zapisuje się w ustandaryzowanych formatach, które maszyna potrafi odczytać. Trzy są powszechnie uznawane (m.in. przez NTIA):

• SPDX (Software Package Data Exchange) — rozwijany przez Linux Foundation, znormalizowany jako ISO/IEC 5962:2021. Powstał głównie z myślą o zgodności licencyjnej i audycie open source; pozwala analizować pliki, a nawet fragmenty kodu. Obsługuje zapis w formie tag-value, JSON, YAML i RDF/XML.
• CycloneDX — rozwijany przez OWASP, z naciskiem na bezpieczeństwo i zarządzanie podatnościami. Ma zwięzły, komponentowy model danych i wbudowaną obsługę informacji o podatnościach oraz VEX (o nim niżej). Obsługuje JSON, XML i Protocol Buffers.
• SWID (Software Identification Tags) — norma ISO/IEC 19770-2, nastawiona na inwentaryzację zasobów IT i licencjonowanie. Działa jak unikalny identyfikator instalacji, ale sam w sobie nie pokazuje pełnego drzewa zależności. Dlatego do zastosowań bezpieczeństwa używa się głównie SPDX i CycloneDX.

Jak powstaje SBOM?

Tworzenie SBOM przebiega zwykle w trzech krokach i jest automatyzowane w pipeline CI/CD (czyli w procesie automatycznego budowania i wdrażania oprogramowania):

1. Wykrycie komponentów — narzędzie skanuje kod, pliki z listą zależności (np. package-lock.json, pom.xml, go.sum) lub gotowe artefakty i obrazy kontenerów, żeby wypisać użyte biblioteki i pakiety.
2. Zebranie metadanych — pobranie wersji, licencji, identyfikatorów, sum kontrolnych i ewentualnych odwołań do podatności.
3. Wygenerowanie dokumentu — zapis danych w wybranym formacie (SPDX lub CycloneDX).

SBOM można utworzyć na różnych etapach: ze źródeł (source), w trakcie budowania (build), z gotowego pliku wynikowego (binary/analyzed) albo przy wdrożeniu. Wersja z fazy budowania bywa najwierniejsza, bo pokazuje zależności faktycznie wpięte do programu. Popularne narzędzia open source to m.in. Syft i Trivy.

Dlaczego SBOM ma znaczenie dla bezpieczeństwa łańcucha dostaw?

Większość dzisiejszych aplikacji opiera się na komponentach open source i bibliotekach od innych dostawców. Często są one wielopoziomowe i niewidoczne wprost dla zespołu. Bez spisu organizacja nie wie, co tak naprawdę uruchamia. A jeśli nie wie, nie potrafi ocenić, czy nowo ujawniona podatność jej dotyczy.

• Log4Shell (CVE-2021-44228) — krytyczna podatność w bibliotece Apache Log4j, ujawniona w grudniu 2021. Problemem nie było samo jej istnienie, lecz ustalenie, gdzie Log4j w ogóle jest używany — często jako głęboko ukryta zależność tranzytywna. Firmy z aktualnym SBOM mogły niemal od razu wskazać dotknięte systemy, zamiast przeszukiwać wszystko ręcznie.
• SolarWinds (2020) — atak na łańcuch dostaw, w którym złośliwy kod wstrzyknięto do procesu budowania zaufanego oprogramowania (Orion) i rozesłano przez legalną aktualizację. Incydent pokazał, jak ważna jest możliwa do zweryfikowania przejrzystość pochodzenia i integralności komponentów.

W reakcji na takie zagrożenia Executive Order 14028 (rozporządzenie wykonawcze prezydenta USA z maja 2021) nakazał dostawcom oprogramowania dla agencji federalnych dołączanie SBOM. NTIA i CISA (agencja ds. cyberbezpieczeństwa) opracowały wtedy wytyczne co do minimalnych elementów i formatów. Tak SBOM stał się wymogiem regulacyjnym i elementem należytej staranności przy zakupach oprogramowania.

Czym jest VEX i jak uzupełnia SBOM?

SBOM mówi, jakie komponenty są obecne. Nie rozstrzyga jednak, czy dana podatność da się w danym produkcie realnie wykorzystać. Tę lukę wypełnia VEX (Vulnerability Exploitability eXchange) — towarzyszący dokument, w którym dostawca podaje status podatności wobec swojego produktu: not affected (nie dotyczy), affected (dotyczy), fixed (naprawione) lub under investigation (w analizie).

VEX ogranicza zalew zbędnych alertów. Bez niego zestawienie SBOM z bazą CVE wskazuje jako zagrożone także te komponenty, które wprawdzie są obecne, ale w danym produkcie nie da się ich wykorzystać. CycloneDX obsługuje VEX wbudowanie; w świecie SPDX robi się to przez osobne dokumenty towarzyszące.

SBOM w zarządzaniu podatnościami i monitorowaniu

W codziennej pracy zespołów bezpieczeństwa SBOM jest źródłem prawdy o tym, co jest wdrożone. Gdy pojawia się nowe CVE, zespół zestawia identyfikatory komponentów z SBOM-ów wdrożonych systemów i od razu widzi, co jest narażone — bez skanowania całego środowiska od nowa. Dla SOC (centrum operacji bezpieczeństwa) i zespołów reagowania skraca to czas od ujawnienia podatności do jej priorytetyzacji i naprawy.

SBOM dobrze uzupełnia widoczność po stronie sieci. Telemetria sieciowa (przepływy, ruch, fingerprinting) pokazuje, co i jak się komunikuje, a SBOM — z jakich komponentów zbudowane są działające w sieci usługi. Połączenie obu warstw pozwala dokładniej powiązać aktywny ruch z konkretnym, potencjalnie podatnym oprogramowaniem oraz wychwytywać różnice między tym, co zadeklarowano, a tym, co faktycznie działa.

Ograniczenia i wyzwania SBOM

• Aktualność — SBOM to migawka stanu z chwili budowania. Bez automatyzacji szybko się dezaktualizuje wraz ze zmianami w kodzie i wersjach.
• Kompletność — komponenty ładowane dynamicznie, wkompilowane na stałe lub celowo zaciemnione bywają trudne do wykrycia. Stąd known unknowns — luki, o których wiadomo, że istnieją, ale nie wiadomo, co dokładnie kryją.
• Interoperacyjność — różnice między formatami i narzędziami utrudniają spójne korzystanie z SBOM-ów od wielu dostawców.
• Skala i dystrybucja — generowanie, przechowywanie, wersjonowanie i bezpieczne udostępnianie SBOM-ów dla wielu produktów wymaga ułożonego procesu, a nie działań od przypadku do przypadku.

Dowiedz się więcej

• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR pokazuje ryzyko nieautoryzowanego dostępu do danych, które SBOM pomaga powiązać z podatnymi komponentami.
• Zero-Day Exploit — SBOM nie usuwa zero-day, ale ułatwia szybkie ustalenie, gdzie podatny komponent jest użyty.
• Monitoring sieci i network visibility – analiza ruchu sieciowego jako podstawa visibility cybersecurity — Widoczność sieci pomaga wykrywać aktywność podatnych komponentów wyszczególnionych w SBOM.
• ARP Spoofing – jak wykryć atak Man-in-the-Middle i zatruwanie ARP w sieci LAN — ARP spoofing dotyczy sieci, a SBOM wspiera ocenę ryzyka komponentów wrażliwych na takie ataki.