SBOM (wykaz komponentów oprogramowania)

SBOM (Software Bill of Materials) to maszynowo czytelny wykaz komponentów, bibliotek i zależności, z których składa się oprogramowanie, wraz z ich wersjami. CISA opisuje SBOM jako zagnieżdżony spis, listę składników tworzących komponenty oprogramowania ^[1]. NTIA definiuje go jako formalny zapis szczegółów i relacji w łańcuchu dostaw komponentów użytych do zbudowania oprogramowania ^[2]. Dzięki takiemu wykazowi można szybko sprawdzić, czy produkt zawiera element z nowo ogłoszoną podatnością.

Jak działa

SBOM powstaje zwykle automatycznie podczas budowania oprogramowania. Narzędzie odczytuje pliki zależności, na przykład composer.lock czy package-lock.json, i zapisuje listę komponentów w standardowym formacie. Wykaz trafia do dokumentacji produktu albo do odbiorcy. Gdy pojawia się nowy wpis CVE, odbiorca porównuje go z wykazem, zamiast przeszukiwać kod.

Porównanie z bazą podatności, na przykład OSV, daje listę trafień. Nie każde trafienie oznacza realne zagrożenie: podatna funkcja może nie być używana. Do przekazania tej informacji służy VEX, czyli według CISA poświadczenie w formie komunikatu bezpieczeństwa, które mówi, czy produkt jest dotknięty znaną podatnością ^[1]. Cały obieg pokazuje schemat poniżej.

RYS. 1Obieg SBOM w zarządzaniu podatnościami

Składniki

Raport NTIA z 12 lipca 2021 roku, przygotowany na polecenie amerykańskiego rozporządzenia wykonawczego 14028, określa minimalne elementy SBOM ^[2]. Dane o każdym komponencie zestawia tabela.

CISA opublikowała w 2025 roku projekt zaktualizowanych minimalnych elementów SBOM do konsultacji ^[1].

Formaty

W praktyce używa się dwóch otwartych standardów.

• CycloneDX rozwijają OWASP Foundation i Ecma International; specyfikacja została znormalizowana jako ECMA-424 ^[5]. Poza SBOM opisuje też wymianę informacji o podatnościach (VEX) i dostępna jest w JSON, XML i Protocol Buffers ^[5].
• SPDX to otwarty standard przekazywania informacji o składzie oprogramowania, w tym o pochodzeniu, licencjach i bezpieczeństwie; jest uznany jako norma ISO/IEC 5962:2021 i rozwijany jako projekt Linux Foundation ^[6].

Znaczenie

SBOM skraca czas od ogłoszenia podatności do odpowiedzi na pytanie, czy dotyczy ona danego produktu. Jest narzędziem zarządzania podatnościami i zarządzania ryzykiem dostawców (third-party risk management), a także podstawą obrony przed atakiem na łańcuch dostaw (supply chain attack). Sekurak, omawiając zgodność z NIS2, wymienia prowadzenie wykazu komponentów obok oceny kondycji projektów, zamrażania wersji, weryfikacji sum kontrolnych i szybkiej reakcji na podatności ^[8].

W Unii Europejskiej SBOM staje się obowiązkiem prawnym. Akt o cyberodporności (Cyber Resilience Act) w załączniku I wymaga od producentów identyfikowania i dokumentowania podatności i komponentów produktu, w tym sporządzenia zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu ^[3]. Organy nadzoru rynku mogą zwrócić się do producentów o przedłożenie takich zestawień ^[3]. Rozporządzenie weszło w życie 10 grudnia 2024 roku, obowiązki zgłaszania stosuje się od 11 września 2026 roku, a główne przepisy od 11 grudnia 2027 roku ^[4].

Ograniczenia

SBOM jest tylko wykazem. Nie usuwa podatności, nie ocenia jakości kodu i nie mówi, czy komponent jest nadal utrzymywany. Jego wartość zależy od kompletności: wykaz obejmujący tylko zależności bezpośrednie pominie biblioteki dołączone pośrednio. Wymóg aktu o cyberodporności obejmuje co najmniej zależności najwyższego poziomu ^[3], więc głębszy wykaz jest decyzją producenta. Wykaz starzeje się też z każdą aktualizacją, dlatego powinien powstawać razem z każdym wydaniem. Wreszcie SBOM odpowiada na pytanie, co jest w produkcie, ale nie na pytanie, czy da się to wykorzystać; do tego służą ocena trafień i dokumenty VEX ^[1].

W WordPressie

Strona WordPress to zbiór komponentów: rdzeń, wtyczki, motywy i biblioteki dołączone do nich przez autorów. Wytyczne katalogu WordPress.org wymagają, by wtyczki korzystały z bibliotek dostarczanych przez WordPress, takich jak jQuery, SimplePie czy PHPMailer, zamiast dołączać własne kopie ^[7]. Inne biblioteki, np. instalowane przez Composer, wtyczka może mieć w swoim katalogu i właściciel strony zwykle ich nie widzi.

Taka ukryta biblioteka bywa źródłem podatności we wtyczce, o której właściciel strony dowiaduje się dopiero z komunikatu autora. Kategoria Vulnerable and Outdated Components z listy OWASP opisuje właśnie ten problem. Namiastką SBOM na poziomie witryny jest spis wtyczek i motywów z wersjami, np. z polecenia wp plugin list, porównywany z bazami podatności. Warto przy tym oznaczać porzucone wtyczki, bo dla nich nikt nie wyda poprawki.

Autorzy wtyczek komercyjnych, którzy sprzedają je w UE, powinni sprawdzić, czy ich produkt podlega aktowi o cyberodporności ^[4].

Dobre praktyki

• Generować SBOM automatycznie przy każdym wydaniu, a nie ręcznie.
• Używać formatu CycloneDX albo SPDX ^{[5] [6]}, żeby wykaz dało się przetwarzać narzędziami.
• Porównywać wykaz z bazami podatności stale, a nie tylko w chwili wydania; zob. skanowanie podatności.
• Publikować VEX dla trafień, które nie dotyczą produktu ^[1].
• Łączyć SBOM z podpisywaniem kodu (code signing), by odbiorca wiedział, że wykaz i artefakt pochodzą od producenta.
• Dla obrazów kontenerów stosować skanowanie obrazów kontenerów przed wdrożeniem.