CRACI vs Dependency-Track

Co Dependency-Track robi dobrze

OWASP Dependency-Track to mocny wybór do analizy komponentów. Jest open source na licencji Apache 2.0, śledzi użycie komponentów we wszystkich wersjach wszystkich aplikacji w Państwa portfolio i pobiera dane o podatnościach z kilku źródeł, w tym z National Vulnerability Database i GitHub Advisories. Jego silnik polityk obejmuje reguły bezpieczeństwa, licencyjne i operacyjne, a platforma przyjmuje i tworzy dokumenty CycloneDX VEX. Projekt oparty na API pasuje do CI/CD: pipeline'y przesyłają SBOM-y do /api/v1/bom.

Zespoły z sektorów regulowanych cenią go za przejrzystość, samodzielny hosting i oparcie na standardowym formacie. Jego słabym punktem nie jest analiza, lecz to, co do niej trafia.

Analiza zależy od danych wejściowych

Dependency-Track przyjmuje SBOM-y, ale ich nie generuje. Każde znalezisko, naruszenie polityki i widok portfolio zależą od SBOM wysłanego przez Państwa pipeline. Jeśli w SBOM brakuje zależności, Dependency-Track nie może jej oznaczyć. Jeśli dwa generatory dają różne wyniki, Dependency-Track pokaże ten, który Państwo przesłali.

W praktyce generatory SBOM często dają różne wyniki, a powody podaje ich własna dokumentacja:

• Brak wspólnej podstawy. Każdy generator sam decyduje, co uznać za komponent i którym plikom ufać, więc dwa z nich skierowane na jedno repozytorium zwracają częściowo pokrywające się, ale różne listy.
• Pomijanie oczywistości. Narzędzie, które rozwiązuje zależności z lockfile, nie ma czego rozwiązywać w repozytorium, które żadnego nie zawiera, jak express 5.2.1. Nadal może zwrócić listę złożoną z tego, co jeszcze rozpozna, na przykład GitHub Actions i plików workflow.
• Wahania zależne od konfiguracji. Syft dobiera swoje katalogery według typu skanu, więc jedna flaga zmienia to, co to samo narzędzie w tej samej wersji zgłasza z tego samego checkoutu.
• Brak manifestu, brak SBOM. Repozytorium bez żadnego manifestu zależności nie daje skanerowi plików nic, na czym mógłby pracować, a to, co zwraca wtedy każde narzędzie, mówi więcej o narzędziu niż o projekcie.
• Skąpe metadane. Większość generatorów nie ma źródła dla pola dostawcy NTIA, więc pozostaje ono puste bez względu na zawartość repozytorium.

CRACI nie można porównać w ten sposób. Rejestruje buildy, a nie skanuje katalogu, więc nie da się go uruchomić tak samo. Nie chodzi o to, że któreś z tych narzędzi jest złe. Chodzi o to, że statyczny skan repozytorium to oszacowanie tego, czego użyje build, a oszacowanie zmienia się wraz z narzędziem, jego ustawieniami i obecnymi plikami.

Co CRACI zmienia u źródła

SBOM pochodzi z buildu

CRACI to runner zgodny z GitHub Actions. Wystarczy zmienić runs-on na craci, a Państwa zadania działają na CRACI w izolowanych maszynach wirtualnych. Podczas każdego zadania proxy rozpoznające pakiety rejestruje ruch do źródeł pakietów: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presety pobierania. Dowody zależności przemieszczają się razem z cache CI, więc pakiet przywrócony z cache nadal jest w zapisie. SBOM, w formacie CycloneDX lub SPDX, zawiera wszystkie zależności przechodnie, których build faktycznie użył.

Informuje, gdy jest niekompletny

Każdy SBOM CRACI ma stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Wiedzą Państwo, czy każdy SBOM to pełny zapis, czy ma lukę. Ma to znaczenie, gdy audytor pyta, skąd wiadomo, że inwentarz jest kompletny.

Rejestruje SBOM wewnątrz buildu

CRACI generuje SBOM wewnątrz własnego runnera na podstawie tego, co pobrało zadanie. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Kontroluje, do czego build może dotrzeć

Ponieważ CRACI uruchamia zadanie, może egzekwować politykę ruchu wychodzącego: domyślna odmowa lub domyślne zezwolenie, z 24 wbudowanymi presetami źródeł oprogramowania i typowanymi źródłami niestandardowymi. Polityki są weryfikowane przed startem zadania i w razie błędu blokują ruch. Dependency-Track może po fakcie poinformować, że komponent jest ryzykowny; polityka ruchu wychodzącego ogranicza to, z jakich źródeł build w ogóle mógł pobierać.

Inwentarz tego, co gdzie jest wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawia się nowa podatność, widać, które produkty działają na dotkniętej wersji, bez składania tego z notatek o wydaniach i arkuszy kalkulacyjnych.

Zastąpienie Dependency-Track przez CRACI

CRACI obejmuje obie połowy zadania, które dotąd wymagało generatora i Dependency-Track. Tworzy SBOM w buildzie, stale ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności, agreguje znaleziska z wielu buildów i repozytoriów oraz pozwala zespołom bezpieczeństwa wykonywać ich triage i przekazywać każde z nich zespołowi odpowiedzialnemu za poprawkę. Nie ma kroku przesyłania do utrzymywania ani serwera do uruchamiania.

Trzeba jasno powiedzieć, z czego Państwo rezygnują. Silnik polityk Dependency-Track jest dojrzały. CRACI ma politykę licencyjną i bramki polityk blokujące buildy, a komentarze i alerty progowe są w planach rozwoju. Dependency-Track jest też open source i hostowany samodzielnie, podczas gdy CRACI jest dziś usługą zarządzaną, a runnery hostowane przez klienta są w planach rozwoju dla Enterprise. Jeśli te kwestie są ważniejsze niż jakość inwentarza, warto pozostać przy Dependency-Track.

Dlaczego ma to znaczenie w sektorach regulowanych

Zgodnie z unijnym Cyber Resilience Act producenci muszą wiedzieć, co znajduje się w każdym wydaniu produktu, i obsługiwać jego podatności, a obowiązki raportowania aktywnie wykorzystywanych podatności wchodzą w życie we wrześniu 2026. Podatność, której Państwo nie widzą, bo SBOM pominął komponent, nadal jest Państwa podatnością.

CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA, i eksportuje SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami. Inwentarz i monitorowanie pochodzą z tego samego zapisu tego, z czego zbudowano każde wydanie. Zob. zgodność z CRA, przemysłowy IoT i telekomunikacja.