Czego nie widzą generatory SBOM open source

Jak wygenerować SBOM każdym z narzędzi

W każdym narzędziu to jedno polecenie dla katalogu źródłowego lub obrazu kontenera, z wynikiem w CycloneDX lub SPDX:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

Polecenia to łatwa część. To, co trafi do pliku, zależy od tego, co odczytuje dane narzędzie, a nie odczytują one tego samego.

Co odczytuje każde narzędzie

Narzędzie	Katalog źródłowy	Obraz kontenera	Warto wiedzieć
Syft	Domyślny zestaw katalogerów dla katalogów, który odczytuje zadeklarowane zależności	Domyślny zestaw katalogerów dla obrazów, który odczytuje zainstalowane pakiety	Katalogery dobierane są według typu skanu. syft cataloger list pokazuje, które działają, a --select-catalogers je dodaje lub usuwa.
Trivy	Lockfile, dla Node.js package-lock.json, yarn.lock, pnpm-lock.yaml i bun.lock	Dla Node.js pliki package.json w node_modules	Pomija zależności deweloperskie, chyba że poda się --include-dev-deps.
cdxgen	Najpierw lockfile, które obejmują zależności deweloperskie; dla Node.js analizuje też importy w kodzie	Obsługiwane	Typ projektu ustawia się przez -t, aby ograniczyć zakres szukania.

Dlaczego różnią się na tym samym repozytorium

Uruchomione na jednym commicie dadzą trzy różne listy. Żadne nie jest zepsute. Każde działa według własnych udokumentowanych reguł:

• Brak lockfile, brak zależności. Express 5.2.1 nie commituje lockfile. Na czystym checkoucie narzędzie rozwiązujące zależności z lockfile lub zainstalowanych pakietów nie ma ani jednego, ani drugiego, więc zależności npm zadeklarowane w package.json nigdy nie trafiają do SBOM. Mimo to zapisuje poprawny dokument z tym, co jeszcze rozpoznało.
• Zainstalowane czy zadeklarowane. To, czy przed skanem wykonano instalację, może mieć większe znaczenie niż wybór narzędzia. Na zainstalowanej kopii tego samego repozytorium jedno ustawienie katalogera Syft decyduje, czy zainstalowane pakiety npm w ogóle się pojawią.
• Zależności deweloperskie. Trivy domyślnie je pomija, a cdxgen uwzględnia, więc ten sam lockfile daje dwie odpowiedzi na pytanie „co jest w tym projekcie”.
• Nazwy i wersje. Narzędzia identyfikują niektóre komponenty pod różnymi typami package URL albo przypinają GitHub Action do SHA commita tam, gdzie inne narzędzie podaje tag. Wyszukiwanie podatności po złym identyfikatorze daje błędną, choć pewnie brzmiącą odpowiedź.
• Brak jakiegokolwiek manifestu. Repozytorium anthropics/claude-code nie ma manifestu zależności, a jego pakiet npm opakowuje gotowy plik binarny. To, co zwraca każde narzędzie, mówi więcej o narzędziu niż o projekcie.

Co pomijają wszystkie: ukryte zależności

Głębsze ograniczenie jest wspólne. Skaner odczytuje lockfile lub wynik buildu i na tej podstawie, po fakcie, ustala, co do niego trafiło. Wszystko, co build pobrał poza tymi plikami, nigdy nie trafia do SBOM. To właśnie ukryte zależności:

• Hooki instalacyjne. Skrypty npm preinstall i postinstall działają podczas instalacji i mogą pobierać dodatkowy kod. W ten sposób działał robak Shai-Hulud.
• Skrypty buildu, takie jak skrypty buildu w Rust, które pobierają to, czego potrzebują, w czasie buildu.
• Obrazy bazowe i ich warstwy systemu operacyjnego w buildzie kontenera, których nie wymienia żaden lockfile języka.
• Pakiety przywrócone z cache CI, które mogą nie odpowiadać bieżącemu lockfile. Zob. co ukrywa cache GitHub Actions.
• Narzędzia buildu instalowane przez kroki konfiguracyjne, z własnymi drzewami zależności.
• Wersje przechodnie rozwiązywane w czasie buildu, gdy lockfile nie ma, jest nieaktualny lub nie jest używany przez instalację w trybie frozen. Zob. zależności przechodnie.

Późniejsze skanowanie wyniku nie zamyka tej luki. Gotowy plik binarny, zwłaszcza kod kompilowany, taki jak Rust, zmusza skaner do zgadywania, co do niego trafiło. Komercyjne skanery SCA pracują na tych samych rodzajach plików i mają te same słabe punkty. CRACI znalazł podatne pakiety, których Snyk i Aikido nie zgłosiły, ponieważ w ich skanach brakowało tych komponentów.

