Co CRACI zastępuje w Państwa stacku, a co uzupełnia

Krótka odpowiedź: co przechodzi, a co zostaje

Za pomocą tej tabeli mogą Państwo rozpisać własny stack. Każdy wiersz to zadanie, które dziś wykonuje narzędzie w Państwa stacku, to, co to zadanie musi widzieć, aby je wykonać, oraz to, czy CRACI wykonuje je z miejsca, w którym działa.

Zadanie w Państwa stacku	Co zadanie musi widzieć	CRACI	Co Państwo zachowują i dlaczego
Runnery CI dla zadań Linux w GitHub Actions: hostowane przez GitHub, od zewnętrznego dostawcy runnerów lub własna flota self-hosted	Miejsce do uruchomienia zadania	Zastępuje	Runnery dla Windows, macOS, GitHub Enterprise Server i systemów CI innych niż GitHub Actions, których CRACI dziś nie obsługuje
Monitoring sieci lub agenty ruchu wychodzącego dodane do zachowywanych runnerów	Ruch wychodzący zadania	Zastępuje na runnerach CRACI	Agenty na runnerach, które Państwo utrzymują gdzie indziej
Generatory SBOM uruchamiane w CI, zespół po zespole: skanery manifestów, lockfile lub obrazów używane do tworzenia SBOM-ów	To, co build faktycznie pobrał	Zastępuje dla buildów w CRACI	Generatory dla oprogramowania, którego Państwo nie budują w CRACI, np. obrazów, które pobierają, ale nigdy nie budują
Wbudowane generowanie SBOM w Yocto (create-spdx) na potrzeby pokrycia łańcucha dostaw	Każde źródło i narzędzie pobrane przez build BitBake	Zastępuje w zakresie pokrycia łańcucha dostaw	create-spdx, jeśli polegają Państwo na jego metadanych receptur: zastosowanych łatkach i CVE oznaczonych jako naprawione
Śledzenie podatności na podstawie SBOM: przesyłanie SBOM-ów, dopasowywanie biuletynów, obserwowanie nowych	Dokładny SBOM dla każdego wydania, stale aktualny	Zastępuje dla buildów w CRACI; można dodać SBOM-y dostawców	Dedykowane narzędzie, jeśli potrzebują Państwo tego, czego CRACI nie robi: reachability, metryk naprawy takich jak MTTR czy terminy według ważności
SBOM-y i listy komponentów prowadzone w arkuszach kalkulacyjnych	Dokładny SBOM dla każdego wydania, stale aktualny	Zastępuje	Nic
Kontrola deklarowanych licencji i polityka licencyjna	Deklarowana licencja każdego komponentu	Częściowo	Skanowanie licencji w pełnym tekście i na poziomie fragmentów kodu, noty atrybucyjne
SAST i skanowanie kodu	Państwa kod źródłowy	Uzupełnia	Zachować; działa bez zmian jako krok workflow na runnerze CRACI
Skanowanie sekretów i push protection	Państwa repozytorium i commity	Uzupełnia	Zachować
DAST i testy API	Państwa działająca usługa	Uzupełnia	Zachować
Analiza plików binarnych i firmware'u stron trzecich	Gotowy plik binarny, którego Państwo nie zbudowali	Uzupełnia	Zachować
Skanowanie fragmentów i sygnatur pod kątem skopiowanego lub dołączonego (vendored) kodu	Zawartość plików w repozytorium	Uzupełnia	Zachować
Priorytetyzacja oparta na reachability	Państwa graf wywołań	Uzupełnia	Zachować, jeśli Państwo na niej polegają
Skanowanie IaC, klastrów i błędnych konfiguracji	Konfiguracja i działająca infrastruktura	Uzupełnia	Zachować
Kontrole postury CI/CD w konfiguracji workflow	Pliki i ustawienia workflow	Uzupełnia	Zachować
Ticketing, obsługa zgłoszeń PSIRT, publikowanie biuletynów bezpieczeństwa	Państwa proces	Uzupełnia	Zachować
Automatyzacja zgodności: zbieranie dowodów na potrzeby audytów SOC 2 lub ISO 27001	Państwa kontrole we wszystkich systemach	Uzupełnia	Zachować; zapisy CRACI są dowodami, które może zbierać

