Generowanie SBOM w zespołach inżynierskich: jedna polityka, każdy pipeline

Dlaczego skanery poszczególnych zespołów nie składają się na program SBOM

Wystarczy skierować pięć narzędzi na ten sam produkt, aby otrzymać pięć SBOM-ów. Różnice są strukturalne, a nie są błędami:

• Różne dane wejściowe, odczytywane w różnych momentach. Jedno narzędzie czyta lockfile, inne zainstalowane drzewo zależności, inne obraz kontenera, jeszcze inne plik binarny. Każde widzi inny wycinek produktu.
• Różne nazwy tego samego. Jedno identyfikuje komponenty przez package URL, inne przez CPE, jeszcze inne tylko przez nazwę pliku. Dwóch SBOM-ów opisujących tę samą bibliotekę nie da się połączyć wspólnym kluczem.
• Różna głębokość. Niektóre wymieniają tylko zależności bezpośrednie, niektóre całe drzewo zależności przechodnich, a niektóre także narzędzia buildu. Dlaczego generatory nie zgadzają się co do tego samego repozytorium, pokazujemy w generatorach SBOM open source.
• Niektóre narzędzia odpowiadają na inne pytanie. Skanery podatności infrastruktury raportują, co jest zainstalowane na działających hostach. To przydatne dla zespołów operacyjnych, ale nie jest to opis produktu, który Państwo dostarczają.

Konsekwencja: nie można scalać, deduplikować ani porównywać SBOM-ów między produktami i nie można pokazać audytorowi jednego procesu, bo go nie ma.

Metoda	Co odczytuje	Kiedy	Czego nie widzi	Typowy identyfikator
Skaner lockfile'ów lub manifestów	Lockfile'e i manifesty w checkoucie	Przed buildem lub po nim	Wszystkiego, czego nie wymienia żaden lockfile: hooków instalacyjnych, plików pobieranych przez skrypty buildu, obrazów bazowych	Package URL
Skaner obrazów kontenerów	Bazy danych pakietów i pliki w obrazie	Po buildzie	Narzędzi używanych tylko w buildzie, wkompilowanego kodu, wszystkiego, co nie ma rekordu pakietu	Package URL dla pakietów systemu operacyjnego i języków
Skaner plików binarnych lub firmware'u	Ciągi znaków i sygnatury w pliku binarnym	Po buildzie	Pewności: wersje i komponenty są wnioskowane	CPE lub wywnioskowana nazwa
Skaner podatności hostów	Oprogramowanie zainstalowane na działających serwerach	W eksploatacji	Produktu w postaci dostarczanej klientom	CPE lub nazwa produktu dostawcy
Rejestrowanie w trakcie buildu	To, co pobrał build wydania	W trakcie buildu	Oprogramowania, którego Państwo nie zbudowali; to, czego nie mogło zobaczyć, jest oznaczane jako niekompletne	Package URL

Polityka SBOM: co ujednolicić

Należy ujednolicić SBOM, a nie skaner. Polityka ustala wynik i proces; każdy pipeline spełnia ją za pomocą najlepszego generatora, jaki może uruchomić. Każdy wiersz poniżej da się sprawdzić.

