CRACI vs Anchore

Krótka odpowiedź

Anchore Enterprise to platforma SBOM do ciągłego zapewniania bezpieczeństwa i zgodności. Opiera się na narzędziach open source Anchore, Syft i Grype, skanuje obrazy kontenerów, systemy plików i importowane SBOM-y oraz egzekwuje pakiety polityk dla standardów takich jak FedRAMP i NIST. CRACI to runner GitHub Actions, który rejestruje zależności faktycznie pobrane przez każde zadanie i na tej podstawie tworzy SBOM ze stanem kompletności.

Różnica polega na tym, skąd pochodzi lista komponentów: ze skanu tego, co jest obecne, czy z zapisu tego, co zrobił build. CRACI monitoruje też ten zapis pod kątem nowych podatności, więc CI, SBOM i śledzenie podatności pochodzą z jednego produktu zamiast z runnera i osobnej platformy skanującej.

W skrócie

Co Anchore robi dobrze

Warto zacząć od narzędzi open source, ponieważ są oddzielone od produktu komercyjnego. Syft to CLI i biblioteka Go, która generuje SBOM-y z obrazów kontenerów i systemów plików, na licencji Apache 2.0. Grype to skaner podatności open source dla obrazów i systemów plików. Wiele zespołów już bezpłatnie korzysta z jednego lub obu.

Anchore Enterprise „opiera się na open source'owych Syft i Grype” i dodaje to, czego potrzebują wokół nich duże organizacje:

• Szerokie pokrycie. SBOM-y kontenerów, kodu źródłowego i systemów plików oraz SBOM-y utworzone poza platformą. Przesłane SBOM-y są przed analizą sprawdzane pod kątem poprawności schematu. Wersja 6 dodała maszyny wirtualne i zdalne systemy plików.
• Ciągłe skanowanie. Zapisane SBOM-y są ponownie skanowane pod kątem podatności bez oryginalnego artefaktu, a platforma wyszukuje też sekrety i złośliwe oprogramowanie.
• Polityki jako kod. Bramki polityk z gotowymi pakietami, m.in. dla FedRAMP, NIST, CIS, PCI DSS i CMMC.
• Państwa infrastruktura. Helm na EKS, AKS, GKE lub OpenShift, Docker Compose, obrazy chmurowe i instalacje air-gapped.
• Wiele systemów CI. Udokumentowane integracje z GitHub, GitLab, Jenkins, AWS CodeBuild i Azure Pipelines.

Jeśli zarządzają Państwo flotami kontenerów w kilku systemach CI lub pracują w środowisku rządowym albo air-gapped, to realne zalety, którym CRACI dziś nie dorównuje.

Czym różni się CRACI

Zapis buildu, a nie skan wyniku

W integracji Anchore z GitHub Actions anchorectl tworzy SBOM na Państwa runnerze albo analizatory Anchore tworzą go na serwerze. W obu przypadkach SBOM opisuje to, co skaner znajduje w obrazie lub katalogu. Skanowanie gotowego obrazu to dobra praktyka. Widzi to, co trafiło do artefaktu. Nie widzi tego, co zadanie pobrało po drodze i pozostawiło, na przykład wtyczek buildu, narzędzi testowych i pakietów przywróconych z cache.

CRACI uruchamia zadanie. Wystarczy zmienić runs-on na craci, a proxy rozpoznające pakiety rejestruje ruch do źródeł pakietów w trakcie buildu: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presety pobierania. Dowody zależności są przenoszone razem z cache CI, więc przywrócony pakiet pozostaje w zapisie.

Dlaczego metoda ma znaczenie

Skaner może zgłosić tylko to, co deklarują dostępne mu pliki, a jego wynik zależy od ustawień. Syft dobiera katalogery według typu skanu, więc ta sama wersja tego samego narzędzia może zwrócić bardzo różne listy z tego samego checkoutu w zależności od jednej flagi. Repozytorium, które nie zawiera lockfile, jak express 5.2.1, nie daje czytnikowi lockfile niczego do rozwiązania. Chodzi tu o skanowanie jako metodę, a nie o jakość Syft. CRACI nie da się porównać w ten sposób, ponieważ rejestruje buildy i nie potrafi skanować katalogu.

Stan kompletności każdego SBOM

Każdy SBOM w CRACI ma stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Stan jest przechodni między cache. Wiedzą Państwo, czy każdy SBOM jest pełnym zapisem, czy ma lukę.

Kontrola i pochodzenie u źródła

Ponieważ CRACI uruchamia zadanie, może egzekwować politykę sieciowego ruchu wychodzącego: domyślna odmowa lub domyślne zezwolenie, 24 wbudowane presety źródeł oprogramowania i typowane źródła niestandardowe. Polityki są weryfikowane przed startem zadania, a w razie błędu blokują ruch. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Monitorowanie

CRACI na bieżąco ponownie ocenia monitorowane SBOM-y i agreguje podatności z wielu buildów i repozytoriów. Zespoły bezpieczeństwa mogą przeprowadzać triaż znalezisk i przekazywać je właściwemu zespołowi. Bramki polityk blokują build na podstawie znalezisk.

Inwentarz tego, co gdzie jest wdrożone

Widok inwentarza w CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, globalnie. Gdy pojawia się nowa podatność, widzą Państwo, które produkty korzystają z podatnej wersji, zamiast składać tę wiedzę z informacji o wydaniach i arkuszy kalkulacyjnych.

Zastąpienie Anchore przez CRACI

