CRACI vs stos SBOM DIY

Krótka odpowiedź

Stos DIY złożony z Syft lub Trivy, Grype, Dependency-Track, Cosign i Renovate nie wymaga płatnych licencji, działa wszędzie i daje sprawnemu zespołowi platformowemu pełną kontrolę. CRACI to zarządzany runner GitHub Actions, który rejestruje, co pobrał każdy build, kontroluje, z czym może się on łączyć, monitoruje to, co dostarczono, i eksportuje dowody. Różnica dotyczy nie tyle funkcji, ile tego, skąd pochodzi SBOM i kto utrzymuje styki między narzędziami. Jeśli budują Państwo na GitLab, Jenkins lub Windows albo wszystko musi działać na Państwa własnej infrastrukturze, uczciwą rekomendacją jest dziś DIY.

Jak wygląda taki stos

Kompletne rozwiązanie budowane samodzielnie ma zwykle siedem warstw. Każda to prawdziwy projekt z własnym utrzymaniem.

1. Generowanie. Syft, który generuje SBOM z obrazów kontenerów i systemów plików, Trivy, cdxgen (projekt OWASP, który tworzy BOM-y CycloneDX z kodu źródłowego i obrazów kontenerów) lub Microsoft SBOM Tool, który zapisuje SPDX i oczekuje w wierszu poleceń folderu z wynikami buildu, nazwy pakietu, wersji i dostawcy.
2. Dopasowywanie. Grype skanuje obrazy, systemy plików i SBOM-y, z EPSS, KEV i oceną ryzyka. OSV-Scanner dopasowuje lockfile, SBOM-y i obrazy kontenerów do OSV.dev.
3. Zarządzanie. OWASP Dependency-Track przyjmuje SBOM-y CycloneDX i monitoruje je w czasie. Jego serwer API potrzebuje co najmniej 2 GB RAM i 2 rdzeni CPU (zalecane 8 GB i 4 rdzenie), a dokumentacja kieruje wdrożenia produkcyjne do Docker Compose z osobną bazą danych.
4. Podpisywanie. Cosign podpisuje obrazy, bloby i atestacje SBOM, z podpisywaniem bezkluczowym przez Fulcio i logiem przejrzystości Rekor. GitHub artifact attestations bazują na Sigstore i zapewniają dane o pochodzeniu na poziomie SLSA v1.0 Build Level 2.
5. Aktualizacje. Renovate lub Dependabot otwierają pull requesty, które utrzymują aktualność zależności.
6. Kontrola ruchu wychodzącego. StepSecurity Harden-Runner może audytować lub blokować połączenia wychodzące z zadań GitHub Actions. Jego plan Community jest bezpłatny dla repozytoriów publicznych na runnerach hostowanych przez GitHub; repozytoria prywatne i runnery self-hosted wymagają planu Enterprise. Alternatywą są własne proxy i reguły zapory wokół runnerów self-hosted.
7. Raportowanie. Ktoś musi zamienić wyniki wszystkich powyższych narzędzi w dokumenty potrzebne audytorowi, klientowi lub dokumentacji technicznej CRA.

Koszt kryje się na stykach

Wybór generatora to wybór jego martwych pól

Gdy skieruje się kilka generatorów SBOM na to samo repozytorium, nie zgodzą się co do jego zawartości. Każdy odczytuje inny zestaw plików i inaczej je rozwiązuje, więc otrzymana lista komponentów jest w równym stopniu cechą wybranego narzędzia, co projektu. Pole dostawcy NTIA pokazuje to samo z drugiej strony: większość generatorów nie ma dla niego źródła, więc pozostaje puste niezależnie od zawartości repozytorium.

Żadne z tych narzędzi nie jest zepsute. Każde podejmuje inną, udokumentowaną decyzję o tym, co liczy się jako komponent i którym plikom ufać. Stos DIY dziedziczy jednak wybrane decyzje, a reszta pipeline'u (dopasowywanie, monitorowanie, raportowanie) może być tylko tak kompletna jak ten pierwszy krok.

Spajanie narzędzi to Państwa zadanie

Każde narzędzie ma własny rytm wydań, bazę podatności, format wyjściowy i konfigurację. Ktoś musi przypinać wersje, aktualizować bazy, łatać Dependency-Track i jego bazę danych, rotować tożsamości podpisujące, decydować, który SBOM dokąd trafia, i zauważać, gdy któryś krok po cichu zaczyna dawać mniej. To ciągła praca platformowa, a nie jednorazowa konfiguracja.