Przed i po

Przed: runnery hostowane przez GitHub, inny generator SBOM w workflow każdego zespołu, create-spdx w Yocto wydłużający czas buildu oraz SBOM-y przesyłane do trackera lub arkusza kalkulacyjnego, a wokół nich skanowanie kodu, skanowanie sekretów, analiza plików binarnych i ticketing. Po: runnery CRACI, które uruchamiają każde zadanie, egzekwują jego politykę ruchu wychodzącego, rejestrują jego SBOM i stale go monitorują. Narzędzia, które czytają kod, repozytoria, pliki binarne i Państwa proces, pozostają bez zmian.

Co zastępuje CRACI i dlaczego

Każde z tych zadań odbywa się w trakcie buildu. CRACI może je przejąć, ponieważ to w nim działa build. Dla każdego z nich: mechanizm, z czego Państwo rezygnują, oraz przykład.

Państwa runnery

CRACI to runner dla GitHub Actions. Zmieniają Państwo runs-on na craci, a uruchomienia nadal pojawiają się w GitHub jak każde inne zadanie Actions. Każde zadanie dostaje własną maszynę wirtualną, z Linuksem na x86-64 lub ARM64, w rozmiarze od 1 do 32 vCPU, rozliczaną co do sekundy. Nie trzeba przepisywać workflow: istniejące kroki, w tym kroki skanowania, działają dalej.

CRACI pobiera opłaty wyłącznie za minuty buildu: $0.002 za vCPU-minutę ($0.004 za domyślny runner z 2 vCPU), rozliczane co do sekundy, bez opłaty miesięcznej i bez opłat za SBOM. To czyni go jednym z najtańszych runnerów CI. Wykonuje buildy mniej więcej dwa razy szybciej niż runnery hostowane przez GitHub dzięki szybszemu sprzętowi, krótszym kolejkom i cache.

Runner, za minutę	CRACI	Hostowany przez GitHub	Różnica
2 vCPU x64	$0.004	$0.006	CRACI około 33% taniej
2 vCPU ARM64	$0.004	$0.005	CRACI 20% taniej
32 vCPU x64	$0.064	$0.082	CRACI około 22% taniej
32 vCPU ARM64	$0.064	$0.050	CRACI 28% drożej

Ceny katalogowe GitHub według stanu na wrzesień 2026. GitHub zaokrągla każde zadanie w górę do pełnej minuty; CRACI rozlicza co do sekundy. Przykład: 10-minutowy build na hostowanym przez GitHub runnerze x64 z 2 rdzeniami kosztuje $0.060. Przy mniej więcej dwukrotnie większej szybkości trwa 5 minut na runnerze CRACI z 2 vCPU i kosztuje $0.020, czyli około 67% mniej. Zobacz cennik i ceny runnerów CI.

Z czego Państwo rezygnują. Runnery Windows i macOS, inne systemy CI oraz runnery hostowane przez klienta nie są dziś dostępne; GitLab CI, Jenkins, Windows, macOS i runnery hostowane przez klienta są na roadmapie. GitHub Enterprise Server nie jest obsługiwany. Runnery są zarządzane, na europejskiej infrastrukturze. Jeśli porównują Państwo zarządzane runnery z własną flotą, zobacz runnery zarządzane a self-hosted.

Agenty ruchu wychodzącego na zachowywanych runnerach

Agent ruchu wychodzącego obserwuje lub ogranicza ruch runnera obsługiwanego przez kogoś innego. W CRACI sam runner egzekwuje politykę ruchu wychodzącego: domyślne blokowanie lub zezwalanie, 24 wbudowane presety źródeł oprogramowania, typowane niestandardowe źródła dla rejestrów pakietów i Git oraz jawne reguły sieciowe. Polityka jest walidowana przed startem zadania i w razie błędu domyka dostęp (fail closed), a CRACI alarmuje o naruszeniach polityki. Osobny agent nie jest potrzebny na runnerach CRACI.