Dla zespołów korzystających z GitHub Actions CRACI przejmuje rolę, jaką Anchore Enterprise pełni w zakresie SBOM: tworzy SBOM w trakcie buildu, stale ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności, agreguje znaleziska z wielu buildów i repozytoriów oraz pozwala zespołom bezpieczeństwa przeprowadzać ich triaż i przekazywać każde z nich zespołowi odpowiedzialnemu za poprawkę. Nie ma platformy skanującej do utrzymania ani kroku przesyłania do konserwacji.

Warto jasno określić, z czego Państwo rezygnują. Anchore Enterprise skanuje obrazy kontenerów i systemy plików, także te, których Państwo nie zbudowali, oraz wyszukuje sekrety i złośliwe oprogramowanie. Jego pakiety polityk dla FedRAMP, NIST i podobnych standardów nie mają dziś odpowiednika w CRACI, choć własne bramki polityk CRACI blokują buildy i egzekwują politykę licencyjną. Anchore Enterprise można też hostować samodzielnie, również w sieciach air-gapped, a produkt integruje się z GitLab, Jenkins oraz innymi systemami CI. Jeśli to jest ważniejsze niż zapis tego, z czego zbudowano każde wydanie, Anchore będzie lepszym wyborem.

Cyber Resilience Act

Anchore publikuje materiały o CRA, w tym stronę o EU CRA i przewodnik po wymaganiach dotyczących SBOM. Pozycjonuje Anchore Enterprise pod kątem zarządzania SBOM, monitorowania podatności na podstawie źródeł obejmujących CISA KEV, wsparcia 24-godzinnego okna wczesnego ostrzeżenia i 72-godzinnego okna powiadomienia, bramek polityk, adnotacji VEX i ścieżek audytu.

Obowiązki zgłoszeniowe CRA obowiązują od 11 września 2026: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o aktywnie wykorzystywanej podatności, za pośrednictwem CRA Single Reporting Platform. Główne przepisy obowiązują od 11 grudnia 2027. Zgłoszenie w ciągu 24 godzin wymaga wiedzy, które wydania zawierają podatny komponent. API CRACI zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu, a SBOM-y eksportuje się w formatach CycloneDX lub SPDX, łącznie z podatnościami.

CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA. Żaden z tych produktów sam w sobie nie zapewnia producentowi zgodności. Zob. czego wymaga CRA oraz zgodność z CRA dzięki CRACI.

CRACI i Anchore: najczęściej zadawane pytania

Syft i Grype, self-hosting, obsługa CI i ceny

Czy CRACI jest alternatywą dla Anchore?

Tak, dla zespołów korzystających z GitHub Actions. CRACI tworzy SBOM w trakcie buildu, stale ponownie ocenia monitorowane SBOM-y w miarę publikowania nowych podatności i pozwala zespołom bezpieczeństwa przeprowadzać triaż znalezisk oraz przekazywać je zespołowi odpowiedzialnemu za poprawkę, bez platformy skanującej do utrzymania. Anchore lepiej się sprawdzi, jeśli muszą Państwo skanować obrazy, których sami nie zbudowali, hostować rozwiązanie samodzielnie lub korzystać z kilku systemów CI.

Czym CRACI różni się od Syft i Grype?

Syft i Grype to bezpłatne narzędzia open source od Anchore: Syft generuje SBOM-y z obrazów kontenerów i systemów plików, a Grype skanuje je pod kątem podatności. Oba odczytują to, co znajduje się w dostępnych im plikach. CRACI uruchamia build i rejestruje pakiety, które zadanie faktycznie pobrało, w tym pakiety przywrócone z cache CI, więc w przypadku budowanego przez Państwa oprogramowania zastępuje oba narzędzia.

Co robi Anchore Enterprise, czego nie robi CRACI?

Anchore Enterprise skanuje obrazy kontenerów i systemy plików, także te, których Państwo nie zbudowali, oraz wyszukuje sekrety i złośliwe oprogramowanie. Zawiera pakiety polityk dla FedRAMP, NIST, CIS, PCI DSS i CMMC, które dziś nie mają odpowiednika w CRACI, choć własne bramki polityk CRACI mogą zablokować build na podstawie znalezisk. Anchore Enterprise można też hostować samodzielnie, również w sieciach air-gapped.

Czy CRACI może działać w trybie self-hosted lub air-gapped?

Obecnie nie. CRACI oferuje zarządzane runnery na europejskiej infrastrukturze, a runnery hostowane u klienta są w planach rozwoju dla Enterprise. Anchore Enterprise instaluje się za pomocą Helm na Kubernetes, przez Docker Compose lub w sieciach air-gapped.

Jakie systemy CI obsługują Anchore i CRACI?

Anchore dokumentuje integracje z GitHub, GitLab, Jenkins, AWS CodeBuild i Azure Pipelines. CRACI jest dziś runnerem dla GitHub Actions; inne systemy CI, w tym GitLab CI i Jenkins, są w planach rozwoju.

Jak wypada porównanie cen?

Według stanu na wrzesień 2026 cena Anchore Enterprise jest ustalana na zapytanie. CRACI pobiera opłaty wyłącznie 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 Anchore i CRACI obsługują VEX i Cyber Resilience Act?

Anchore pozycjonuje Anchore Enterprise pod kątem CRA, oferując zarządzanie SBOM, monitorowanie podatności, bramki polityk, adnotacje VEX i ścieżki audytu. CRACI również obsługuje VEX. Rejestruje, z czego zbudowano każde wydanie, stale śledzi jego podatności i składa w Państwa imieniu powiadomienia o podatnościach wymagane przez CRA, automatyzując znaczną część dowodów potrzebnych w Państwa procesie CRA. Proszę umówić demo, aby porównać zarejestrowany SBOM z tym, który tworzy obecny skan.