CRACI vs Syft i Grype

Krótka odpowiedź

Syft to popularny generator SBOM open source, a Grype to towarzyszący mu skaner podatności. Razem bezpłatnie obejmują generowanie i dopasowanie, w dowolnym pipeline. CRACI to runner GitHub Actions, który rejestruje, co pobrał każdy build, określa, czy ten zapis jest kompletny, kontroluje, z czym build może się łączyć, i nadal monitoruje to, co dostarczono. Różnica w jednym zdaniu: Syft odtwarza SBOM z plików, a to, ile znajdzie, zależy od jego konfiguracji i od tego, co jest na dysku w chwili uruchomienia. CRACI go obserwuje i śledzi podatności w tym, co zarejestrował, więc jeden produkt wykonuje pracę obu.

Co Syft i Grype robią dobrze

Syft to "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Rozpoznaje dziesiątki systemów pakietów, od Alpine, Debian i RPM po Go, Python, Java, JavaScript, Ruby, Rust, PHP i .NET. Zapisuje CycloneDX, SPDX i własny format Syft JSON, konwertuje między formatami i może tworzyć podpisane atestacje SBOM zgodnie ze specyfikacją in-toto.

Grype skanuje obrazy kontenerów, systemy plików i SBOM-y pod kątem znanych podatności. Priorytetyzuje znaleziska za pomocą EPSS, KEV i oceny ryzyka, obsługuje OpenVEX do filtrowania wyników, a jego flaga --fail-on przerywa pipeline, gdy znajdzie podatności o wybranej ważności lub wyższej. Anchore zaznacza, że Grype "runs entirely locally and doesn't send any data to external services," poza pobieraniem swojej bazy danych.

Oba są na licencji Apache-2.0 i są sponsorowane przez Anchore, której komercyjna platforma Anchore Enterprise "builds on open source Syft and Grype." Ta strona dotyczy narzędzi open source.

Syft jest mocny, gdy ma przed sobą właściwe pliki. Skierowany na drzewo źródeł, które zawiera swoje zależności, takie jak ollama/ollama, w domyślnym skanie ustala je wraz z wersjami, adresami URL pakietów i powiązaniami między zależnościami.

Jedna flaga zmienia odpowiedź

Syft wybiera katalogery według typu skanu, a jego dokumentacja wyjaśnia dlaczego: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Katalogery mają tagi takie jak declared, installed, image i directory, a flagi takie jak --select-catalogers i --override-default-catalogers zmieniają ich zestaw.

W syft cataloger list w wersji v1.51.1 kataloger JavaScript, który odczytuje node_modules, ma tagi dla skanów obrazów i instalacji i nie należy do domyślnego zestawu dla skanu katalogu. Zatem na checkoucie z zainstalowanymi zależnościami jedna flaga decyduje o tym, czy pakiety npm w node_modules w ogóle zostaną odczytane. To samo narzędzie, ta sama wersja, to samo drzewo.

Druga strona medalu jest równie ważna. Żadna pojedyncza konfiguracja nie jest dobra wszędzie:

• Na czystym checkoucie express 5.2.1, który nie ma lockfile, domyślny skan nie ma zależności npm do ustalenia i zwraca tylko to, co jeszcze rozpozna, na przykład GitHub Actions i pliki workflow.
• Po włączeniu katalogerów instalacji i skierowaniu ich na drzewa źródeł w stanie z commita, gdzie nic jeszcze nie zainstalowano, nie mają prawie czego odczytać.
• Repozytorium bez żadnego manifestu zależności nie daje skanowi żadnych plików zależności do odczytania, niezależnie od konfiguracji.

Nic z tego nie jest błędem. Syft zgłasza to, na co pozwalają pliki przed nim, zgodnie z założeniami. Praktyczna konsekwencja jest taka, że SBOM zależy od dwóch decyzji, które ktoś musi podjąć prawidłowo w każdym pipeline: które katalogery działają i czy zależności zainstalowano przed skanem. A Grype może dopasować tylko to, co wymienił Syft. Komponent nieobecny w SBOM nigdy nie trafia do wyszukiwania podatności, więc skan wypada dla niego czysto.

Czym różni się CRACI

W CRACI nie ma katalogerów do wyboru, ponieważ nie odczytuje on drzewa po fakcie. Wystarczy zmienić runs-on na craci, a proxy rozpoznające pakiety rejestruje to, co zadanie pobiera ze źródeł npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i Git, a także z presetów pobierania. Pakiety przywrócone z cache CI zachowują swoje dowody. Wynik, w formacie CycloneDX lub SPDX, obejmuje zależności przechodnie, których build faktycznie użył.

• Kompletność jest jawna. Każde zadanie i każdy cache ma oznaczenie Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.
• Build jest kontrolowany. Polityka ruchu wychodzącego (domyślna odmowa lub zezwolenie, 24 wbudowane presety źródeł oprogramowania) jest weryfikowana przed startem zadania i w razie awarii blokuje ruch.
• Dane o pochodzeniu. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu; atestacja Syft podpisuje SBOM.
• Monitorowanie. Monitorowane SBOM-y są stale ponownie oceniane, a znaleziska są agregowane z wielu buildów i repozytoriów.

Grype wciąż robi rzeczy, których CRACI nie robi. Filtrowanie VEX i skanowanie obrazów, których Państwo nie zbudowali, to domena Grype. Bramki polityk CRACI mogą przerwać build; alerty progowe 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.

Przejście z Syft i Grype

W CRACI nie trzeba generować SBOM ani utrzymywać kroku skanu. Runner rejestruje SBOM w trakcie buildu, a CRACI nadal sprawdza go pod kątem nowych podatności po zakończeniu buildu. Syft i Grype pozostają narzędziami do obrazów i zewnętrznego oprogramowania, których Państwo nie zbudowali, oraz do pipeline'ów poza GitHub Actions.

Cyber Resilience Act

CRA oczekuje, że producenci będą dokumentować komponenty każdego produktu, w tym w postaci SBOM, oraz obsługiwać jego podatności. Syft i Grype mogą wytworzyć i sprawdzić taki SBOM, a ścieżkę dowodową od każdego wydania do jego SBOM trzeba zbudować samodzielnie. CRACI rejestruje SBOM dla każdego buildu i eksportuje go w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów, których firmy potrzebują w szerszym procesie zgodności z CRA. Zob. czym jest CRA oraz generowanie SBOM w czasie buildu.