SPDX i CycloneDX: wybór formatu SBOM
Sytance · Zaktualizowano
Zarówno SPDX, jak i CycloneDX opisują komponenty oprogramowania i ich relacje. Wybór zależy od informacji potrzebnych odbiorcy oraz wersji obsługiwanych przez jego narzędzia. Uzgodnienie formatu obejmuje zatem także uzgodnienie jego wersji, kodowania i wymaganych pól.
Potrzeby informacyjne odbiorcy
Dostawca oprogramowania układowego przekazujący SBOM producentowi może podlegać innym wymaganiom niż zespół wczytujący go do usługi zarządzania podatnościami. Obsługiwane przez odbiorcę wersje i kodowania określają, które pliki może on przetwarzać. Reprezentatywny plik pomaga potwierdzić tę obsługę.
Należy zapisać wymagane informacje, w tym tożsamość produktu, identyfikatory komponentów, relacje, licencje oraz wszelkie dane o podatnościach lub pochodzeniu. Jeśli odbiorca obsługuje tylko część formatu, należy ustalić, czy pominięte pola wpływają na cel wymiany.
Wersje specyfikacji i obsługa przez narzędzia
SPDX 2.3 i SPDX 3.0.1 to odrębne opublikowane specyfikacje. SPDX 3.0.1 wykorzystuje model oparty na profilach, w tym klasę SBOM oprogramowania. Nie należy zakładać, że odbiorca akceptujący SPDX 2.3 JSON przyjmie również dokument w wersji 3.x.
Przegląd specyfikacji CycloneDX wymienia wersję 1.7. Jej model obiektowy obejmuje komponenty, usługi, relacje zależności i informacje o podatnościach. Producent może obsługiwać najnowszą specyfikację, podczas gdy importer w dalszym procesie obsługuje starszą wersję.
| Szczegóły wymiany | Przykład SPDX | Przykład CycloneDX |
|---|---|---|
| Wersja | 2.3 lub 3.0.1 | 1.7 |
| Tożsamość dokumentu | Model dokumentu właściwy dla wersji | Numer seryjny i wersja BOM |
| Zależności | Relacje określone typami | Graf zależności |
| Walidacja | Reguły dla wybranej wersji | Schemat dla wybranej wersji |
Relacje i pola licencji
W SPDX 2.3 relacja CONTAINS opisuje zawieranie, a DEPENDS_ON — zależność. Umieszczenie pakietu w archiwum różni się od sytuacji, w której inny pakiet potrzebuje go do kompilacji lub działania. Podczas importu należy zachować typ i kierunek relacji.
SPDX 2.3 rozróżnia także licencję zadeklarowaną i ustaloną. Deklaracja dostawcy i wniosek analityka nie powinny bez wyraźnego powodu trafiać do tego samego pola. Jeśli rozróżnienie ma znaczenie dla przeglądu, narzędzie odbierające musi je zachować.
W przypadku CycloneDX należy sprawdzić graf zależności i odwołania do komponentów w wybranej wersji. Po konwersji płaska lista komponentów może pozostać czytelna, ale utracić ścieżki niezbędne do ustalenia, które produkty korzystają z danego komponentu.
Kontrola informacji po konwersji
Niewielki plik testowy może ujawnić utratę informacji podczas konwersji. Powinien zawierać produkt, zależność bezpośrednią i pośrednią. Dwie wersje tego samego komponentu, wyrażenie licencji i pole wyraźnie oznaczone jako nieznane pozwalają sprawdzić więcej niż samo przyjęcie pliku.
- Zweryfikować plik źródłowy względem zadeklarowanej wersji specyfikacji.
- Zaimportować go do narzędzia odbierającego i sprawdzić produkt docelowy.
- Porównać tożsamość i wersje komponentów oraz kierunek relacji.
- Sprawdzić pola licencji i sposób reprezentowania nieznanych informacji.
- Jeśli to możliwe, ponownie wyeksportować plik i porównać znaczenie, a nie formatowanie.
Wybór formatu do dostarczenia
Jeśli klient wymaga SPDX 2.3, należy dostarczyć tę wersję z uzgodnionymi polami i zachować bogatszy zapis źródłowy, jeśli konwersja usuwa inne dane. Jeśli proces odbiorcy już przetwarza CycloneDX i zachowuje potrzebny graf, należy użyć obsługiwanej wersji CycloneDX.
Jeśli klienci potrzebują obu formatów, należy utrzymywać i testować mapowania pól między nimi. Udokumentować informacje tracone lub przenoszone do rozszerzeń podczas konwersji. Konwersja musi przekształcać dane zgodnie ze specyfikacją docelową.
Po imporcie należy sprawdzić, czy odbiorca nadal może używać informacji zgodnie z przeznaczeniem. W analizie podatności obejmuje to możliwość rozpoczęcia od komponentu i ustalenia, które produkty i wydania z niego korzystają.