CRACI vs Syft a Grype

Stručná odpověď

Syft je oblíbený open source generátor SBOM a Grype je k němu doprovodný skener zranitelností. Společně zdarma pokrývají generování i párování, v libovolné pipeline. CRACI je runner pro GitHub Actions, který zaznamenává, co stáhl každý build, uvádí, zda je tento záznam úplný, kontroluje, kam se build může připojit, a průběžně monitoruje to, co bylo dodáno. Rozdíl v jedné větě: Syft rekonstruuje SBOM ze souborů a to, kolik najde, závisí na jeho konfiguraci a na tom, co je na disku v okamžiku spuštění. CRACI ji pozoruje a sleduje zranitelnosti v tom, co zaznamenal, takže jeden produkt odvede práci obou.

Co Syft a Grype dělají dobře

Syft je „nástroj CLI a knihovna pro Go pro generování softwarového kusovníku (SBOM) z image kontejnerů a souborových systémů“. Rozpozná desítky balíčkovacích systémů, od Alpine, Debianu a RPM po Go, Python, Javu, JavaScript, Ruby, Rust, PHP a .NET. Zapisuje CycloneDX, SPDX a vlastní Syft JSON, převádí mezi formáty a dokáže vytvářet podepsané atestace SBOM podle specifikace in-toto.

Grype skenuje image kontejnerů, souborové systémy a SBOM na známé zranitelnosti. Nálezy prioritizuje pomocí EPSS, KEV a hodnocení rizik, podporuje OpenVEX pro filtrování výsledků a jeho přepínač --fail-on nechá pipeline selhat, když najde zranitelnosti od zvolené závažnosti výše. Anchore uvádí, že Grype „běží zcela lokálně a neodesílá žádná data externím službám“, kromě stahování své databáze.

Oba nástroje jsou pod licencí Apache-2.0 a sponzoruje je Anchore, jejíž komerční platforma Anchore Enterprise „staví na open source Syft a Grype“. Tato stránka se týká open source nástrojů.

Syft je silný, když má před sebou správné soubory. Namířený na zdrojový strom, který má své závislosti v repozitáři, například ollama/ollama, je jeho výchozí sken vyřeší včetně verzí, package URL a vazeb mezi nimi.

Jeden přepínač změní odpověď

Syft volí své katalogizátory podle typu skenu a jeho dokumentace vysvětluje proč: „soubory, které naznačují záměr software nainstalovat, neobsahují dost informací k určení přesné verze“. Katalogizátory nesou tagy jako declared, installed, image a directory a přepínače jako --select-catalogers a --override-default-catalogers jejich sadu mění.

Ve výpisu syft cataloger list ve verzi v1.51.1 je katalogizátor JavaScriptu, který čte node_modules, označen pro skeny image a nainstalovaného softwaru a ve výchozí sadě pro sken adresáře není. Na nainstalovaném checkoutu tak jeden přepínač rozhoduje, zda se balíčky npm v node_modules vůbec přečtou. Stejný nástroj, stejná verze, stejný strom.

Stejně důležitá je i opačná strana. Žádná jednotlivá konfigurace není správná všude:

• Na čistém checkoutu express 5.2.1, který nemá lockfile, nemá výchozí sken žádné závislosti npm k vyřešení a vrátí to ostatní, co rozpozná, například GitHub Actions a soubory workflow.
• Když zapnete katalogizátory pro nainstalovaný software a namíříte je na zdrojové stromy tak, jak jsou v repozitáři, kde ještě nic nainstalováno není, nemají téměř co číst.
• Repozitář úplně bez manifestu závislostí nedá skenu žádné soubory závislostí ke čtení, ať je konfigurace jakákoli.

Nic z toho není chyba. Syft hlásí to, co soubory před ním podporují, tak jak byl navržen. Praktický důsledek je, že SBOM závisí na dvou rozhodnutích, která musí někdo udělat správně v každé pipeline: které katalogizátory běží a zda byly závislosti nainstalovány před skenem. A Grype dokáže spárovat jen to, co Syft vypsal. Komponenta, která v SBOM chybí, se k vyhledání zranitelností nikdy nedostane, takže sken pro ni vyjde čistý.

V čem je CRACI jiný

CRACI nemá žádné katalogizátory k výběru, protože strom dodatečně nečte. Změníte runs-on na craci a proxy, která rozumí balíčkům, zaznamená, co job stahuje ze zdrojů npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk a Git, a navíc z předvoleb pro stahování. Balíčky obnovené z cache CI si své důkazy nesou dál. Výsledek ve formátu CycloneDX nebo SPDX obsahuje tranzitivní závislosti, které build skutečně použil.

• Úplnost je explicitní. Každý job a každá cache jsou označeny jako Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded.
• Build je pod kontrolou. Egress policy (výchozí zákaz nebo povolení, 24 vestavěných předvoleb softwarových zdrojů) se ověří před spuštěním jobu a při selhání vše zablokuje (fail-closed).
• Údaje o původu. API vrací SBOM, síťové záznamy a údaje o původu. CRACI původ nepodepisuje; atestace ze Syftu podepisuje SBOM.
• Monitorování. Monitorované SBOM se průběžně znovu vyhodnocují a nálezy se agregují napříč buildy a repozitáři.

Grype stále umí věci, které CRACI neumí. Filtrování pomocí VEX a skenování image, které jste nesestavili, jsou doménou Grype. Policy gates v CRACI mohou nechat build selhat; upozornění při překročení prahů jsou v plánu vývoje.

Inventář toho, co je kde nasazeno

Pohled inventáře v CRACI přesně ukazuje, které verze softwaru jsou nasazeny ve kterých produktech, globálně. Když se objeví nová zranitelnost, vidíte, které produkty používají dotčenou verzi, místo abyste to skládali z poznámek k vydání a tabulek.

Přechod ze Syft a Grype

Na CRACI není třeba generovat SBOM ani udržovat krok skenování. Runner zaznamená SBOM během běhu buildu a CRACI ji i po dokončení buildu dál kontroluje na nové zranitelnosti. Syft a Grype zůstávají nástroji pro image a software třetích stran, který jste nesestavili, a pro pipeline mimo GitHub Actions.

Pro Cyber Resilience Act

CRA požaduje, aby výrobci dokumentovali komponenty každého produktu, včetně SBOM, a řešili v nich zranitelnosti. Syft a Grype umí takovou SBOM vytvořit a zkontrolovat, ale stopu důkazů od každého vydání zpět k jeho SBOM si musíte vybudovat sami. CRACI zaznamenává SBOM pro každý build a exportuje ji jako CycloneDX nebo SPDX. Automatizuje významnou část přehledu o softwarovém dodavatelském řetězci a důkazů, které firmy potřebují pro svůj širší proces dosažení souladu s CRA. Viz co je CRA a generování SBOM během buildu.