Prośby klientów o SBOM: jak na nie odpowiadać

Dostarczają Państwo komponenty lub oprogramowanie wbudowane producentom? Zob. przewodnik SBOM dla dostawców, który omawia umowy, VEX i SBOM dla każdej dostarczanej wersji oprogramowania.

Dlaczego klienci pytają właśnie teraz

• Cyber Resilience Act. Producenci sprzedający w UE potrzebują SBOM własnego produktu i muszą zachować należytą staranność wobec wykorzystywanych komponentów, więc pytanie przechodzi dalej w dół łańcucha dostaw.
• NIS2. Podmioty kluczowe i ważne muszą zająć się bezpieczeństwem łańcucha dostaw. Dyrektywa nie wymienia SBOM, ale SBOM jest jednym ze sposobów, w jaki kupujący może zobaczyć, co dostarcza dostawca. Zob. SBOM jako dowód dla NIS2, ISO 27001 i SOC 2.
• Przepisy sektorowe. Sekcja 524B FDA wymaga SBOM dla cyberurządzeń, a inne sektory mają własne przepisy.
• Ich własna praca nad podatnościami. Klient, który wie, co jest w Państwa produkcie, może ustalić, czy nowa CVE go dotyczy, bez otwierania zgłoszenia do wsparcia.

Co uzgodnić, zanim cokolwiek Państwo wyślą

Pytanie	Dlaczego to ważne
Który produkt i która wersja?	SBOM opisuje jedno wydanie. Należy wysłać to, którego używa klient, a nie najnowszy build.
Jaki format?	Większość próśb dopuszcza CycloneDX lub SPDX. Warto zapytać, czy potrzebna jest konkretna wersja.
Jak głęboko?	Zależności najwyższego poziomu mogą nie wystarczyć. Należy spodziewać się pytania o przechodnie.
Raz czy z każdym wydaniem?	Umowa może przewidywać nowy SBOM dla każdego wydania, co wyklucza wszystko, co robione jest ręcznie.
Na jakich warunkach?	SBOM pokazuje, jak zbudowany jest Państwa produkt. Należy uzgodnić warunki poufności i sposób przekazania pliku.

Co zawiera dobra odpowiedź

• SBOM w uzgodnionym formacie dla dokładnie tego wydania, którego używa klient.
• Każdy komponent z nazwą, wersją, dostawcą, licencją i identyfikatorem pakietu.
• Relacje między zależnościami, aby pakiet przechodni można było powiązać z tym, co go pobrało.
• Datę, narzędzie, które go wytworzyło, oraz build, z którego pochodzi.
• Szczerą informację o wszystkim, czego SBOM nie obejmuje (zob. kompletność SBOM).

Jak wyglądają takie pliki, pokazują przykłady SBOM. O obu formatach piszemy w tekście CycloneDX vs SPDX. Co klient prawdopodobnie sprawdzi po otrzymaniu pliku, opisuje lista kontrolna jakości SBOM.

Błędy, które wracają później

• Wysłanie najnowszego buildu zamiast dostarczonego. Buildy nie są domyślnie powtarzalne, więc ponowne zbudowanie tego samego commita nie gwarantuje tego samego SBOM. Tylko SBOM z buildu, który wytworzył wydanie, pokazuje, co otrzymał klient.
• Ręczne składanie SBOM na tę okazję. Spełnia prośbę jednorazowo, a dla kolejnego klienta i kolejnego wydania trzeba to powtórzyć. Zob. automatyzacja SBOM.
• Obiecywanie więcej, niż można powtarzać. „Będziemy wysyłać SBOM z każdym wydaniem” łatwo wpisać do umowy, ale bez automatyzacji trudno tego dotrzymać.
• Traktowanie SBOM jako końca sprawy. Kolejne pytanie brzmi: „czy dotyczy Państwa ta CVE?”, a przychodzi wraz z następną dużą podatnością.

Jak przygotować się na kolejną prośbę

Prośby stają się proste, gdy SBOM już istnieje. Należy wytwarzać go dla każdego wydania w pipeline, który je buduje, przechowywać razem z wydaniem i monitorować pod kątem nowych podatności. Wtedy odpowiedź na prośbę to pobranie pliku i krótka notatka, a na kolejne pytanie można odpowiedzieć na podstawie tego samego zapisu.

Jak robi to CRACI

CRACI rejestruje SBOM z każdego buildu GitHub Actions uruchamianego na jego runnerach, więc każde wydanie ma już swój SBOM, gdy ktoś o niego poprosi.

• Eksport w formacie CycloneDX lub SPDX, łącznie z zależnościami przechodnimi i podatnościami znalezionymi w komponentach.
• Dowody z samego buildu. Każdy komponent w SBOM rzeczywiście był w buildzie, a ukryte zależności, które pomijają narzędzia oparte na lockfile, są rejestrowane.
• Stan kompletności dla każdego zadania, dzięki czemu wiedzą Państwo, co wysyłają, zanim to wyślą.
• Historia buildów. W ramach okresu przechowywania widać wcześniejsze buildy i ich SBOM-y oraz to, które buildy zawierały podatną zależność.
• Odpowiedzi na kolejne pytania. CRACI na bieżąco ponownie ocenia monitorowane SBOM-y, obsługuje VEX i pokazuje w widoku inwentarza, które produkty używają których wersji.

Prośby klientów o SBOM: najczęściej zadawane pytania

Czy mamy obowiązek przekazywać klientom nasz SBOM?

To zależy od rynku i umów. Cyber Resilience Act czyni SBOM częścią dokumentacji technicznej, która na żądanie trafia do organu nadzoru rynku, i nie wymaga jego publikowania. Prawo klienta do SBOM wynika zwykle z umowy, dlatego warto sprawdzić, co Państwo uzgodnili.

Jaki format SBOM należy wysłać?

CycloneDX lub SPDX, zależnie od tego, o który prosi klient. Jeśli nie ma preferencji, oba się sprawdzą. Warto zapytać, czy jego narzędzia wymagają konkretnej wersji.

Czy trzeba uwzględniać zależności przechodnie?

Cyber Resilience Act wymaga co najmniej zależności najwyższego poziomu, ale wielu kupujących oczekuje pełnego drzewa, a podatności często kryją się w pakietach przechodnich. Pełny SBOM to bezpieczniejsza odpowiedź.

Czy SBOM powinien trafić do klienta na podstawie NDA?

To decyzja Państwa i klienta. SBOM pokazuje, z czego składa się Państwa produkt, dlatego wielu dostawców udostępnia go na podstawie obowiązującej umowy lub NDA zamiast go publikować.

Jak często należy wysyłać zaktualizowany SBOM?

Tak często, jak Państwo uzgodnią. Zależności zmieniają się z każdym wydaniem, więc uczciwym domyślnym wyborem jest nowy SBOM na wydanie, a to jest wykonalne tylko wtedy, gdy SBOM powstaje w buildzie.

Co, jeśli klient pyta o starsze wydanie?

Potrzebny jest SBOM z buildu, który wytworzył to wydanie. CRACI przechowuje historię buildów w ramach okresu przechowywania, domyślnie 180 dni, z niestandardowym okresem w planie Enterprise, dlatego wszystko, co ma być przechowywane dłużej, należy wyeksportować.

Nigdy nie tworzyliśmy SBOM. Od czego zacząć?

Od wydania, którego używa klient, i narzędzia, które pracuje na Państwa rzeczywistym buildzie. Jeśli korzystają Państwo z GitHub Actions, przeniesienie buildu na runnery CRACI daje zarejestrowany SBOM od pierwszego uruchomienia.