CRACI vs Apiiro

Krótka odpowiedź

Apiiro to platforma do zarządzania stanem bezpieczeństwa aplikacji (ASPM). Jej Deep Code Analysis mapuje architekturę oprogramowania od kodu po środowisko uruchomieniowe, a Risk Graph koreluje znaleziska z własnych skanerów Apiiro i z narzędzi zewnętrznych. Moduł bezpieczeństwa łańcucha dostaw oprogramowania (SSCS) tworzy inwentarz repozytoriów i pipeline'ów oraz sygnalizuje ryzyka, takie jak słaba ochrona gałęzi, błędna konfiguracja pipeline'ów i nietypowe commity.

CRACI konkuruje o ten sam budżet na „zabezpieczenie łańcucha dostaw oprogramowania” z innej pozycji: uruchamia Państwa zadania GitHub Actions. Apiiro analizuje, co według kodu i konfiguracji pipeline'ów się wydarzy. CRACI rejestruje, co build faktycznie zrobił, kontroluje jego ruch wychodzący i stale obserwuje to, co Państwo wydali. Duży program AppSec może korzystać z obu. Zespół, który przede wszystkim potrzebuje dowodów na to, co trafiło do każdego wydania, może zacząć od CRACI.

W skrócie

Co Apiiro robi dobrze

• Kontekst architektury bez zmian w CI. Apiiro łączy się z systemem zarządzania kodem źródłowym przez integrację API i według dostawcy nie wymaga konfiguracji ani utrzymania CI/CD. Deep Code Analysis mapuje następnie API, dane wrażliwe, frameworki GenAI i własność kodu, z odświeżaniem przy każdym commicie i istotnej zmianie.
• Bezpieczeństwo kodowania z AI. Guardian Agent, wprowadzony w styczniu 2026, współpracuje z asystentami kodowania AI i dodaje do promptów programistów wytyczne bezpieczeństwa z Państwa modeli zagrożeń, polityk zgodności i architektury, dzięki czemu asystent jest odciągany od podatnego kodu, zanim go napisze. W marcu 2026 dołączyło AI Threat Modeling.
• Zakres. Apiiro wymienia natywne AI SAST, AI SCA, SSCS, sekrety, infrastrukturę jako kod, bezpieczeństwo API w kodzie, DSPM dla kodu i modelowanie zagrożeń z AI. CRACI nie wykonuje żadnego ze skanowań kodu z tej listy.
• Priorytetyzacja. Risk Graph pobiera, deduplikuje i koreluje znaleziska, a następnie łączy je w „toksyczne kombinacje”. Przykład Apiiro: repozytorium przechowujące dane osobowe, budowane przez podatny pipeline, otrzymujące commity do gałęzi bez wymaganych recenzentów. Trzy średnie znaleziska stają się jednym krytycznym ryzykiem.
• Inwentarz fabryki oprogramowania. SSCS tworzy inwentarz repozytoriów i pipeline'ów CI/CD, w tym ukrytych pipeline'ów, z kontrybutorami, uprawnieniami, wtyczkami i zależnościami. Śledzi podatności zależności pipeline'ów przez cały ich cykl życia, a zabezpieczenia mogą blokować ryzykowne commity i scalenia.
• Analiza zależności i poprawki. AI SCA sprawdza, czy podatna funkcja jest faktycznie wywoływana, dopasowuje zależności do wdrożonych kontenerów i publicznych endpointów, wykrywa złośliwe pakiety i egzekwuje politykę licencyjną. AutoFix dostarcza podbicia wersji, które według Apiiro są wstępnie sprawdzone pod kątem zgodności API.
• Integracje. GitHub, GitLab, Azure DevOps, Bitbucket i Perforce po stronie kontroli wersji, Jenkins i GitHub Actions dla konfiguracji pipeline'ów oraz długa lista skanerów, rejestrów i narzędzi do zgłoszeń.

Czym różni się CRACI

Build jest źródłem prawdy

XBOM w Apiiro powstaje przez analizę kodu: każdy pakiet, API, model AI i licencja, odświeżane przy każdej zmianie kodu. To mocny obraz tego, co Państwa kod deklaruje i czego używa. Build często robi jednak więcej, niż mówi kod. Uruchamia skrypty instalacyjne, pobiera toolchainy, przywraca cache, pobiera obrazy bazowe i pliki binarne wydań.

