Skanują już Państwo zależności. Oto, czego skaner nie widzi.

Co obecny zestaw robi dobrze

Jeśli mają Państwo skonfigurowane SCA i generowanie SBOM, trudna praca organizacyjna jest już wykonana: zależności są śledzone, biuletyny docierają do programistów, a gdy ktoś poprosi, jest plik do przekazania. Warto to zachować.

• Graf zależności GitHub i Dependabot są w wielu zespołach włączone domyślnie. GitHub opisuje graf zależności jako podsumowanie plików manifestów i lockfile przechowywanych w repozytorium oraz wszelkich zależności przesłanych dla repozytorium przez dependency submission API. Alerty Dependabot opierają się na nim i powiadamiają Państwa, gdy zostanie opublikowany nowy biuletyn lub gdy zmieni się graf zależności.
• Komercyjne SCA, takie jak Snyk, także generuje SBOM-y. Polecenie snyk sbom odczytuje pliki manifestów i ich lockfile, a następnie zapisuje CycloneDX lub SPDX. Według stanu na wrzesień 2026 dokumentacja Snyk podaje, że jest ono dostępne tylko dla klientów planów Snyk Enterprise.
• Generatory open source, takie jak Syft, Trivy i cdxgen, są bezpłatne, szybkie i łatwe do dodania do CI. Syft opisuje siebie jako narzędzie do generowania Software Bill of Materials (SBOM) z obrazów kontenerów i systemów plików.

Najmocniejsze strony tych narzędzi to szybka informacja zwrotna w pull requeście, szerokie pokrycie ekosystemów i proces naprawy, który programiści już znają. CRACI dziś tego nie zastępuje. Śledzenie podatności w CRACI agreguje znaleziska z buildów i repozytoriów oraz ponownie ocenia monitorowane SBOM-y, gdy pojawiają się nowe podatności. Zespoły bezpieczeństwa mogą wykonywać triage znalezisk i przekazywać je właściwemu zespołowi. Bramki polityk mogą zablokować build; webhooki podatności są w planach rozwoju.

Skaner a rejestrator

Każde z powyższych narzędzi jest skanerem. Wskazują mu Państwo drzewo źródeł, lockfile lub obraz kontenera, a ono wnioskuje, co się tam znalazło. To działa, gdy pliki mówią wszystko. Trudniej, gdy tak nie jest:

• Repozytorium nie ma lockfile, więc o wersjach decyduje moment instalacji.
• Build przywraca pakiety z cache CI, którego nie wymienia żaden manifest.
• Krok buildu pobiera bezpośrednio narzędzie, pakiet systemowy lub plik binarny.
• Hook instalacji npm lub skrypt buildu Rust pobiera dodatkowy kod podczas instalacji. Tą drogą poszedł robak Shai-Hulud.
• Build kontenera pobiera obraz bazowy i jego warstwy systemu operacyjnego, których nie wymienia żaden lockfile języka.
• Dostarczanym produktem jest skompilowany plik binarny, a manifest obok niego nie wymienia prawie niczego.

CRACI jest rejestratorem: widzi ruch, a skanery nie. Uruchamia build na własnym runnerze zgodnym z GitHub Actions, a proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów w czasie działania zadania, więc te ukryte zależności trafiają do SBOM. Pakiety przywrócone z cache przenoszą swoje dowody dalej. Nie ma polecenia craci scan ./dir, ponieważ skanowanie katalogu po fakcie to właśnie ten krok, którego CRACI ma unikać.

Od czego zależy skan

Wynik skanera zależy od narzędzia i od tego, na co je skierowano. Syft, Trivy, cdxgen, Microsoft SBOM Tool, eksport grafu zależności GitHub i Socket CLI ustalają listę na podstawie tego, co potrafią odczytać. Poniższe wzorce wynikają z udokumentowanego sposobu działania tych narzędzi.

Żadnego komponentu nie znajduje każde narzędzie

Każdy generator sam decyduje, co uznać za komponent i którym plikom ufać, więc to samo repozytorium daje każdemu z nich inną listę. Eksport grafu zależności GitHub działa jeszcze inaczej: powstaje z tego, co GitHub wie o repozytorium, a nie z plików odczytywanych przez skaner, i odczytuje domyślną gałąź, a nie przypięty commit.

Brak lockfile, brak zależności

Express 5.2.1 nie zawiera w repozytorium lockfile. Generator, który rozwiązuje zależności z lockfile lub zainstalowanego drzewa, skierowany na czyste repozytorium nie ma żadnego z nich, więc żadna z zależności npm zadeklarowanych w package.json nie trafia do dokumentu. Żadne z tych narzędzi nie jest zepsute. O tym, czy SBOM w ogóle zawiera jakiekolwiek zależności, nie decyduje narzędzie. Decyduje to, czy ktoś wcześniej uruchomił instalację.

Jedna flaga zmienia odpowiedź

Domyślny skan katalogu w Syft raportuje to, co projekt deklaruje, a nie to, co jest zainstalowane na dysku. Po instalacji zależności w tym samym wydaniu express jedna flaga katalogera decyduje o tym, czy zainstalowane pakiety npm w ogóle pojawią się na liście. To samo narzędzie, ta sama wersja, to samo drzewo.

Produktem jest plik binarny

Repozytorium anthropics/claude-code w wersji v2.1.259 nie ma żadnego manifestu zależności ani lockfile. Jego opublikowany pakiet npm deklaruje zero zależności runtime i opakowuje prekompilowany natywny plik binarny przez osiem pakietów platformowych. @openai/codex 0.149.1 ma taką samą budowę. Czytnik manifestów nie ma tu prawie czego opisywać, a uruchamiany program to skompilowany plik binarny, więc to, co zwraca każde narzędzie, mówi więcej o narzędziu niż o projekcie.

Ten sam pakiet, różne wersje

Gdy dwa narzędzia znajdą to samo, nie zawsze zgadzają się, co to jest. Jedno może przypiąć GitHub Action do SHA commita, a drugie zgłosić tag wydania. Wyszukiwanie podatności według niewłaściwej wersji zwraca pewną siebie, błędną odpowiedź.

Miejsce CRACI obok SCA

Warto zachować SCA w pull requestach. To właściwe miejsce, by wyłapać podatną wersję przed scaleniem. CRACI należy dodać tam, gdzie pytanie dotyczy buildu, a nie zmian w kodzie:

• Co faktycznie zawierało to wydanie? Zarejestrowany SBOM obejmuje źródła npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i Git, a także presety pobierania, łącznie z zależnościami przechodnimi. Działają też mirrory JFrog Artifactory dla npm i PyPI.
• Czy można ufać tej liście? Każde zadanie i każdy cache ma stan kompletności, więc niekompletny zapis jest widoczny, a nie po cichu ubogi.
• Czy dotyczy nas nowy biuletyn? Monitorowane SBOM-y są ponownie oceniane w miarę publikowania nowych podatności, a znaleziska są agregowane z buildów i repozytoriów.

SBOM można pobrać jako CycloneDX przez publiczne REST API, wraz ze śladem sieciowym zadania i danymi o pochodzeniu, więc może zasilać każde narzędzie odczytujące CycloneDX, łącznie z używanym już SCA. Konfiguracja to jeden wiersz w workflow: zmiana runs-on na craci. Dziś obsługiwanym CI jest GitHub Actions; GitLab CI, Jenkins i inne systemy CI są w planach rozwoju.

Inwentarz tego, co jest gdzie wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawi się nowa podatność, widzą Państwo, które produkty używają podatnej wersji, zamiast składać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Więcej o generowaniu SBOM w czasie buildu i śledzeniu podatności.