CRACI vs Dependency-Track

V čem je Dependency-Track dobrý

OWASP Dependency-Track je silnou volbou pro analýzu komponent. Je open source pod licencí Apache 2.0, sleduje použití komponent napříč všemi verzemi všech aplikací ve vašem portfoliu a čerpá informace o zranitelnostech z několika zdrojů, mimo jiné z National Vulnerability Database a GitHub Advisories. Jeho engine politik pokrývá bezpečnostní, licenční i provozní pravidla a přijímá i vytváří dokumenty CycloneDX VEX. Návrh postavený na API dobře zapadá do CI/CD: pipeline nahrávají SBOM na /api/v1/bom.

Týmy v regulovaných odvětvích ho mají rády, protože je transparentní, self-hosted a postavený na standardním formátu. Jeho slabinou není analýza, ale to, co do ní vstupuje.

Analýza závisí na svém vstupu

Dependency-Track SBOM přijímá, ale negeneruje. Každý nález, porušení politiky i pohled na portfolio závisí na SBOM, které vaše pipeline odešle. Pokud SBOM nějakou závislost vynechá, Dependency-Track ji nemůže označit. Pokud se dva generátory neshodnou, Dependency-Track ukáže ten, který jste nahráli.

V praxi se generátory SBOM rozcházejí často a důvody najdete v jejich vlastní dokumentaci:

• Žádný společný základ. Každý generátor si sám určuje, co se počítá jako komponenta a kterým souborům věřit, takže dva generátory nasměrované na stejný repozitář vrátí překrývající se, ale odlišné seznamy.
• Přehlédnou i to zjevné. Nástroj, který rozlišuje závislosti z lockfilů, nemá co rozlišovat v repozitáři, který žádný lockfile necommituje, jako je tomu u express 5.2.1. Přesto může vrátit seznam složený z čehokoli jiného, co rozpozná, například z GitHub Actions a souborů workflow.
• Výkyvy podle konfigurace. Syft volí své katalogizátory podle typu skenu, takže jediný přepínač změní, co stejný nástroj ve stejné verzi nahlásí ze stejného checkoutu.
• Bez manifestu žádný SBOM. Repozitář bez jakéhokoli manifestu závislostí nedává skeneru založenému na souborech nic, s čím by mohl pracovat, a to, co pak jednotlivé nástroje vrátí, vypovídá víc o nástroji než o projektu.
• Chudá metadata. Většina generátorů nemá zdroj pro pole dodavatele podle NTIA, takže zůstane prázdné, ať repozitář obsahuje cokoli.

CRACI takto porovnat nelze. Zaznamenává buildy, místo aby skenoval adresář, takže ho nelze spustit stejným způsobem. Nejde o to, že by některý z těchto nástrojů byl špatný. Jde o to, že statický sken repozitáře je jen odhad toho, co build použije, a ten odhad se liší podle nástroje, jeho nastavení a přítomných souborů.

Co CRACI mění u zdroje

SBOM pochází z buildu

CRACI je runner kompatibilní s GitHub Actions. Změníte runs-on na craci a vaše joby poběží na CRACI v izolovaných virtuálních strojích. Během každého jobu zaznamenává proxy, která rozumí balíčkům, provoz ke zdrojům balíčků: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk a zdrojům Git, plus předvolbám pro stahování. Důkazy o závislostech putují spolu s cache CI, takže balíček obnovený z cache v záznamu zůstává. SBOM ve formátu CycloneDX nebo SPDX obsahuje všechny tranzitivní závislosti, které build skutečně použil.

Řekne vám, když je neúplný

Každý SBOM od CRACI nese stav úplnosti pro každý job a každou cache: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded. Víte tak, zda je každý SBOM úplným záznamem, nebo má mezeru. To je důležité, když se auditor zeptá, jak víte, že je váš inventář úplný.

Zaznamenává SBOM uvnitř buildu

CRACI generuje SBOM uvnitř vlastního runneru z toho, co job stáhl. API vrací SBOM, síťové záznamy a údaje o původu (provenance).

Řídí, kam se build může připojit

Protože CRACI job spouští, může vynutit politiku odchozího provozu: výchozí zákaz nebo výchozí povolení, s 24 vestavěnými předvolbami softwarových zdrojů a typovanými vlastními zdroji. Politiky se ověří před spuštěním jobu a při selhání vše zablokují. Dependency-Track vám může dodatečně říct, že je komponenta riziková; politika odchozího provozu omezuje, ze kterých zdrojů mohl build vůbec stahovat.

Inventář toho, co je kde nasazeno

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

Nahrazení Dependency-Track platformou CRACI

CRACI pokrývá obě poloviny práce, na kterou jste dřív potřebovali generátor a Dependency-Track. Vytváří SBOM v buildu, průběžně znovu vyhodnocuje monitorované SBOM, jak se zveřejňují nové zranitelnosti, agreguje nálezy napříč buildy a repozitáři a umožňuje bezpečnostním týmům provést jejich triáž a předat každý z nich týmu, který odpovídá za opravu. Nemusíte udržovat žádný krok nahrávání ani provozovat žádný server.

Buďte si vědomi toho, čeho se vzdáváte. Engine politik v Dependency-Track je vyspělý. CRACI má kontrolní brány politik, které blokují buildy, a licenční politiku, zatímco komentáře a upozornění na prahové hodnoty jsou v plánu vývoje. Dependency-Track je navíc open source a self-hosted, zatímco CRACI je dnes spravovaná služba a runnery hostované zákazníkem jsou v plánu vývoje pro Enterprise. Pokud jsou pro vás tyto věci důležitější než kvalita inventáře, zůstaňte u Dependency-Track.

Proč na tom záleží v regulovaných odvětvích

Podle evropského Cyber Resilience Act musí výrobci vědět, co obsahuje každé vydání produktu, a řešit v něm zranitelnosti, přičemž povinnosti hlášení aktivně zneužívaných zranitelností platí od září 2026. Zranitelnost, kterou nevidíte, protože váš SBOM komponentu vynechal, je stále vaší zranitelností.

CRACI 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, a exportuje SBOM ve formátu CycloneDX nebo SPDX včetně zranitelností. Inventář i monitorování vycházejí ze stejného záznamu toho, z čeho bylo každé vydání sestaveno. Viz soulad s CRA, průmyslový IoT a telekomunikace.