CRACI widzi tę aktywność, ponieważ jest runnerem. Proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów w trakcie zadania, obejmując npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródła Git, a także presety pobierania. Dowody zależności są przenoszone razem z cache CI, więc pakiet przywrócony z cache nadal jest uwzględniany. Każdy SBOM ma stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Wiedzą Państwo, kiedy zapis ma lukę.

Kontrola na runnerze, nie tylko ocena konfiguracji

Apiiro informuje, gdy pipeline jest źle skonfigurowany lub podatny na manipulację. CRACI ogranicza, dokąd build może się połączyć w trakcie działania. 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. Są weryfikowane przed startem zadania i w razie błędu blokują ruch, a CRACI może powiadomić Państwa o naruszeniu.

Dowody z buildu przez API

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Po wydaniu

CRACI stale ponownie ocenia SBOM-y wydanego oprogramowania w miarę publikowania nowych podatności i agreguje znaleziska z wielu buildów i repozytoriów.

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.

Gdzie Apiiro jest przed CRACI

Mówiąc wprost: CRACI nie ma skanowania SAST, sekretów, IaC ani bezpieczeństwa API, nie pobiera znalezisk innych skanerów, nie audytuje ochrony gałęzi ani uprawnień repozytoriów i obsługuje dziś wyłącznie GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. CRACI blokuje natomiast buildy za pomocą bramek polityk i egzekwuje politykę licencyjną. Jeśli potrzebują Państwo jednej platformy, która priorytetyzuje ryzyko w całym kodzie, Apiiro obejmuje znacznie szerszy obszar.

Które rozwiązanie wybrać

Apiiro sprawdzi się lepiej, gdy

• Chcą Państwo jednej platformy ASPM obejmującej wiele skanerów, repozytoriów i systemów SCM.
• Priorytetem jest kontekst architektury: który kod jest wystawiony do internetu, przetwarza dane osobowe lub istotnie się zmienił.
• Potrzebują Państwo oceny konfiguracji repozytoriów i pipeline'ów w GitLab, Azure DevOps, Bitbucket lub Jenkins.

CRACI sprawdzi się lepiej, gdy

• Budują Państwo na GitHub Actions i chcą mieć runner, politykę ruchu wychodzącego i zapis zależności w jednym miejscu.
• Potrzebują Państwo SBOM tego, co pobrał każdy build, ze stanem kompletności, który można pokazać audytorowi.
• Chcą Państwo monitorowania tego, co wydano, i dowodów dla CRA.

Korzystanie z obu

Apiiro określa dziś swoją rolę jako zabezpieczanie rozwoju agentowego. Jego Guardian Agent kieruje asystentów kodowania AI ku bezpiecznemu kodowi, zanim kod powstanie, a XBOM pochodzi z analizy kodu w Państwa repozytoriach. CRACI to CI/CD z bezpieczeństwem wbudowanym w runner, więc jego SBOM rejestruje, co każdy build faktycznie pobrał, w tym to, czego analiza kodu nie widzi: skrypty instalacyjne, toolchainy, pakiety z cache i obrazy bazowe. Apiiro działa tam, gdzie kod jest pisany, CRACI tam, gdzie jest budowany i wydawany. CRACI zastępuje runner, a nie GitHub Actions, więc każda integracja Apiiro z pipeline'ami nadal działa.

Cyber Resilience Act

Cyber Resilience Act wymaga od producentów znajomości komponentów każdego produktu, obsługi ich podatności i przechowywania dowodów. Platforma ASPM pomaga w bezpiecznym wytwarzaniu oprogramowania i w obsłudze podatności w Państwa kodzie. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA: SBOM-y z czasu buildu, śledzenie podatności, pochodzenie i eksport SBOM w formatach CycloneDX lub SPDX. Żadne z tych narzędzi samo w sobie nie zapewnia zgodności. Zob. zgodność z CRA.

Dodanie CRACI

Wystarczy zainstalować aplikację CRACI GitHub App w organizacji, a następnie zmienić etykietę runnera w zadaniu na runs-on: craci. Uruchomienia nadal widać w interfejsie GitHub. Proszę zacząć od jednego workflow, który tworzy artefakt wydania, i porównać SBOM z CRACI z obecnym inwentarzem. Więcej o integracji CI/CD, generowaniu SBOM w czasie buildu i cenach.