Przykład: przejęta zależność próbuje wysłać sekrety zadania do hosta, którego build nigdy nie potrzebował. Przy polityce default-deny połączenie zostaje zablokowane, nawet w ataku, którego nikt wcześniej nie widział, ponieważ polityka zezwala tylko na to, czego build potrzebuje, zamiast szukać znanych złośliwych hostów.

Z czego Państwo rezygnują. Polityka obejmuje zadania na runnerach CRACI. Runnery utrzymywane gdzie indziej nadal potrzebują własnej kontroli.

Generator SBOM w workflow każdego zespołu

Generator czyta pliki, które ma przed sobą, takie jak manifest, lockfile czy obraz, i odtwarza, co do nich trafiło. Różne generatory zwracają różne listy z tego samego checkoutu, a zespoły zwykle wybierają własne, więc organizacja kończy z kilkoma inwentarzami, które do siebie nie pasują.

CRACI rejestruje pakiety, które każde zadanie faktycznie pobrało, w tym pakiety przywrócone z cache CI, oraz ukryte zależności, które pomijają narzędzia oparte na lockfile: kod pobierany przez hooki npm install, skrypty buildu Rust, które pobierają dane w czasie buildu, oraz obraz bazowy z warstwami systemu operacyjnego w buildzie kontenera. Każdy komponent w SBOM był w buildzie. SBOM każdego zadania podaje swoją kompletność jako Complete, Complete with connections, Incomplete, Unavailable lub Not recorded, więc luka jest widoczna, a nie ukryta. Wynikiem jest jeden inwentarz dla każdego repozytorium budowanego w CRACI, eksportowany jako CycloneDX lub SPDX. Ekosystemy rejestrowane dziś: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk i źródła Git, a także pobrania Yocto i OpenEmbedded.

Przykład: expressjs/express 5.2.1 nie commituje lockfile. Generator, który rozwiązuje zależności na podstawie lockfile, nie ma tam czego rozwiązywać, a mimo to może zwrócić dokument, w którym nie ma żadnej z zależności npm zadeklarowanych w package.json. Build tego samego projektu w CRACI rejestruje pakiety pobrane przez npm install. Więcej o metodzie w SBOM-ach z czasu buildu i porównaniu narzędzi SCA i SBOM; zestaw generatorów do samodzielnego złożenia opisuje stack SBOM DIY.

Z czego Państwo rezygnują. Z ekosystemów, których CRACI jeszcze nie rejestruje. Maven i Java są na roadmapie, a wszystko, czego nie ma na powyższej liście, nie jest objęte. Dla tych buildów warto zachować generator.

Wbudowane generowanie SBOM w Yocto

Yocto tworzy własny SBOM SPDX za pomocą create-spdx i jest on dokładny w odniesieniu do tego, co buduje BitBake. Nie widzi jednak tego, co dzieje się poza metadanymi BitBake. CRACI uruchamia build BitBake i rejestruje, co zostało pobrane. W porównawczym buildzie core-image-sato na natywnym runnerze ARM64 z 32 vCPU SBOM CRACI zawierał każdy komponent z SBOM-u Yocto oraz 88, które Yocto pominął: 23 pakiety hosta na maszynie buildowej, 10 źródeł z GitHub, w tym GitHub Action actions/upload-artifact, oraz 55 innych źródeł i narzędzi pobranych w trakcie buildu. Zarejestrował wszystkie 653 wersje crate'ów Rust z adresami package URL pkg:cargo, dzięki czemu można je dopasować do biuletynów bezpieczeństwa. Build bez generowania SBOM w Yocto trwał o 43% krócej: około $9.96 wobec $5.68 za build w cenach CRACI.