Wymaganie	Reguła	Dlaczego	Jak to sprawdzić
Zakres	Każde wydanie produktu dostarczane klientowi, łącznie z firmware'em i obrazami kontenerów. Narzędzia wewnętrzne opcjonalnie.	Klienci i regulatorzy pytają o to, co Państwo dostarczają.	Każde wydanie w rejestrze wydań ma SBOM.
Format i wersja	Jeden format podstawowy, CycloneDX lub SPDX, z wersją minimalną. Drugi akceptowany na życzenie.	Jeden format oznacza jeden parser, jeden walidator i jedno repozytorium. BSI TR-03183-2 wymaga CycloneDX 1.6 lub nowszego albo SPDX 3.0.1 lub nowszego, co jest rozsądnym minimum dla klientów z UE.	Walidacja schematu raportuje format i wersję.
Pola minimalne	Package URL dla każdego komponentu, który go ma, CPE tylko tam, gdzie go brak, dostawca, wersja, deklarowana licencja, relacje zależności, nazwa i wersja narzędzia, znacznik czasu i kontekst generowania.	Z tych pól korzystają dopasowywanie, przegląd licencji i audyty. Należy je dopasować do elementów minimalnych opisanych w czym jest SBOM.	Kontrola pól w pipelinie zlicza brakujące wartości.
Kiedy jest generowany	W buildzie CI, który tworzy wydanie, za każdym razem. Nie w chwili audytu, nie na laptopie.	Ponowny build to nie ten sam build; zob. SBOM-y z czasu buildu.	Identyfikator buildu w SBOM zgadza się z identyfikatorem buildu wydania.
Głębokość	Pełne drzewo zależności przechodnich, nie tylko najwyższy poziom.	Minimum według CRA to zależności najwyższego poziomu; podatności i klienci sięgają głębiej.	Relacje zależności istnieją poniżej pierwszego poziomu.
Gdzie jest przechowywany	Razem z artefaktem wydania, z możliwością pobrania według produktu i wersji.	SBOM, którego nikt nie może znaleźć, gdy pojawia się advisory, nie jest dowodem.	Pobranie SBOM dla losowego wydania według produktu i wersji.
Okres przechowywania	Co najmniej okres wsparcia produktu plus okres przechowywania dokumentacji wymagany przez obowiązujące Państwa przepisy.	CRA określa okres przechowywania dokumentacji technicznej, a SBOM jest jej częścią.	Porównanie okresu z polityki z okresem przechowywania w każdym narzędziu.
Walidacja	Każdy SBOM jest walidowany względem schematu w pipelinie; nieprawidłowy powoduje niepowodzenie buildu lub bramki wydania.	Nieprawidłowe SBOM-y zawodzą bez ostrzeżenia w narzędziach klienta.	Log bramki wydania pokazuje krok walidacji.
Odpowiedzialność	Za generowanie odpowiada zespół produktowy; za politykę, reguły walidacji i raportowanie pokrycia odpowiada zespół bezpieczeństwa produktu.	Generowanie wymaga właściciela pipeline'u; spójność wymaga jednego właściciela reguł.	Każdy pipeline ma wskazanego właściciela.
Wyjątki	Rejestr imiennych wyjątków ograniczonych w czasie: zespół, powód, data zakończenia.	Polityka przetrwa zespoły, które jeszcze nie mogą jej spełnić.	Żaden wyjątek nie przekroczył daty zakończenia.

Lista kontrolna w dobrych praktykach SBOM obejmuje reguły dla pojedynczego SBOM; ta polityka jest warstwą nad nimi. Każdy zespół deklaruje, jak jego pipeline spełnia politykę, w pliku obok pipeline'u:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Generowanie w buildzie, a nie przez każdy zespół po fakcie

Generowanie w trakcie buildu to standard, do którego warto dążyć. Opisuje build, który został dostarczony, obejmuje ukryte zależności, których nie wymienia żaden lockfile, a jeden mechanizm tworzy SBOM-y o tym samym kształcie dla każdego zespołu w tym pipelinie. Różnicę najłatwiej wyjaśnić na przykładzie kuchni: skaner próbuje zupy i zgaduje przepis; rejestrator obserwuje, co trafia do kuchni.

Skaner pozostaje właściwym narzędziem dla obrazów, których Państwo nie zbudowali, dla plików binarnych firm trzecich i dla starszych produktów bez CI. Należy zapisać to w polityce i rejestrować kontekst generowania, aby czytelnik wiedział, co widział każdy SBOM.

Sytuacja	Metoda generowania	Kontekst generowania do zapisania
Wydanie budowane w CI, które Państwo kontrolują	Rejestrowanie buildu lub uruchomienie generatora wewnątrz zadania wydania	"Zarejestrowany w trakcie buildu" lub "po instalacji, z plików"
Obraz kontenera budowany w CI	Rejestrowanie buildu obrazu; skanowanie wyniku pod kątem pakietów systemu operacyjnego, jeśli rejestrator ich nie obejmuje	Identyfikator buildu i digest obrazu
Obraz lub appliance firmy trzeciej	Skaner obrazów plus SBOM dostawcy, jeśli istnieje	"Wynik skanowania, nie zbudowany przez nas"
Plik binarny dostawcy	Prośba o SBOM z buildu dostawcy; analiza binarna jako kontrola	Dostawca, wersja, sposób pozyskania
Starszy produkt bez pipeline'u	Skanowanie dostarczanego artefaktu; zaplanowanie pipeline'u	"Wynik skanowania" i wyjątek z datą zakończenia

