CRACI i Dependabot

Proszę zachować Dependabot. Oto, co obejmuje.

Jeśli Państwa kod jest w GitHub, prawdopodobnie używają Państwo już Dependabot. Robi on trzy przydatne rzeczy. Alerty Dependabot informują, gdy zależność w repozytorium pasuje do znanej podatności. Aktualizacje zabezpieczeń otwierają pull requesty, które aktualizują podatne zależności. Aktualizacje wersji utrzymują aktualność zależności, nawet gdy nic nie jest podatne.

Wszystko to opiera się na grafie zależności GitHub, który parsuje manifesty i lockfile w Państwa repozytorium. GitHub może wyeksportować ten graf jako SBOM SPDX. W ekosystemach takich jak Go, Gradle i Maven gotowe akcje mogą przesyłać zależności rozwiązane w czasie buildu przez dependency submission API.

Do utrzymywania zależności w aktualnym stanie niewielkim wysiłkiem Dependabot trudno pobić, a CRACI nie otwiera pull requestów. CRACI dodaje drugą połowę: zapis tego, co naprawdę pobrał każdy build, monitorowany pod kątem nowych podatności, dzięki czemu wiedzą Państwo, których dostarczonych buildów dotyczy nowy biuletyn i które pull requesty z aktualizacjami scalić najpierw.

Pytania, na które Dependabot nie odpowiada

Dependabot jest zbudowany wokół repozytorium. Skanuje domyślną gałąź i polega na Państwa manifestach i lockfile. Dokumentacja GitHub mówi o tym wprost: alerty nie wychwycą każdego problemu bezpieczeństwa, dla dokładnego wykrywania należy utrzymywać aktualne manifesty i lockfile, a alerty wywołują tylko biuletyny zweryfikowane przez GitHub.

Pozostają pytania, które osoba odpowiedzialna za bezpieczeństwo lub zgodność w końcu usłyszy:

• Co naprawdę pobrał build wydania 4.2, łącznie z narzędziami i obrazami spoza manifestów?
• Czy build mógł podczas działania połączyć się z dowolnym hostem w internecie?
• Czy można udowodnić, że plik binarny otrzymany przez klienta pochodzi z tego buildu?
• Czy można przedstawić te dowody audytorowi wiele miesięcy później?

Odpowiedź wymaga wglądu z wnętrza buildu, a właśnie tam działa CRACI.

Co dodaje CRACI

Widoczność w czasie 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, przy czym uruchomienia nadal są widoczne w interfejsie GitHub. 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. Pakiety przywrócone z cache CI są uwzględniane dalej, ponieważ dowody zależności przemieszczają się razem z cache.

Każdy SBOM podaje, jak bardzo jest kompletny, dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. To co innego niż graf, który jest tylko tak dobry jak parsowane przez niego pliki.

Różnica ujawnia się w praktyce. Eksport grafu zależności GitHub powstaje z tego, co GitHub wie o repozytorium, więc może wymieniać komponenty, których nie znajdzie żaden skaner plików, i odzwierciedla domyślną gałąź, a nie commit, który Państwo zbudowali. Żadne z tych zachowań nie jest błędem w świetle tego, do czego służy graf. Pokazują one, dlaczego widok repozytorium i zapis buildu to różne rzeczy. (CRACI nie można porównać w ten sposób, ponieważ rejestruje buildy, a nie skanuje katalogów.)

Kontrole w czasie działania

Dependabot informuje o podatnym pakiecie, gdy jest on już w manifeście. Nie ma wpływu na to, z czym build może się łączyć. CRACI ma, ponieważ uruchamia build. Polityki ruchu wychodzącego działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania, typowanymi źródłami niestandardowymi dla npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestrów OCI i Git oraz jawnymi regułami TLS, TCP, UDP i ICMP. Polityki są weryfikowane przed startem zadania, w razie błędu blokują ruch i wywołują alert przy naruszeniu.

Dane o pochodzeniu

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.

Dowody zgodności

Regulacje takie jak unijny Cyber Resilience Act wymagają od producentów, aby wiedzieli, co znajduje się w każdym wydaniu produktu, i obsługiwali jego podatności. CRACI agreguje podatności z wielu buildów i repozytoriów, stale ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych biuletynów i eksportuje SBOM-y w formacie CycloneDX lub SPDX, łącznie z podatnościami. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA. Więcej: czym jest CRA i dowody dla CRA.

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.

Jak zespoły używają obu

• Dependabot utrzymuje aktualność zależności w domyślnej gałęzi i otwiera pull requesty, gdy pojawiają się biuletyny.
• CRACI uruchamia zadania GitHub Actions, rejestruje, co pobrał każdy build, ogranicza, z czym buildy mogą się łączyć, monitoruje to, co pobrał każdy build, pod kątem nowych podatności i przechowuje dowody wydań.

Nie ma czego migrować. Dependabot nadal działa w Państwa repozytoriach, a workflow nadal działają w GitHub Actions, tylko na innym runnerze.

CRACI i Dependabot: najczęstsze pytania

Co obejmuje każde narzędzie, SBOM-y, ceny i zgodność

Czy CRACI zastępuje Dependabot?

Nie. Dependabot warto zostawić włączony. Oznacza podatne zależności w Państwa repozytoriach i otwiera pull requesty, które je aktualizują. CRACI uruchamia Państwa zadania GitHub Actions i rejestruje, co naprawdę pobrał każdy build, kontroluje, z czym buildy mogą się łączyć, i monitoruje to, co zostało dostarczone, pod kątem nowych podatności.

Czy widoki podatności w CRACI zastępują alerty Dependabot?

Nie. Odpowiadają na inne pytanie. Alerty Dependabot dotyczą domyślnej gałęzi jednego repozytorium. CRACI agreguje podatności z wielu buildów i repozytoriów i stale ponownie ocenia monitorowane SBOM-y, dzięki czemu widać, które buildy mają wspólną podatną zależność, a zespoły bezpieczeństwa mogą wykonywać triage znalezisk i przekazywać je zespołowi odpowiedzialnemu za poprawkę. Bramki polityk mogą zablokować build; alerty progowe są w planach rozwoju.

Czy CRACI otwiera pull requesty tak jak Dependabot?

Nie. Aktualizacje zabezpieczeń i aktualizacje wersji Dependabot otwierają pull requesty; CRACI tego nie robi. CRACI dodaje zapis buildu, więc gdy pojawia się nowy biuletyn, wiedzą Państwo, których dostarczonych buildów dotyczy i które pull requesty z aktualizacjami scalić najpierw.

Czym różnią się SBOM-y z GitHub i CRACI?

GitHub eksportuje graf zależności jako SBOM SPDX, zbudowany z manifestów i lockfile w repozytorium oraz dependency submission API, i odzwierciedla on domyślną gałąź. CRACI rejestruje SBOM podczas działania każdego buildu i eksportuje go w formacie CycloneDX lub SPDX, ze stanem kompletności dla każdego zadania i każdego cache, który informuje, czy w zapisie wystąpiła luka.

Czy CRACI pomaga, gdy zależności nie ma w żadnym manifeście?

Tak, jeśli build pobiera ją ze źródła pakietów. Ponieważ CRACI rejestruje ruch podczas zadania, narzędzie pobrane przez skrypt lub pakiet przywrócony z cache nadal pojawia się w zapisie buildu, a stan kompletności SBOM informuje, czy czegoś nie udało się zarejestrować.

Ile kosztują Dependabot i CRACI?

Aktualizacje zabezpieczeń i aktualizacje wersji Dependabot wchodzą w skład każdego planu GitHub, także Free (stan na wrzesień 2026). CRACI pobiera opłaty tylko za minuty buildu: $0.002 za minutę vCPU ($0.004 za domyślny runner 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej i bez opłat za SBOM. Aktualne warunki podaje strona cennika.

Czy CRACI jest tylko dla zespołów z wymaganiami zgodności?

Nie, ale tam dowody przynoszą największą korzyść. Jeśli sprzedają Państwo oprogramowanie w UE, Cyber Resilience Act czyni inwentarz komponentów każdego wydania i obsługę podatności częścią pracy. Dla wszystkich pozostałych wiedza o tym, co pobierają buildy, nadal jest podstawą reagowania na incydenty w łańcuchu dostaw. Proszę umówić demo, aby zobaczyć zapis buildu jednego z Państwa workflow.