Czym jest SBOM i dlaczego ma znaczenie
Software Bill of Materials (SBOM) to ustrukturyzowany dokument opisujący składniki oprogramowania — biblioteki, zależności, frameworki — wraz z ich wersjami, licencjami i relacjami między nimi. Analogia do etykiety składników na produkcie spożywczym jest trafna: tak jak producent żywności musi ujawnić co jest w produkcie, dostawca oprogramowania jest coraz częściej zobowiązany do ujawnienia z czego jest zbudowane jego oprogramowanie.
SBOM odpowiada na pytania które stały się krytyczne po incydentach takich jak Log4Shell z 2021 roku: jakie komponenty open-source są w produkcie, w jakich wersjach, i czy któryś z nich ma znane podatności. Bez SBOM odpowiedź na te pytania w skali setek aplikacji zajmuje tygodnie. Z SBOM — godziny lub minuty.
Skąd presja na SBOM?
Kilka równoległych trendów zbiera się w tym samym czasie. US Executive Order 14028 z 2021 roku wymaga SBOM dla oprogramowania dostarczanego do administracji rządowej USA — co stworzyło de facto standard dla całej branży. Cyber Resilience Act, nadchodzące rozporządzenie UE dotyczące produktów z elementami cyfrowymi, idzie w tym samym kierunku dla rynku europejskiego. NIS2 wymaga zarządzania bezpieczeństwem łańcucha dostaw od podmiotów objętych dyrektywą — a dostawcy oprogramowania są częścią tego łańcucha.
Niezależnie od regulacji, wymagania kontraktowe dużych organizacji Enterprise wyprzedzają regulatorów. Firmy z branży finansowej, zdrowotnej i technologicznej coraz częściej włączają wymóg SBOM do zapytań ofertowych — zanim jeszcze regulacje ich do tego zmuszą.
Formaty i standardy
Dwa główne standardy to CycloneDX (rozwijany przez OWASP, preferowany w kontekście bezpieczeństwa) i SPDX (Linux Foundation, szeroko używany przez GitHub i narzędzia compliance licencyjnego). Oba są otwartymi standardami z szerokim wsparciem w narzędziach DevSecOps.
Wybór formatu zależy od kontekstu użycia — jeśli głównym zastosowaniem jest weryfikacja podatności, CycloneDX ma bogatszy model danych bezpieczeństwa. Jeśli priorytetem jest compliance licencyjny — SPDX jest szerzej wspierany przez narzędzia prawne.
SBOM a odpowiedź na incydenty bezpieczeństwa
Kiedy pojawia się nowa podatność (jak Log4Shell, XZ Utils, lub dziesiątki innych każdego roku), organizacje z aktualnym SBOM mogą w ciągu godzin odpowiedzieć na pytanie: czy jesteśmy dotknięci? Które produkty używają tej biblioteki, w jakich wersjach?
Organizacje bez SBOM spędzają w takich sytuacjach dni lub tygodnie na manualnym przeszukiwaniu kodu i zależności — podczas gdy czas reakcji jest krytyczny zarówno z perspektywy bezpieczeństwa jak i komunikacji z klientami.
SBOM jako element procesu, nie jednorazowy dokument
SBOM ma wartość tylko jeśli jest aktualny. Jednorazowo wygenerowany dokument staje się nieaktualny przy każdej zmianie zależności. Dlatego generowanie SBOM musi być częścią pipeline’u wytwórczego — automatycznie przy każdym release, dołączony jako artefakt wydania.
To z kolei oznacza że organizacja musi mieć odpowiednio dojrzały pipeline aby SBOM był możliwy do wdrożenia w ten sposób. Brak hardeningu CI/CD i brak SBOM to często dwa aspekty tego samego problemu — niedojrzałości procesu wytwórczego z perspektywy bezpieczeństwa.
Czytaj również: