O 123% więcej zgłoszonych CVE dziennie w 2026 niż przed rokiem.

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

Strona główna Renovate
mend.io

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, packageRules do 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