Dobre praktyki SBOM

Generowanie SBOM-ów

1. Generować w CI, dla każdego wydania

SBOM tworzony ręcznie dezaktualizuje się, zanim ktokolwiek go przeczyta. Należy uczynić go krokiem w pipeline, który buduje wydanie, albo użyć runnera, który tworzy go w ogóle bez dodatkowego kroku, tak aby żadne wydanie nie wyszło bez SBOM. Dla GitHub Actions zob. jak wygenerować SBOM w GitHub Actions.

2. Opisywać build, który został dostarczony

Buildy nie są domyślnie powtarzalne. Dwukrotne zbudowanie tego samego commita nie gwarantuje tych samych zależności, ponieważ wersje są rozwiązywane w czasie buildu, a kroki mogą się różnić. SBOM z laptopa lub z późniejszego skanu opisuje podobny build, a nie ten, który Państwo dostarczyli. Tylko SBOM z buildu CI, który wytworzył wydanie, dowodzi, co w nim jest. Zob. SBOM-y z czasu buildu.

3. Obejmować więcej niż lockfile

Lockfile nie jest zapisem tego, co zostało dostarczone. Skrypty instalacyjne pobierają kod, skrypty buildu w Rust pobierają pliki, a buildy kontenerów wprowadzają obraz bazowy z własnymi pakietami systemu operacyjnego. Należy ustalić, co SBOM musi obejmować, a potem to przetestować: wyszukać w SBOM pakiet z obrazu bazowego i narzędzie buildu.

4. Uwzględniać zależności przechodnie i relacje

Podatności zwykle kryją się poniżej zależności bezpośrednich. Płaska lista pokazuje, że komponent istnieje, ale nie pokazuje, co zaktualizować. Warto zachować w SBOM graf zależności, aby znalezisko wskazywało pakiet, który pobiera dany komponent.

5. Podawać, czego nie udało się zobaczyć

2026 Minimum Elements wymagają od autorów SBOM jawnego wskazania nieznanych informacji. Częściowy SBOM, który to przyznaje, jest wart więcej niż częściowy SBOM udający gotowy. Należy też zapisywać narzędzie, jego wersję i kontekst generowania, aby czytelnik mógł ocenić, co plik obejmuje.

Przechowywanie SBOM-ów

6. Trzymać jeden SBOM na wydanie, powiązany z artefaktem

Gdy klient korzystający ze starej wersji pyta, czy jest narażony, potrzebny jest SBOM tej wersji, a nie najnowszy. Każdy SBOM należy przechowywać razem z buildem i artefaktem, który opisuje, a okres przechowywania ustalić na podstawie tego, jak długo wydanie jest wspierane. Skróty (hashes) w SBOM pomagają powiązać go z dokładnym artefaktem.

7. Wybrać format i identyfikator i się ich trzymać

Warto ustandaryzować CycloneDX lub SPDX, wersję formatu oraz package URL jako identyfikatory. Większość trudności przy porównywaniu SBOM-ów wynika z tego, że narzędzia różnie nazywają to samo. Każdy plik należy walidować w pipeline, a od dostawców wymagać tego samego formatu.

Korzystanie z SBOM-ów

8. Monitorować to, co dostarczone, nie tylko to, co powstaje

Najcenniejszy moment dla SBOM to dzień po opublikowaniu biuletynu dotyczącego oprogramowania wydanego w zeszłym roku. Skan w pull requeście w niczym wtedy nie pomoże. Przechowywane SBOM-y wspieranych wydań należy ponownie oceniać względem nowych danych o podatnościach, tak aby nowy biuletyn zamieniał się w listę wydań, których dotyczy.

9. Kierować znaleziska do właściciela i zapisywać decyzję

SBOM z tysiącem dopasowanych podatności to lista, a nie plan. Znaleziska należy uszeregować metodą priorytetyzacji, każde przekazać zespołowi odpowiedzialnemu za poprawkę, a przy pozostałych zapisać, dlaczego nie podjęto działań, na przykład w oświadczeniu VEX.

10. Używać tego samego SBOM dla klientów i audytorów

Klienci, audytorzy i regulatorzy zadają podobne pytania. Warto odpowiadać na nie na podstawie SBOM, którego używają Państwa zespoły, zamiast tworzyć osobny dokument, który z czasem się rozjedzie. Jeśli udostępniają Państwo SBOM-y, należy ustalić, kto może je zobaczyć i jak otrzymuje aktualizacje, oraz wymagać tego samego od dostawców.

Częste błędy

Błąd	Dlaczego szkodzi	Co zamiast tego
Jeden SBOM na repozytorium	Nie mówi nic o żadnym konkretnym wydaniu	Jeden na wydanie, powiązany z artefaktem
Generowanie tylko na potrzeby audytu	Opisuje build, którego nikt nie dostarczył	Każde wydanie, w CI
Traktowanie SBOM jako gotowego	Nowe biuletyny pojawiają się po wydaniu	Dalsze monitorowanie
Porównywanie tylko liczby komponentów	Więcej nie znaczy lepiej, jeśli wpisy są błędne	Sprawdzanie konkretnych pakietów, o których wiadomo, że tam są

Jak robi to CRACI

CRACI obejmuje praktyki zależne od buildu. To runner GitHub Actions, który rejestruje każdy pakiet pobrany przez każde zadanie, łącznie z ukrytymi zależnościami, których nie wymienia żaden lockfile, w SBOM CycloneDX lub SPDX ze stanem kompletności. Zachowuje każdy wcześniejszy build i jego SBOM w ramach okresu przechowywania Państwa planu, ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych podatności i pokazuje, które buildy zawierały podatną zależność. Zespoły bezpieczeństwa analizują znaleziska i przekazują je zespołom odpowiedzialnym za poprawkę. Porównanie menedżerów opisuje zarządzanie SBOM, a szerszy wybór przedstawia zestawienie najlepszych narzędzi SBOM.

Dobre praktyki SBOM: najczęściej zadawane pytania

Kiedy należy generować SBOM?

Za każdym razem w trakcie buildu CI, który wytwarza wydanie. SBOM utworzony w tym momencie opisuje to, co zostało dostarczone, a utworzony później opisuje ponowny build lub skan.

Jak długo należy przechowywać SBOM-y?

Co najmniej tak długo, jak wydanie jest wspierane, oraz tyle, ile wymagają regulatorzy lub umowy. SBOM starej wersji jest potrzebny, aby ustalić, czy nowa podatność dotyczy jej użytkowników.

Czy SBOM-y należy automatyzować?

Tak. Ręczny SBOM jest nieaktualny już przy następnym wydaniu. SBOM-y należy generować w pipeline, tam je walidować i przechowywać razem z buildem.

Czy należy udostępniać SBOM klientom?

Tak, gdy prosi o to klient lub regulator, na warunkach, które są dla Państwa do przyjęcia. SBOM ujawnia, czego Państwo używają, dlatego wiele firm udostępnia go na żądanie zamiast publikować.

Czym różni się SBOM od zarządzania SBOM?

SBOM to jeden plik. Zarządzanie SBOM to ciągła praca polegająca na przechowywaniu SBOM-ów według wydań, monitorowaniu ich pod kątem nowych podatności i udostępnianiu ich osobom, które ich potrzebują.