Utrzymanie SBOM w kolejnych wydaniach produktu
Sytance · Zaktualizowano
SBOM musi pozostać powiązany z wydaniem oprogramowania, które opisuje. Aktualizacja oprogramowania może zmienić komponenty, podczas gdy korekta SBOM może jedynie poprawić informacje o niezmienionym wydaniu. Rejestrowanie obu wersji umożliwia ustalenie, co otrzymali klienci i który wykaz dokładnie to opisuje.
Oprogramowanie opisane w każdym wykazie
Należy wybrać powtarzalny etap procesu kompilacji lub wydania, na którym będzie generowany SBOM. Zachować rewizję źródła, rozwiązane zależności, konfigurację kompilacji i tożsamość końcowego artefaktu potrzebne do odtworzenia wykazu lub zbadania jego zawartości.
Przewodnik CycloneDX rozróżnia wykazy generowane na podstawie kodu źródłowego, podczas kompilacji i podczas działania. Na tych etapach może znajdować się inne oprogramowanie. Wskazanie etapu pozwala odbiorcy ustalić, czy SBOM opisuje zadeklarowane zależności, wynik kompilacji czy wdrożone oprogramowanie.
W przypadku bramy należy połączyć informacje z kompilacji aplikacji, obrazu bazowego i dostarczonych komponentów oprogramowania układowego. Zachować powiązanie z SBOM każdego dostawcy. Usługa chmurowa używana przez bramę może wymagać osobnego wykazu i własnego cyklu wydawniczego.
Zmiany komponentów między wydaniami
Porównanie wydań pokazuje komponenty dodane, usunięte, zaktualizowane lub ponownie skompilowane, wraz ze zmianami ścieżek zależności. Sama liczba komponentów może przeoczyć zastąpienie: jedną bibliotekę można usunąć, a inną dodać bez zmiany łącznej liczby.
Do porównania należy używać znormalizowanych tożsamości, zachowując jednocześnie oryginalne wersje i identyfikatory. Jeśli narzędzie zaczyna rozpoznawać wcześniej nieznane pakiety, należy odróżnić poprawę widoczności od rzeczywistej zmiany oprogramowania.
- Dodane lub usunięte komponenty i ich nadrzędne ścieżki zależności.
- Zmiany wersji, poprawki dalszych poziomów i zmienione skróty artefaktów.
- Zmiany w deklaracjach licencji lub producentach komponentów.
- Nowe braki, poprawione identyfikatory i rewizje SBOM dostawców.
Kontrole przed wydaniem
Należy zweryfikować plik względem wersji formatu, a następnie sprawdzić jego znaczenie. Potwierdzić, że wszystkie odwołania są rozstrzygane, produkt główny jest zamierzonym wydaniem, a odbiorca może uzyskać dostęp do powiązanych SBOM komponentów.
Uruchomić kontrole podatności i licencji dla kandydującego wydania oraz zapisać wyniki dla tego wydania. Nowo wprowadzony problem o wysokim priorytecie wymaga decyzji dotyczącej postępowania. Dawny wyjątek należy ponownie rozpatrzyć, jeśli zmieniła się wersja komponentu lub założenia operacyjne.
Zarchiwizować zaakceptowany artefakt, SBOM, odniesienia do kompilacji i wynik przeglądu razem. Jeśli używane jest podpisywanie, zweryfikować podpis i potwierdzić, że należy do oczekiwanego wystawcy.
Korekty istniejącego SBOM
Wspólne wytyczne dotyczące SBOM z 2026 r. wymagają SBOM dla każdej wersji oprogramowania lub aktualizacji oraz zrewidowanego SBOM po skorygowaniu błędów lub poznaniu szczegółów nowych komponentów. Rozróżniają także informacje nieznane od informacji celowo nieujawnionych.
Na przykład dostawca koryguje producenta komponentu, ale bajty oprogramowania układowego pozostają bez zmian. Należy zachować tożsamość oprogramowania układowego, wydać nową rewizję SBOM, wyjaśnić korektę i zachować poprzedni dokument. Dzięki temu odbiorcy mogą odróżnić korektę danych od aktualizacji oprogramowania.
Opublikować aktualizację w uzgodnionym kanale dystrybucji. Stabilna strona docelowa może wskazywać bieżącą rewizję, a niezmienne pliki mogą zachować historię. Potwierdzić, że odbiorcy mogą ustalić, która rewizja zastępuje wcześniejszą.
Nowe podatności we wspieranych wydaniach
Po otrzymaniu komunikatu należy wyszukać tożsamości komponentów we wszystkich wspieranych wydaniach. Przed przypisaniem wpływu należy sprawdzić rzeczywiste kompilacje i sposób użytkowania produktu. Wykaz komponentów należy oddzielić od oceny podatności, aby można było ponownie ocenić ten sam SBOM po uzyskaniu nowych informacji.
Jeśli wydanie bramy 1.0 zawiera podatną bibliotekę, a wydanie 1.1 już jej nie zawiera, nowe wydanie nie zmienia składu urządzeń z zainstalowaną wersją 1.0. Zespół nadal musi zareagować w odniesieniu do tych urządzeń i zachować dokładny zapis wersji objętych komunikatem o podatności lub oświadczeniem VEX.
Należy uzgodnić, kto utrzymuje aktualizacje od dostawców, kto ocenia wpływ, kto zatwierdza reakcję i kto ją komunikuje. Określić terminy przeglądów zgodnie z obowiązkami wsparcia produktu i wagą nowych informacji, a nie polegać wyłącznie na kolejnym zaplanowanym wydaniu.
Przechowywanie zapisów i przekazanie obowiązków
Po zakończeniu wsparcia należy zachować powiązanie wydań z SBOM oraz decyzje potrzebne do wyjaśnienia historycznych dostaw. Ograniczyć dostęp do wrażliwych zapisów w odpowiednim zakresie, a jednocześnie umożliwić uprawnionym odbiorcom uzyskanie obiecanych im informacji.
Nowy podmiot przejmujący utrzymanie musi znaleźć wykaz dla konkretnej wersji produktu, zlokalizować komponent i odczytać najnowszą ocenę wpływu. Przejście przez jedno wspierane wydanie pomaga zidentyfikować brakujące zapisy lub uprawnienia dostępu.