Mieszane CI: GitHub Actions, GitLab i Jenkins w jednej organizacji

Polityka z założenia nie zależy od CI: definiuje wynik, więc pipeline GitLab lub Jenkins może ją spełnić za pomocą kroku generatora, a pipeline GitHub Actions może korzystać z rejestrowania w trakcie buildu. Reguły dla kroku generatora:

• Należy uruchamiać go w zadaniu wydania, po kroku instalacji, a nie w osobnym zadaniu, które instaluje ponownie.
• Należy przypiąć wersję generatora, a akcje CI przypinać do commita, nie do tagu. Dlaczego ma to znaczenie szczególnie w przypadku skanerów, wyjaśniamy w generatorach SBOM open source.
• Należy zapisać kontekst generowania jako "po instalacji, z plików", aby czytelnicy wiedzieli, co widział.
• Należy walidować wynik względem tego samego schematu co w każdym innym pipelinie.

Generatory open source, takie jak Syft, Trivy i cdxgen, potrafią zapisywać CycloneDX i SPDX, więc reguła formatu nie wymusza wyboru narzędzia. Aby je porównać, zob. porównanie narzędzi SBOM.

CRACI obsługuje dziś GitHub Actions; GitLab CI i Jenkins są na roadmapie, bez daty. Konsekwencja dla wdrożenia: należy zacząć rejestrowanie w trakcie buildu tam, gdzie używa się GitHub Actions, gdzie indziej zachować kroki generatora i śledzić oba w tym samym raporcie pokrycia.

Gdy klient chce konkretnej wersji formatu

Klient prosi o CycloneDX 1.6, a Państwa narzędzia zapisują 1.7. Dzieje się tak, ponieważ jego narzędzie do importu lub jego własna polityka jest przypięta do wersji; minimum BSI to 1.6, więc klienci z UE często ją wskazują. Możliwości:

1. Zapytać, czy nowsza wersja jest akceptowana. Często jest.
2. Przekonwertować za pomocą CycloneDX CLI, następnie zwalidować względem wersji docelowej i sprawdzić, co zostało utracone: pola, które istnieją tylko w nowszej specyfikacji, są usuwane.
3. W przypadku prośby o SPDX to samo CLI konwertuje do i z SPDX JSON 2.3. Jego dokumentacja ostrzega, że konwersja między SPDX a CycloneDX "może skutkować utratą części informacji".

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Walidator sprawdza względem CycloneDX 1.7, chyba że przekażą Państwo --input-version. Reguła polityki: oryginalny SBOM pozostaje zapisem. Przekonwertowana kopia to dostawa pochodna; należy przechowywać z nią informację o jej pochodzeniu (narzędzie, wersja, data). Więcej o odpowiadaniu na takie prośby w prośbach klientów o SBOM, a o obu formatach w CycloneDX vs SPDX.

Dane licencyjne dla działu prawnego

Ten sam SBOM może służyć działowi prawnemu, jeśli polityka wymaga właściwych pól. Dział prawny potrzebuje licencji każdego komponentu, rozróżnienia między licencją deklarowaną (co podaje pakiet) a ustaloną (co ktoś zweryfikował), obowiązków copyleft oraz listy komponentów bez licencji. CycloneDX 1.6 oznacza licencje jako deklarowane lub ustalone, a SPDX ma osobne pola dla obu.

• Należy wymagać identyfikatorów lub wyrażeń licencji SPDX, takich jak MIT czy Apache-2.0 OR MIT.
• Należy oznaczać NOASSERTION i brakujące licencje do przeglądu. W SPDX NOASSERTION oznacza, że nie dokonano ustalenia lub nie podano informacji; to nie jest licencja.
• Licencje copyleft należy kierować do działu prawnego przed wydaniem, a nie po nim.

SBOM zawiera deklarowane licencje. Przegląd zgodności licencyjnej, z ustalonymi licencjami, informacjami o licencjach i obowiązkami, to praca prawnicza lub zadanie dla specjalistycznego narzędzia; zob. zgodność licencji open source.

Wdrażanie zespół po zespole

