Porównanie
CRACI vs Renovate
Renovate utrzymuje aktualność Państwa zależności według napisanych przez Państwa reguł. CRACI zaczyna od drugiego końca: rejestruje, co każdy build faktycznie pobrał, i nadal to monitoruje, dzięki czemu wiedzą Państwo, których dostarczonych buildów dotyczy nowy biuletyn.
Zaktualizowano
Krótka odpowiedź
Renovate służy do higieny zależności: znajduje pliki pakietów, otwiera pull requesty z aktualizacjami i pozwala ograniczać szum za pomocą harmonogramów, grupowania i automerge. CRACI to runner GitHub Actions, który rejestruje, co pobrał każdy build, i monitoruje te SBOM-y pod kątem nowych podatności. Renovate pyta, czy jest nowsza wersja. CRACI pyta, czy coś w tym, co zbudowaliśmy i dostarczyliśmy, jest podatne, i gdzie. Nie konkurują o to samo zadanie i działają obok siebie: Renovate otwiera pull requesty z aktualizacjami, a CRACI mówi Państwu, które buildy ich potrzebują.
| Funkcja | CRACI | Renovate |
|---|---|---|
| Na co odpowiada | Które z dostarczonych buildów zawierają podatny pakiet | Które zależności mają nowszą wersję lub alert o podatności |
| Uruchamia Państwa buildy | Zadania działają na runnerach CRACI | Czyta repozytoria, a nie buildy |
| Zależności rejestrowane z buildu | Zaobserwowane pobrania, łącznie z pakietami z cache | Znajduje odwołania w plikach pakietów |
| Otwiera pull requesty z aktualizacjami | Aktualizacje według harmonogramu oraz poprawki z alertów GitHub lub OSV | |
| Triage i przekazywanie do odpowiedzialnych zespołów | W wielu buildach i repozytoriach | Dependency Dashboard dla każdego repozytorium |
| Menedżery pakietów | Wykrywa npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk, Git | Ponad 90 menedżerów pakietów |
| Poza GitHub | Dziś GitHub Actions; GitLab CI i Jenkins w planach rozwoju | GitLab, Bitbucket, Azure DevOps i inne |
| Polityka ruchu wychodzącego na runnerze | Domyślna odmowa lub zezwolenie, blokuje w razie błędu | Poza jego zakresem |
| SBOM i dane o pochodzeniu | Dla każdego buildu, kompletność dla zadania i cache | Poza jego zakresem |
| Monitorowanie dostarczonych SBOM-ów | Monitorowane SBOM-y stale ponownie oceniane | Poza jego zakresem |
| Self-hosting | Dziś zarządzany; runnery hostowane u klienta w planach rozwoju, Enterprise | CLI, Docker lub self-hosted edycja Community |
| Cena | $0.002 za minutę vCPU ($0.004 za 2 vCPU), naliczane co sekundę; bez opłaty miesięcznej i bez opłat za SBOM | Open source na licencji AGPL-3.0. Mend Renovate Community jest bezpłatny; Mend Renovate Enterprise to plan płatny (stan na wrzesień 2026). |
- W zestawie
- Częściowo
- Brak
- W planach rozwoju
Co Renovate robi dobrze
Dokumentacja Renovate zaczyna się od słów „Automated dependency updates. Multi-platform and multi-language.” Obie części są zasłużone. Narzędzie „looks for references to dependencies (both public and private)” w Państwa repozytorium, a gdy istnieją nowsze wersje, otwiera pull requesty aktualizujące je wraz z plikami lock.
- Zakres. Ponad 90 menedżerów pakietów oraz repozytoria w GitHub, GitLab, Bitbucket, Azure DevOps, Gitea i Forgejo, a AWS CodeCommit, Gerrit i SCM-Manager są wymienione jako eksperymentalne.
- Kontrola. Współdzielone presety konfiguracji,
packageRulesdo określania zachowania dla poszczególnych pakietów, harmonogramy ograniczające czas pojawiania się pull requestów oraz automerge dla zaufanych aktualizacji. Dokumentacja zauważa, że większość zespołów zostawia aktualizacje wersji głównych człowiekowi. - Widoczność. Zgłoszenie Dependency Dashboard, domyślnie włączone w
config:recommended, oraz informacje pomagające zdecydować, które aktualizacje przyjąć: wiek, popularność, wskaźniki powodzenia i merge confidence. - Zasięg. Niestandardowe menedżery obsługują własnościowe formaty plików i popularne formaty, których Renovate jeszcze nie obsługuje.
- Wybór wdrożenia. Open source na licencji AGPL-3.0, utrzymywany przez Mend. Można samodzielnie uruchamiać CLI lub obraz Docker, korzystać z bezpłatnej aplikacji chmurowej Mend Renovate Community w GitHub.com i Bitbucket Cloud albo uruchamiać self-hosted edycje Community lub płatną Enterprise.
Jak Renovate obsługuje podatności
Renovate ma dwie drogi do poprawek bezpieczeństwa. Z vulnerabilityAlerts odczytuje alerty o podatnościach GitHub, co wymaga włączenia grafu zależności i alertów Dependabot. Te pull requesty „skip the line”, ignorując harmonogramy i limity godzinowe, a domyślnie przechodzą na najniższą naprawioną wersję. Z osvVulnerabilityAlerts sprawdza zależności w bazie OSV, którą pobiera i odpytuje offline. Dokumentacja precyzyjnie określa ograniczenie: „You will only get OSV-based vulnerability alerts for direct dependencies”, dla wymienionego zestawu źródeł danych.
CRACI nie zastępuje niczego z tego i nie otwiera pull requestów. Jeśli Państwa celem jest utrzymywanie aktualności setek repozytoriów przy minimalnym wysiłku, Renovate powstał właśnie do tego.
Czym różni się CRACI
Zaczyna od buildu, a nie od plików pakietów
Renovate pracuje na tym, co deklaruje Państwa repozytorium. Build często robi więcej: rozwiązuje wersje w czasie instalacji, przywraca pakiety z cache i pobiera narzędzia, pakiety systemowe i obrazy, których nie wymienia żaden manifest. expressjs/express 5.2.1 pokazuje tę lukę najprościej: nie ma lockfile w repozytorium, więc generator uruchomiony na czystym checkoucie nie ma czego rozwiązać i nie zgłasza żadnej z zależności npm tego projektu, niezależnie od jakości narzędzia. CRACI nie da się porównać w ten sposób, ponieważ rejestruje buildy, a nie skanuje katalogi. Pliki w repozytorium i pakiety w buildzie to nie ta sama lista.
CRACI uruchamia build. Zmieniają Państwo runs-on na craci, a 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. Każde zadanie i każdy cache otrzymuje stan kompletności: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.
Monitorowanie tego, co dostarczono
CRACI agreguje podatności z wielu buildów i repozytoriów oraz stale ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych biuletynów. Gdy się pojawi, widzą Państwo, które buildy i repozytoria faktycznie użyły podatnego pakietu, łącznie z pakietami niewymienionymi w żadnym manifeście, a zespoły bezpieczeństwa mogą wykonać triage znaleziska i przekazać je zespołowi odpowiedzialnemu za poprawkę. Wyzwalaczem jest podatność w czymś, czego build faktycznie użył, a nie pojawienie się nowej wersji.
Więcej niż monitorowanie
Ponieważ CRACI jest runnerem, egzekwuje też politykę ruchu wychodzącego dla każdego zadania (domyślna odmowa lub zezwolenie, walidacja przed uruchomieniem zadania, blokowanie w razie błędu), zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu przez swoje API oraz eksportuje SBOM-y w formacie CycloneDX lub SPDX. Nic z tego nie należy do zadań Renovate.
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 pojawi się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast odtwarzać to z informacji o wydaniach i arkuszy kalkulacyjnych.
Korzystanie z obu
- Renovate utrzymuje aktualność każdej zależności według harmonogramu, na wszystkich Państwa platformach i w menedżerach pakietów, z automerge dla aktualizacji niskiego ryzyka.
- CRACI rejestruje każdy build GitHub Actions, monitoruje to, co dostarczono, i wskazuje, których buildów i zespołów dotyczy nowa podatność, dzięki czemu wiedzą Państwo, które pull requesty z aktualizacjami scalić najpierw.
Nie ma czego migrować. Renovate nadal czyta Państwa repozytoria, a Państwa workflow nadal działają w GitHub Actions, tylko na innym runnerze.
Na potrzeby Cyber Resilience Act
CRA oczekuje, że producenci będą wiedzieć, co zawiera każde wydanie, i obsługiwać jego podatności. Renovate pomaga, utrzymując zależności załatane i aktualne. CRACI rejestruje SBOM każdego buildu, monitoruje go pod kątem nowych podatności i przechowuje dowody. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA. Zob. czym jest CRA oraz śledzenie podatności.
Co naprawdę pobrały Państwa buildy?
Proszę umówić demo, a uruchomimy jeden z Państwa workflow GitHub Actions na CRACI i omówimy jego zapis buildu oraz znalezione w nim podatności.
Umów demo