Narzędzia też są częścią Państwa łańcucha dostaw

Skaner działa w Państwa CI z dostępem do kodu, a często też sekretów. W marcu 2026 biuletyn Aqua Security (CVE-2026-33634) opisał złośliwe wydanie Trivy v0.69.4 oraz zatrute tagi trivy-action i setup-trivy, które kradły poświadczenia z runnerów CI. Akcje skanerów należy przypinać do pełnych SHA commitów, a używane wersje sprawdzić w biuletynie.

Jak sprawdzić własny SBOM

1. Uruchomić dwa generatory na tym samym commicie i porównać zgłoszone package URL.
2. Sprawdzić, czy repozytorium commituje lockfile i czy CI instaluje z niego w trybie frozen.
3. Skanować zarówno po kroku instalacji, jak i przed nim, i porównać wyniki.
4. Porównać listę z tym, co pokazuje log buildu jako pobrane, łącznie z krokami konfiguracyjnymi i przywróceniami cache.

Jeśli listy się różnią, publikowany SBOM zależy od tego, jakie narzędzie akurat uruchomiono, a nie od tego, co Państwo dostarczyli.

Zamiast tego rejestrować build

CRACI widzi ruch; skanery nie. To runner GitHub Actions, który widzi ruch sieciowy wchodzący do każdego buildu, więc jego SBOM rejestruje każdy pakiet pobrany przez zadanie, na każdym poziomie drzewa, łącznie z ukrytymi zależnościami i pakietami przywróconymi z cache CI. Nie ma katalogu do wskazania ani katalogera do wyboru. Gdy rejestracja nie mogła zobaczyć wszystkiego, na przykład dlatego, że zadanie dopuściło niemonitorowany ruch, SBOM informuje o tym swoim stanem kompletności.

Rejestrowanie ma znaczenie także dlatego, że buildy rzadko są odtwarzalne. Gdy ten sam commit zbuduje się dwa razy z rzędu, menedżer pakietów może rozwiązać i zainstalować pakiety w innej kolejności, więc drugi build może zawierać inne pakiety. Tylko SBOM zarejestrowany podczas buildu, który wytworzył wydanie, dowodzi, co to wydanie zawiera.

Syft lub Trivy warto zachować dla obrazów i plików binarnych, których nie budują Państwo sami. W przypadku własnych wydań zob. SBOM-y z czasu buildu lub proszę umówić demo, aby porównać zarejestrowany SBOM z wynikiem obecnego narzędzia na jednym z Państwa repozytoriów.

Generatory SBOM open source: najczęściej zadawane pytania

Co jest lepsze do SBOM: Syft czy Trivy?

Służą do różnych zadań. Syft to wyspecjalizowany generator SBOM z wieloma katalogerami i podpisanymi poświadczeniami; Trivy to skaner bezpieczeństwa, który zapisuje SBOM-y jako jeden ze swoich wyników. Oba odczytują pliki, które mają przed sobą, więc na tym samym repozytorium większą różnicę zwykle robi to, czy lockfile jest commitowany i czy zależności zainstalowano przed skanem.

Dlaczego mój SBOM nie pokazuje żadnych zależności?

Najczęściej dlatego, że repozytorium nie commituje lockfile, a przed skanem niczego nie zainstalowano. Generator odczytujący lockfile lub zainstalowane pakiety nie ma wtedy czego czytać, a mimo to zapisuje poprawny SBOM. Należy commitować lockfile lub skanować po kroku instalacji.

Czy Trivy uwzględnia w SBOM zależności deweloperskie?

Domyślnie nie. Dokumentacja Trivy dla Node.js podaje, że nie zgłasza zależności deweloperskich, chyba że poda się --include-dev-deps. cdxgen natomiast analizuje lockfile i uwzględnia zależności deweloperskie. Już z tego powodu dwa narzędzia mogą się różnić na tym samym projekcie.

Czy można ufać SBOM z generatora open source?

W zakresie tego, co odczytał, tak. Pytanie brzmi, czego nie odczytał: cache, narzędzi buildu, pobrań, skryptów instalacyjnych i plików binarnych bez metadanych pakietów. SBOM ze skanu należy traktować jako opis plików wskazanych narzędziu, a nie buildu, który wytworzył Państwa wydanie.

Jakie narzędzie SBOM jest najlepsze?

W przypadku oprogramowania budowanego samodzielnie najpełniejszy SBOM daje rejestrowanie buildu, a nie skanowanie plików. CRACI rejestruje każdy pakiet pobrany przez każde zadanie GitHub Actions, także z cache, i znalazł podatne pakiety, których Snyk i Aikido nie zgłosiły. Dla obrazów i plików binarnych, których nie budują Państwo sami, praktycznym wyborem pozostaje skaner, taki jak Syft lub Trivy.