Z czego Państwo rezygnują. SPDX z Yocto zawiera metadane receptur, których CRACI nie rejestruje: zastosowane łatki i CVE oznaczone jako naprawione. Jeśli Państwo na nich polegają, warto pozostawić włączony create-spdx. Metoda i pełne porównanie są opisane w buildach Yocto w CRACI.

Od SBOM-ów do śledzenia podatności

Samodzielny tracker trzeba zasilić SBOM-em, a on ufa temu, co dostanie. CRACI tworzy SBOM i przechowuje zapis. Monitorowane SBOM-y są stale ponownie oceniane w miarę publikowania nowych biuletynów. Historia buildów pokazuje, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, więc wiedzą Państwo, w jakim okresie byli narażeni, w ramach okresu przechowywania danych w Państwa planie. Ustalenia są przypisywane zespołowi odpowiedzialnemu za poprawkę, CRACI powiadamia właściwe osoby o podatności i jej ważności, a bramki polityk mogą zablokować build z powodu ustaleń, w tym build zawierający konkretną CVE. VEX jest obsługiwany. Można dodać SBOM-y dostawców, dzięki czemu kupowane komponenty są monitorowane razem z Państwa własnymi buildami.

Przykład: zostaje opublikowany biuletyn dla crate'a, który jedna z Państwa usług wkompilowała trzy miesiące temu. CRACI dopasowuje go do każdego monitorowanego SBOM-u i pokazuje, które buildy zawierały tę wersję, bez ponownego przesyłania czegokolwiek.

Z czego Państwo rezygnują. CRACI nie oferuje analizy reachability ani metryk naprawy, takich jak MTTR, terminy według ważności czy trendy backlogu. Jeśli Państwo od nich zależą, warto zachować narzędzie, które je dostarcza. Pełny zakres funkcji opisuje śledzenie podatności.

Arkusz kalkulacyjny

W zespołach bez narzędzi SBOM CRACI zastępuje ręczne składanie: ktoś kopiuje listy zależności do arkusza kalkulacyjnego przed wydaniem lub audytem. Build w CRACI tworzy SBOM jako efekt uboczny działania, więc lista istnieje dla każdego buildu, a nie tylko dla tych, o których ktoś pamiętał.

Co CRACI uzupełnia i jak

Te narzędzia czytają rzeczy, których CRACI nigdy nie czyta. CRACI nie czyta Państwa kodu źródłowego w poszukiwaniu błędów, nie testuje działających usług i nie analizuje plików binarnych, których nie zbudował. Działają dalej tak jak teraz.

Narzędzia, które czytają Państwa kod i repozytorium

SAST, skanowanie sekretów i push protection, skanowanie fragmentów i sygnatur, skanowanie IaC oraz kontrole postury CI/CD analizują Państwa kod, commity lub konfigurację. Kroki w workflow działają bez zmian na runnerze CRACI, a funkcje na poziomie repozytorium pozostają nienaruszone, ponieważ nigdy nie działały na runnerze. Krok skanowania kodu może znajdować się w tym samym zadaniu co build. SAST jest celowo poza zakresem: wiele doskonałych narzędzi SAST działa razem z CRACI. Czym różnią się oba rodzaje ustaleń, wyjaśnia SAST a SCA.

Narzędzia, które analizują to, czego Państwo nie zbudowali

Analiza plików binarnych i firmware'u dostawców, skanery obrazów, które Państwo pobierają, ale nigdy nie budują, oraz DAST działających usług badają coś, co zostało zbudowane gdzie indziej lub już działa. CRACI rejestruje buildy; plik binarny od dostawcy został zbudowany w miejscu, którego CRACI nigdy nie widział. Jeśli dostawca przekaże Państwu SBOM, CRACI może go monitorować razem z Państwa własnymi buildami.

Priorytetyzacja oparta na reachability czyta Państwa graf wywołań, którego CRACI nie analizuje. Warto ją zachować, jeśli Państwo na niej polegają; co może, a czego nie może powiedzieć, opisuje analiza reachability.