Faza	Właściciel	Kryterium zakończenia	Typowa przeszkoda
1. Inwentaryzacja: produkty, pipeline'y, systemy CI i obecne generatory, jeden wiersz na pipeline wydania	Bezpieczeństwo produktu	Każdy dostarczany produkt ma wiersz	Nikt nie wie, który pipeline buduje dane wydanie
2. Publikacja polityki wraz z rejestrem wyjątków	Bezpieczeństwo produktu	Polityka zatwierdzona i opublikowana	Spór o to, które narzędzie narzucić (polityka nie narzuca żadnego)
3. Pilotaż z jednym lub dwoma zespołami, które mają powód: prośbę klienta, termin, produkt, z którym obecne narzędzie sobie nie radzi	Zespoły pilotażowe	Wydania pilotażowe są dostarczane ze zgodnymi SBOM-ami	Zespoły bez pilnego powodu odkładają to na później
4. Dodanie bramek walidacji w pipeline'ach pilotażowych	Zespoły pilotażowe	Nieprawidłowy SBOM powoduje niepowodzenie wydania	Obawa przed blokowaniem wydań; zacząć od ostrzeżenia
5. Rozszerzanie według systemu CI; wycofanie skanera zespołu dopiero wtedy, gdy zamiennik spełnia politykę	Zespoły produktowe	Cel pokrycia osiągnięty dla każdego systemu CI	Pipeline'y bez właściciela
6. Comiesięczne raportowanie pokrycia	Bezpieczeństwo produktu	Raport trafia do kierownictwa co miesiąc	Wskaźniki liczone ręcznie

Arkusz inwentaryzacji z fazy 1 powinien być ostatnim arkuszem; odejście od arkuszy kalkulacyjnych opisujemy w automatyzacji SBOM. Produkt oparty na Yocto to częsty wybór na pilotaż, ponieważ skanery ogólnego przeznaczenia mają z nim trudności; zob. dlaczego skanery SBOM pomijają buildy Yocto.

Mierzenie pokrycia

Liczby, o które pytają kierownictwo i audytorzy, każda zdefiniowana jako stosunek:

• Pokrycie wydań: wydania dostarczone ze SBOM zgodnym z polityką ÷ dostarczone wydania.
• Pokrycie produktów: produkty z co najmniej jednym zgodnym SBOM w bieżącym okresie wsparcia ÷ produkty objęte wsparciem.
• Odsetek pozytywnych walidacji: SBOM-y, które przeszły walidację ÷ wygenerowane SBOM-y.
• Pokrycie identyfikatorów: komponenty z package URL (lub CPE) ÷ komponenty.
• Pokrycie licencji: komponenty z deklarowaną licencją ÷ komponenty.
• Kompletność: SBOM-y, o których generator stwierdza, że są kompletne ÷ SBOM-y. Możliwe tylko tam, gdzie narzędzie to raportuje.
• Czas do SBOM: czas od wydania do udostępnienia SBOM.

Przykładowy raport miesięczny (dane poglądowe):

Wskaźnik	Pipeline'y GitHub Actions	Pipeline'y GitLab i Jenkins	Wszystkie
Pokrycie wydań	46 / 48	19 / 27	65 / 75
Odsetek pozytywnych walidacji	100%	92%	97%
Pokrycie identyfikatorów	99%	88%	95%
Otwarte wyjątki	1	4	5

Jako dowód dla regulatora lub audytora zestaw obejmuje politykę, rejestr wyjątków, raport pokrycia i kilka przykładowych SBOM-ów. Pokazuje jeden proces, stosowany i mierzony. Informacje o CRA znajdą Państwo w przewodniku po CRA.

Gdzie pasuje CRACI

W pipeline'ach GitHub Actions CRACI jest runnerem: ustawiają Państwo runs-on: craci, a każde zadanie otrzymuje zarejestrowany SBOM bez kroku generatora. Każdy SBOM zawiera stan kompletności, zależności przechodnie, package URL dla każdego pakietu i deklarowaną licencję każdego komponentu, a eksportuje się go jako CycloneDX lub SPDX. Reguły polityki licencyjnej mogą zablokować build, monitorowane SBOM-y są stale ponownie oceniane, a historia buildów pokazuje, które buildy zawierały podatną zależność. Dzięki temu te zespoły domyślnie spełniają wiersze polityki "generowany w buildzie wydania", "identyfikator" i "licencja". Można dodawać SBOM-y firm trzecich, dzięki czemu kupowane komponenty są monitorowane razem z Państwa buildami.