Narzędzia też są zależnościami

Narzędzia bezpieczeństwa działają wewnątrz Państwa buildów z dostępem do sekretów, więc należą do Państwa modelu zagrożeń. W marcu 2026 Aqua Security opublikowała biuletyn opisujący, jak przejęte poświadczenia posłużyły do opublikowania złośliwego wydania Trivy i do nadpisania przez force-push większości tagów trivy-action kodem kradnącym poświadczenia na około 12 godzin. Aqua udokumentowała to publicznie, a mogło się to przydarzyć każdemu szeroko używanemu projektowi. Pokazuje to, dlaczego kontrola ruchu wychodzącego na runnerze ma znaczenie: polityka domyślnej odmowy ogranicza, dokąd przejęty krok może wysłać dane, choć nie obejmuje każdego kanału (biuletyn opisuje też mechanizm awaryjny, który tworzył repozytoria na koncie GitHub ofiary).

Kiedy DIY jest właściwym wyborem

• Państwa CI to nie GitHub Actions. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. Zespoły korzystające z GitLab, Jenkins i CircleCI mogą uruchamiać wszystkie powyższe narzędzia open source.
• Budują Państwo na Windows lub macOS. Runnery CRACI to dziś Linux (x86-64 i ARM64); Windows i macOS są w planach rozwoju.
• Wszystko musi działać na Państwa infrastrukturze. CRACI uruchamia dziś zarządzane runnery na europejskiej infrastrukturze, a runnery hostowane u klienta są w planach rozwoju dla Enterprise.
• Mają Państwo zespół platformowy, który chce się tym zajmować. Jeśli utrzymanie stosu jest świadomą inwestycją i Dependency-Track już działa u Państwa dobrze, warto go zachować.
• Potrzebują Państwo jednego SBOM do jednego kwestionariusza. Przy mało istotnej, okazjonalnej prośbie może wystarczyć ręczne uruchomienie generatora.

Co CRACI zastępuje, a czego nie

CRACI obejmuje kilka warstw w jednym miejscu, zaczynając od buildu. Zmieniają Państwo runs-on na craci, a uruchomienia nadal są widoczne w interfejsie GitHub. Proxy rozpoznające pakiety rejestruje, co każde zadanie pobiera ze źródeł npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i Git, a także z presetów pobierania, a dowody zależności przemieszczają się razem z cache CI. Każde zadanie i każdy cache otrzymuje stan kompletności: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.

• Generowanie: CycloneDX i SPDX z zarejestrowanego buildu, łącznie z zależnościami przechodnimi.
• Monitorowanie: znaleziska agregowane z wielu buildów i repozytoriów, a monitorowane SBOM-y są stale ponownie oceniane.
• Pochodzenie: API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu.
• Ruch wychodzący: polityka dla każdego zadania z 24 wbudowanymi presetami źródeł oprogramowania, walidowana przed startem zadania, blokująca ruch w razie błędu, z alertami o naruszeniach.
• Eksport: SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami; brak eksportu raportów.

Nie zastępuje wszystkiego. Listy blokowanych pakietów są w planach rozwoju. Jeśli potrzebują Państwo podpisanych danych o pochodzeniu, należy zachować Cosign lub GitHub artifact attestations. Renovate lub Dependabot nadal mają sens przy utrzymywaniu aktualności wszystkich zależności, nie tylko podatnych. Jeśli Państwa zespół bezpieczeństwa pracuje w Dependency-Track, SBOM CycloneDX można pobrać przez REST API CRACI i zasilić nim to narzędzie.

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 pojawia się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast składać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Na potrzeby Cyber Resilience Act

CRA wymaga od producentów identyfikowania i dokumentowania podatności i komponentów zawartych w produktach z elementami cyfrowymi, między innymi przez sporządzenie SBOM (załącznik I, część II). Zgłaszanie aktywnie wykorzystywanych podatności obowiązuje od września 2026, a na pierwsze powiadomienie są 24 godziny. Stos DIY może to wspierać, o ile ktoś odpowiada za ślad dowodowy od każdego wydania do jego SBOM. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA oraz składa zgłoszenia CRA w Państwa imieniu. Niezależnie od wybranej drogi decyzja o tym, co jest aktywnie wykorzystywane, pozostaje po stronie Państwa zespołu. Zob. zgodność z CRA i generowanie SBOM w czasie buildu.