Systemy procesowe

Ticketing, obsługa zgłoszeń PSIRT, publikowanie biuletynów bezpieczeństwa i platformy automatyzacji zgodności prowadzą Państwa proces w wielu systemach. CRACI kieruje ustalenia do odpowiedzialnego zespołu i przechowuje dowody z buildu; do reszty warto zachować narzędzia procesowe. Zapisy opuszczają CRACI jako SBOM-y CycloneDX lub SPDX oraz przez API, które zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. W kwestii audytów zobacz kontrole SBOM dla SOC 2. Pracę z licencjami wykraczającą poza deklarowane licencje, taką jak noty i przegląd pełnego tekstu, opisuje zgodność licencji open source. CRACI przenosi deklarowaną licencję każdego komponentu i egzekwuje reguły polityki licencyjnej, w tym blokowanie buildu z powodu licencji.

Jak znaleźć punkt zastąpienia we własnym stacku

Pięć pytań, na które można odpowiedzieć w jedno popołudnie. Każda odpowiedź mówi, czy dana pozycja w stacku się przenosi.

1. Czy Państwa buildy działają w GitHub Actions na Linuksie? Jeśli tak, runnery się przenoszą. Jeśli nie, CRACI dziś niczego nie zastępuje.
2. Kto dziś generuje SBOM-y i ile różnych generatorów jest w użyciu? Każdy generator w repozytorium przeniesionym do CRACI to pozycja, która znika.
3. Czy budują Państwo obrazy Yocto? Jeśli tak, przed wyłączeniem create-spdx warto sprawdzić, czy ktoś polega na zastosowanych łatkach i naprawionych CVE w jego wynikach.
4. Dokąd trafiają SBOM-y po wygenerowaniu: do trackera, do arkusza kalkulacyjnego, donikąd? To narzędzie lub proces jest drugą pozycją, która znika, chyba że potrzebują Państwo z niego reachability lub metryk naprawy.
5. Które z Państwa narzędzi bezpieczeństwa czytają kod, repozytoria lub pliki binarne stron trzecich? Te zostają. Warto je spisać, aby nikt nie oczekiwał, że CRACI je zastąpi.

Przykład krok po kroku

Przykładowy producent urządzeń, niewzorowany na żadnej prawdziwej firmie: buildy Linux na runnerach hostowanych przez GitHub, dwa zespoły korzystające z dwóch różnych generatorów SBOM, linia produktów Yocto z włączonym create-spdx, SBOM-y zbierane we wspólnym arkuszu kalkulacyjnym, pakiet do skanowania kodu i system ticketowy. Zespół bezpieczeństwa odpowiada twierdząco na pytania 1 i 3, znajduje dwa generatory w pytaniu 2 i arkusz kalkulacyjny w pytaniu 4, a w pytaniu 5 wymienia skanowanie kodu, skanowanie sekretów i system ticketowy. Nikt nie korzysta z metadanych łatek w SPDX z Yocto.

Przechodzi do CRACI	Zostaje
Runnery hostowane przez GitHub dla zadań Linux	Skanowanie kodu, uruchamiane jako krok na runnerach CRACI
Oba generatory SBOM	Skanowanie sekretów
create-spdx, bo nikt nie potrzebuje jego metadanych łatek	System ticketowy
Arkusz kalkulacyjny z SBOM-ami

W pozycji runnerów 10-minutowy build, który kosztuje $0.060 na hostowanym przez GitHub runnerze x64 z 2 rdzeniami, kosztuje w CRACI około $0.020 dzięki przyspieszeniu. Koszty pozostałych narzędzi firma musi uzupełnić sama.

Kiedy CRACI nie jest odpowiedzią

