Software Bill of Materials (SBOM)

Software Bill of Materials (SBOM) to formalny, czytelny maszynowo wykaz każdego komponentu zawartego w oprogramowaniu: bibliotek, ich wersji, licencji i informacji o dostawcy.

Tak jak etykieta produktu spożywczego wymienia składniki, SBOM pozwala w kilka sekund odpowiedzieć na pytanie: czy ten produkt zawiera podatną wersję X? Bez SBOM odpowiedź na to pytanie może wymagać wielu dni ręcznego przeszukiwania.

Gdy pojawia się krytyczna podatność, pierwsze pytanie operacyjne dotyczy zakresu narażenia: które z naszych produktów zawierają ten podatny komponent?

Podczas incydentu Log4Shell organizacje posiadające SBOM-y wyszukiwały informacje w swoich wykazach i przeprowadzały wstępną ocenę w ciągu kilku godzin. Organizacje bez SBOM-ów spędzały tygodnie na przeszukiwaniu katalogów budowania. Organy regulacyjne i najwięksi nabywcy coraz częściej wymagają SBOM-ów jako warunku zakupu.

• Szybka analiza wpływu podatności
• Zgodność licencyjna i śledzenie obowiązków
• Przejrzystość łańcucha dostaw dla klientów i audytorów

Dominują dwa otwarte standardy. Narzędzia zazwyczaj mogą konwertować dane między nimi.

• SPDX — standard Linux Foundation, dobrze obsługujący licencjonowanie i szeroko akceptowany przez organy regulacyjne
• CycloneDX — standard OWASP skoncentrowany na bezpieczeństwie, obsługujący dane o podatnościach i relacjach między zależnościami

Należy unikać tworzenia własnego formatu; odbiorcy i skanery oczekują tych standardów.

Każdy wpis komponentu powinien zawierać wystarczające informacje identyfikacyjne, aby można go było dopasować do źródeł informacji o podatnościach. Najważniejsze pola:

• nazwa i wersja — dokładne, a nie określone zakresem
• PURL (package URL) — uniwersalny identyfikator, taki jak pkg:npm/lodash@4.17.21
• skrót — do weryfikacji integralności
• licencja — identyfikator licencji SPDX
• dostawca — podmiot, który go wytworzył

SBOM-y należy generować automatycznie na podstawie kodu źródłowego lub zbudowanego artefaktu. Syft to popularny generator działający w różnych ekosystemach, który generuje dane w obu standardach.

SBOM wygenerowany na różnych etapach przedstawia różne informacje.

• SBOM źródłowy — to, co deklaruje manifest; może pomijać kod włączony do pakietu lub dołączony bezpośrednio do repozytorium
• SBOM kompilacji — to, co faktycznie pobrał proces budowania; najdokładniejszy dla wydania
• SBOM środowiska uruchomieniowego lub wdrożenia — to, co rzeczywiście znajduje się w uruchomionym obrazie, w tym pakiety systemu operacyjnego

W celu zapewnienia bezpieczeństwa łańcucha dostaw należy generować SBOM podczas budowania na podstawie rzeczywistego artefaktu, a także skanować finalny kontener pod kątem pakietów systemu operacyjnego.

SBOM staje się szczególnie użyteczny po przekazaniu go do narzędzia dopasowującego komponenty do znanych CVE. Oddziela to generowanie od analizy: stare SBOM-y można skanować w dniu ujawnienia nowej CVE.

SBOM może wskazywać podatny komponent, którego faktycznie nie można wykorzystać w danym produkcie (podatna funkcja nigdy nie jest wywoływana). Dokument VEX (Vulnerability Exploitability eXchange) zapisuje tę ocenę.

VEX ogranicza liczbę nieistotnych alertów: zamiast wywoływać panikę u każdego klienta z powodu wymienionej CVE, publikuje się oświadczenie not_affected wraz z uzasadnieniem albo affected wraz z działaniami naprawczymi. W ten sposób surowy wykaz staje się podstawą konkretnych działań.

SBOM jest wiarygodny tylko wtedy, gdy jest autentyczny i powiązany z dokładnym artefaktem, który opisuje. Należy go podpisać i dołączyć jako poświadczenie, a nie jako niezależny plik.

Ręcznie tworzone SBOM-y szybko tracą aktualność. Generowanie należy włączyć do potoku, aby każde wydanie tworzyło i przechowywało SBOM jako artefakt budowania, najlepiej podpisując go i skanując w ramach tego samego zadania.

• Generować na podstawie zbudowanego artefaktu, a nie tylko repozytorium
• Przechowywać SBOM-y w rejestrze umożliwiającym wyszukiwanie, z kluczem utworzonym na podstawie wersji
• Ponownie skanować przechowywane SBOM-y zgodnie z harmonogramem, korzystając z aktualnych źródeł informacji o CVE
• Blokować wydania na podstawie wyniku skanowania podatności

SBOM-y zawodzą po cichu, gdy traktuje się je tylko jako zadanie do odhaczenia.

• Nieaktualny — wygenerowany raz i nigdy niegenerowany ponownie
• Niekompletny — pomija pakiety systemu operacyjnego oraz kod statycznie linkowany lub dołączony bezpośrednio
• Niezweryfikowany — brak skrótu wiążącego go z wdrożonym artefaktem
• Niewykorzystywany — utworzony, ale nigdy nieskanowany ani niewyszukiwany

Celem jest dokładny, regularnie generowany ponownie, podpisany i stale skanowany SBOM, a nie jednorazowy plik JSON.

Można teraz zinwentaryzować zawartość oprogramowania i odpowiednio na nią reagować.

• SBOM to czytelna maszynowo lista każdego komponentu w formacie SPDX lub CycloneDX
• Komponenty należy identyfikować za pomocą PURL, wersji, skrótu i licencji
• Należy generować SBOM podczas budowania, a następnie przekazywać go do narzędzia dopasowującego (grype, osv-scanner) w celu wykrywania CVE
• Należy używać VEX do określania rzeczywistej możliwości wykorzystania podatności i ograniczania fałszywych alarmów
• Należy podpisywać i automatyzować SBOM-y w CI oraz ponownie skanować przechowywane SBOM-y pod kątem nowych informacji

Następnie: potwierdzanie pochodzenia artefaktów za pomocą podpisywania.