Zob. generowanie SBOM w CRACI oraz SBOM-y w GitHub Actions.

Kiedy CRACI nie jest odpowiedzią

• Zespoły na GitLab CI lub Jenkins: nie dziś, jest to na roadmapie. Należy użyć kroku generatora, który spełnia politykę.
• GitHub Enterprise Server: obecnie nieobsługiwany.
• Skanowanie infrastruktury i hostów, czyli tego, co jest zainstalowane na serwerach, oraz błędnych konfiguracji: to inne zadanie; warto zachować te narzędzia.
• Analiza plików binarnych lub firmware'u w obrazach dostawców, których Państwo nie budują: CRACI rejestruje buildy i nie skanuje plików binarnych.
• Długie przechowywanie: CRACI domyślnie przechowuje dane buildów przez 180 dni, z niestandardowym okresem przechowywania w planie Enterprise. Jeśli Państwa polityka wymaga SBOM-ów przez dłuższy czas, należy eksportować je do własnego repozytorium.

Generowanie SBOM w zespołach: najczęściej zadawane pytania

Jak ujednolicić generowanie SBOM w zespołach, które używają różnych narzędzi?

Należy ujednolicić wynik, a nie narzędzie. Wystarczy napisać jedną politykę, która ustala format i wersję, pola minimalne, moment generowania SBOM, miejsce przechowywania, okres przechowywania i to, kto go waliduje. Każdy pipeline spełnia ją za pomocą najlepszego generatora, jaki może uruchomić, a pokrycie mierzy się względem polityki.

Co powinna zawierać polityka SBOM?

Zakres, format i wersję minimalną, pola minimalne (package URL, dostawca, wersja, deklarowana licencja, zależności, narzędzie, znacznik czasu, kontekst generowania), generowanie w buildzie wydania, pełną głębokość zależności przechodnich, przechowywanie razem z wydaniem, okres przechowywania, walidację w pipelinie, odpowiedzialność oraz rejestr wyjątków ograniczonych w czasie.

Czy każdy zespół powinien uruchamiać własny skaner, czy SBOM-y powinny pochodzić z buildu?

Z buildu, tam gdzie to możliwe. SBOM z czasu buildu opisuje build, który został dostarczony, i daje każdemu zespołowi w tym pipelinie SBOM-y o tym samym kształcie. Skanery warto zachować dla tego, czego Państwo nie zbudowali: obrazów firm trzecich, plików binarnych dostawców i starszych produktów bez pipeline'u.

Klient chce naszego SBOM w starszej wersji CycloneDX. Co robić?

Najpierw zapytać, czy nowsza wersja jest akceptowana. Jeśli nie, przekonwertować kopię za pomocą CycloneDX CLI (cyclonedx convert z --output-version v1_6), zwalidować ją względem tej wersji i sprawdzić, które pola zostały usunięte. Oryginał pozostaje zapisem, a przy kopii należy przechować informację, jak powstała.

Jak przekazać dane licencyjne z naszych SBOM-ów do działu prawnego?

Należy wymagać w polityce identyfikatorów lub wyrażeń licencji SPDX, oznaczać NOASSERTION i brakujące licencje do przeglądu, a licencje copyleft kierować do działu prawnego przed wydaniem. SBOM zawiera deklarowane licencje; ustalone licencje, informacje o licencjach i obowiązki wymagają przeglądu licencji.

Jak mierzyć pokrycie SBOM w różnych produktach?

Jako stosunki: wydania dostarczone ze zgodnym SBOM, produkty objęte wsparciem ze zgodnym SBOM, odsetek pozytywnych walidacji, komponenty z package URL, komponenty z deklarowaną licencją, kompletne SBOM-y tam, gdzie narzędzie to raportuje, oraz czas od wydania do SBOM. Raportować je co miesiąc według systemu CI.

Jakie dowody są potrzebne, aby pokazać audytorowi, że generowanie SBOM jest spójne?

Polityka, rejestr wyjątków, miesięczny raport pokrycia i kilka przykładowych SBOM-ów z ich kontekstem generowania. Razem pokazują jeden proces, stosowany przy każdym wydaniu i mierzony, a to właśnie sprawdza audytor lub klient.