CRACI vs Kusari

Krótka odpowiedź

Kusari to platforma bezpieczeństwa łańcucha dostaw oprogramowania stworzona przez zespół współtwórców GUAC, grafu open source dla metadanych łańcucha dostaw. Tworzy stale aktualizowany graf wiedzy z Państwa kodu źródłowego, SBOM-ów, dokumentów VEX i wyników obecnych skanerów, szereguje to, co można wykorzystać, przegląda pull requesty i otwiera poprawki. CRACI to runner GitHub Actions. Rejestruje, co każdy build pobiera podczas działania, kontroluje, do czego build może dotrzeć, i nadal monitoruje to, co dostarczono. Każdy graf odzwierciedla przekazane mu SBOM-y; CRACI tworzy SBOM-y z samego buildu. Oba produkty konkurują o ten sam budżet na łańcuch dostaw. Dla oprogramowania, które budują Państwo sami, CRACI obejmuje CI, SBOM i śledzenie podatności w jednym produkcie.

W skrócie

Kusari i GUAC: co jest czym

GUAC (Graph for Understanding Artifact Composition) to projekt inkubowany przez OpenSSF w ramach grupy roboczej Supply Chain Integrity, na licencji Apache 2.0. Agreguje metadane bezpieczeństwa oprogramowania w grafowej bazie danych. Jego udokumentowane dane wejściowe to m.in. SBOM-y CycloneDX i SPDX, atestacje in-toto i SLSA, dokumenty OpenVEX i CSAF, wyniki OpenSSF Scorecard oraz dane OSV i deps.dev. GUAC agreguje metadane tworzone przez inne narzędzia; nie uruchamia buildów.

Współzałożyciele Kusari współtworzyli GUAC z Google, a jeden ze współzałożycieli Kusari jest głównym opiekunem GUAC. Kusari podaje, że w swoich produktach komercyjnych używa projektów open source GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined i innych oraz się nimi opiekuje. GUAC ma też innych współtwórców, w tym Google, Red Hat, Purdue University i Citi. Kusari to platforma komercyjna; GUAC to projekt społeczności.

Co Kusari robi dobrze

Graf zbudowany na otwartych standardach. Platforma Kusari przyjmuje kod źródłowy, artefakty buildu, SBOM-y CycloneDX i SPDX, VEX oraz wyniki obecnych skanerów, w tym Snyk, Black Duck, Prisma Cloud, Dependabot i GitHub Advanced Security. Mapuje zależności bezpośrednie i przechodnie wraz z pochodzeniem i rodowodem oraz pokazuje zasięg skutków nowej podatności w całym Państwa środowisku.

Mniej, ale lepszych znalezisk. Analiza osiągalności i możliwości wykorzystania szuka dowodów na to, że podatny kod jest faktycznie wywoływany, więc w kolejce zostaje to, co ważne. AutoFix generuje pull requesty z poprawkami i weryfikuje je, zanim trafią do Państwa repozytorium.

Kontrole przy pull requeście. Kusari Inspector przegląda każdy pull request w GitHub lub GitLab pod kątem podatności przechodnich, wycieków sekretów, złośliwych pakietów i typosquattingu, ryzyka licencyjnego, zależności po zakończeniu wsparcia, niebezpiecznych workflow GitHub Actions i typowych słabości kodu. Kusari podaje, że instalacja Inspectora jest bezpłatna i nie wymaga rozmowy z działem sprzedaży.

Standardy i frameworki. Kusari tworzy SBOM-y i atestacje w formatach SPDX, CycloneDX i in-toto oraz wymienia obsługę frameworków, w tym unijnego CRA, FDA 524B, SSDF, IEC 62443 i DORA. Jego narzędzie do przesyłania działa w GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines i TeamCity.

Czym różni się CRACI