• Państwa pipeline'y działają w GitLab CI, Jenkins, Azure DevOps lub innym systemie CI. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są na roadmapie, więc na razie niczego nie zastępuje.
• Państwa buildy wymagają runnerów Windows lub macOS albo GitHub Enterprise Server lub muszą działać na własnej infrastrukturze.
• Głównym problemem jest szum ze skanowania kodu w Państwa własnym kodzie. To kwestia dostrojenia SAST; zobacz SAST a SCA i jak ograniczyć szum podatności.
• Głównym ryzykiem są firmware i pliki binarne otrzymywane od dostawców, a nie kod, który Państwo budują.
• Państwa stack to głównie Java i Maven, które są na roadmapie, lub .NET, którego nie ma na liście ekosystemów rejestrowanych przez CRACI.
• Potrzebują Państwo już dziś priorytetyzacji opartej na reachability lub obsługi zgłoszeń PSIRT.

Działanie produktu krok po kroku opisuje strona jak działa CRACI; sam SBOM opisuje generowanie SBOM.

Co zastępuje CRACI: najczęściej zadawane pytania

Co zastępuje CRACI?

Państwa runnery GitHub Actions dla zadań Linux, generatory SBOM uruchamiane przez zespoły w CI dla buildów przeniesionych do CRACI, create-spdx w Yocto na potrzeby pokrycia łańcucha dostaw, agenty ruchu wychodzącego na runnerach oraz samodzielne śledzenie podatności na podstawie SBOM dla tych buildów. Nie zastępuje narzędzi, które czytają Państwa kod, repozytoria lub pliki binarne stron trzecich.

Czy CRACI jest dodatkiem do naszego narzędzia SCA, czy coś zastępuje?

Zastępuje zadania w warstwie buildu: runner, generowanie SBOM i śledzenie wynikające z SBOM. To, czy wypiera Państwa narzędzie SCA, zależy od tego, do czego go Państwo używają. Jeśli czyta Państwa kod, wykonuje analizę fragmentów lub plików binarnych albo zapewnia reachability, te części zostają.

Czy nadal potrzebujemy naszego generatora SBOM, jeśli uruchamiamy buildy w CRACI?

Nie dla buildów, które działają w CRACI i korzystają z rejestrowanych przez niego ekosystemów. CRACI rejestruje pakiety pobrane przez każde zadanie i eksportuje SBOM jako CycloneDX lub SPDX. Generator warto zachować dla oprogramowania, którego Państwo nie budują w CRACI, np. pobieranych obrazów, oraz dla ekosystemów, których CRACI jeszcze nie rejestruje, np. Maven.

Czy nadal potrzebujemy wbudowanego generowania SBOM w Yocto (create-spdx)?

Na potrzeby pokrycia łańcucha dostaw nie: w porównawczym buildzie core-image-sato SBOM CRACI zawierał każdy komponent z SBOM-u Yocto oraz 88, które Yocto pominął, a build bez create-spdx trwał o 43% krócej. Warto pozostawić włączony create-spdx, jeśli polegają Państwo na jego zastosowanych łatkach i CVE oznaczonych jako naprawione, których CRACI nie rejestruje.

Czy CRACI zastępuje skanowanie kodu lub skanowanie sekretów?

Nie. CRACI nie czyta Państwa kodu źródłowego ani commitów w poszukiwaniu błędów czy sekretów. Te narzędzia warto zachować. Kroki skanowania kodu działają bez zmian w Państwa workflow na runnerze CRACI, a funkcje na poziomie repozytorium pozostają nienaruszone.

Czy CRACI zastępuje analizę plików binarnych lub firmware'u?

Nie. CRACI rejestruje buildy, które uruchamia. Dla firmware'u i plików binarnych otrzymywanych od dostawców właściwym narzędziem jest analiza plików binarnych. Jeśli dostawca przekaże Państwu SBOM, CRACI może go monitorować razem z Państwa własnymi buildami.

Czy możemy zachować istniejące kroki bezpieczeństwa w GitHub Actions na runnerach CRACI?

Tak. CRACI zastępuje runner, a nie GitHub Actions: ustawiają Państwo runs-on na craci, a workflow, kroki i wyniki pozostają w GitHub. Kroki skanowania, testów i wszystkie inne działają dalej jak wcześniej.