Kompletność SBOM

SBOM jest kompletny, gdy wymienia każdy komponent, który trafił do opisywanego oprogramowania, na każdym poziomie drzewa zależności, łącznie z komponentami, których nie wymienia żaden lockfile ani manifest. Kompletność SBOM to właśnie ta cecha. 2026 Minimum Elements CISA proszą autorów SBOM o wyraźne zaznaczanie, kiedy informacja jest nieznana, i zauważają, że odbiorcy mogą uznać SBOM za niekompletny, jeśli zatajono istotne dane o komponentach.

Kompletność, poprawność i jakość to różne rzeczy

Pytanie	Co to oznacza	Co to sprawdza	Czego nie powie
Poprawny	Plik jest zgodny ze schematem CycloneDX lub SPDX	Walidator schematu	Czy brakuje komponentów
Jakość pól	Każdy komponent ma nazwę, wersję, dostawcę, identyfikator, licencję i skrót	Narzędzie do oceny jakości	Czy brakuje komponentów
Kompletny	Nie brakuje niczego, co trafiło do oprogramowania	Porównanie z tym, co build faktycznie pobrał	Wejść, których porównanie nie objęło

Identyfikator z drugiego wiersza to zwykle package URL lub CPE. Plik może bez zarzutu przejść dwie pierwsze kontrole, a mimo to pominąć połowę oprogramowania.

Dlaczego kompletność trudno zmierzyć po fakcie

Skaner pracuje na lockfile'ach, manifestach lub gotowym wyniku. Nie może wiedzieć o pakiecie pobranym przez skrypt post-install, o crate'cie wkompilowanym w plik binarny ani o warstwie obrazu bazowego, której nigdy mu nie pokazano. Każde z nich to ukryta zależność.

Weźmy usługę Node.js, której lockfile wymienia 400 pakietów. Jeden z nich ma skrypt postinstall, który podczas npm ci pobiera gotowy plik binarny. SBOM wygenerowany z package-lock.json jest poprawny, każdy komponent ma wersję i package URL, a pliku binarnego w nim nie ma. Żadna ocena jakości tego nie wykaże, bo nic w pliku nie wskazuje na to, czego brakuje.

Ponowne zbudowanie później też nie rozstrzyga sprawy: jeśli build nie jest odtwarzalnym buildem, drugi build może pobrać coś innego niż pierwszy.

Jak rzetelnie podawać kompletność

• Podawać kontekst wygenerowania: czy SBOM powstał z kodu źródłowego przed buildem, został zarejestrowany w trakcie buildu, czy powstał przez analizę wyniku po fakcie.
• Wymieniać znane luki: części oprogramowania, których narzędzie nie widziało, np. kod dołączony do repozytorium, gotowe pliki binarne lub komponenty zainstalowane poza menedżerem pakietów.
• Wybierać stan z uzasadnieniem zamiast oceny. Odsetek kompletności wymaga sumy, a tej sumy nikt nie zna. Informacja w rodzaju „niekompletny: zadanie dopuściło niemonitorowany ruch” pozwala działać.

Dobre praktyki SBOM omawiają szerzej praktykę informowania o tym, czego SBOM nie mógł zobaczyć.

Stany kompletności w CRACI

CRACI nadaje SBOM każdego zadania stan kompletności, a swój stan otrzymują też cache. Stany według dokumentacji CRACI:

• Complete: „CRACI zaobserwował kompletne dane dla zadania, a każdy przywrócony cache był kompletny”.
• Complete with connections: „Wymagania zostały spełnione, ale zadanie użyło co najmniej jednego niestandardowego połączenia sieciowego”.
• Incomplete: „CRACI wykrył warunek, przez który zależności mogą nie trafić do SBOM”.
• Unavailable: „CRACI nie mógł dokończyć oceny danych”.
• Not recorded: „Zadanie powstało, zanim wprowadzono raportowanie kompletności”.

CRACI może to stwierdzić, ponieważ widzi ruch każdego zadania do źródeł pakietów i wie, kiedy coś mogło go ominąć: ruch, którego nie monitorował, albo przywrócony cache, którego własny SBOM był niekompletny. Gdy zadanie jest niekompletne, pokazuje przyczynę, np. „Unmonitored traffic was allowed”. Zob. generowanie SBOM.

Te stany dotyczą buildów uruchamianych na runnerach CRACI. W przypadku SBOM od dostawcy lub z pipeline'u, który nie działa na CRACI, należy stosować opisane wyżej porównania i zasady.