Kusari opisuje swój graf jako budowany z kodu źródłowego i systemów buildu w trakcie powstawania oprogramowania, a nie odtwarzany z gotowych plików binarnych. To właściwe podejście, a zarazem miejsce, w którym oba produkty się rozchodzą. SBOM-y Kusari pochodzą z generatora: dokumentacja opisuje ich generowanie przez waybill, zestaw narzędzi SBOM open source, przy scalaniu pull requestów lub użycie własnego narzędzia. Generator odczytuje lockfile, manifesty, cache i obrazy. CRACI nie odczytuje plików buildu, aby wywnioskować, czego użył. Jest maszyną, na której działa build.

Zapis, a nie rekonstrukcja

Po zmianie jednej linii w runs-on Państwa workflow działa na CRACI. Proxy rozpoznające pakiety rejestruje, co każde zadanie pobiera ze źródeł pakietów, a pakiety przywrócone z cache CI są przenoszone dalej. Każdy SBOM określa swoją kompletność dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Monitorowanie zaczyna od tego, co build faktycznie pobrał, i wie, gdzie są luki.

Kontrola w trakcie buildu

Graf pomaga ustalić po fakcie, czego coś dotyczy. Polityka ruchu wychodzącego na runnerze decyduje w trakcie zadania, do których hostów może ono dotrzeć. Polityki CRACI działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania, są walidowane przed startem zadania i w razie błędu blokują ruch.

Pochodzenie i monitorowanie z tego samego zapisu

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu. Nadal ponownie ocenia monitorowane SBOM-y.

CRACI nie robi tego, co wyróżnia Kusari: nie przyjmuje danych z innych skanerów, nie analizuje osiągalności ani nie przegląda pull requestów pod kątem złośliwych pakietów i słabości kodu. Obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju.

Inwentarz tego, co jest gdzie 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ść, widzą Państwo, które produkty działają na podatnej wersji, zamiast składać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Zastąpienie Kusari przez CRACI

Dla oprogramowania, które Państwo budują i dostarczają, CRACI obejmuje to, po co zwykle kupuje się platformę grafową. Uruchamia build, rejestruje SBOM z określoną kompletnością, nadal 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 wykonywać ich triage i przekazywać każde z nich zespołowi odpowiedzialnemu za poprawkę. Polityka ruchu wychodzącego z góry ogranicza, do czego build może dotrzeć, czego nie potrafi żaden graf.

Warto jasno określić, z czego Państwo rezygnują. Kusari łączy jeden graf z wielu skanerów i źródeł SBOM, przyjmuje VEX, analizuje osiągalność i przegląda pull requesty pod kątem złośliwych pakietów, wycieków sekretów i słabości kodu. CRACI nie robi dziś niczego z tego i obsługuje tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju. Jeśli główną potrzebą jest korelowanie znalezisk z wielu obecnych narzędzi, Kusari pozostaje lepszym wyborem.

Na potrzeby CRA

Cyber Resilience Act wymaga od producentów dokumentowania komponentów ich produktów, w tym przez SBOM, oraz obsługi podatności przez cały okres wsparcia produktu. Zgłaszanie aktywnie wykorzystywanych podatności obowiązuje od września 2026. Kusari łączy SBOM-y, VEX i znaleziska w jednym grafie i wymienia CRA wśród obsługiwanych frameworków. CRACI wytwarza dowody z każdego buildu i nadal je monitoruje: z czego zbudowano każde wydanie, wraz z danymi o pochodzeniu, bieżącym monitorowaniem i eksportem SBOM w formacie CycloneDX lub SPDX. CRACI automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmom w szerszym procesie zgodności z CRA; żadne z tych narzędzi samo nie zapewnia zgodności produktu. Zob. czego wymaga CRA.

Przejście na CRACI

Wystarczy ustawić runs-on: craci w workflow, które budują to, co Państwo dostarczają. CRACI zastępuje runner, a nie GitHub Actions, a uruchomienia nadal są widoczne w interfejsie GitHub. Więcej o generowaniu SBOM w czasie buildu i śledzeniu podatności.

Rozważają Państwo więcej niż dwa narzędzia? Alternatywy dla Kusari porównują obok siebie dziewięć opcji.