CRACI vs Dependency-Track

Vad Dependency-Track gör bra

OWASP Dependency-Track är ett starkt val för komponentanalys. Det är öppen källkod under licensen Apache 2.0, det spårar komponentanvändning över alla versioner av alla applikationer i din portfölj, och det hämtar sårbarhetsdata från flera källor, bland annat National Vulnerability Database och GitHub Advisories. Dess policymotor täcker regler för säkerhet, licenser och drift, och det läser och tar fram VEX-dokument i CycloneDX. Dess API-first-design passar CI/CD: pipelines laddar upp SBOM:er till /api/v1/bom.

Team i reglerade sektorer gillar det eftersom det är transparent, egenhostat och byggt kring ett standardformat. Dess svaga punkt är inte analysen. Det är vad som går in i den.

Analysen beror på indata

Dependency-Track läser SBOM:er; det genererar dem inte. Varje fynd, policyöverträdelse och portföljvy beror på SBOM:en som din pipeline skickar. Om SBOM:en missar ett beroende kan Dependency-Track inte flagga det. Om två generatorer är oense visar Dependency-Track den du råkade ladda upp.

I praktiken är SBOM-generatorer ofta oense, och skälen står i deras egen dokumentation:

• Ingen gemensam grund. Varje generator avgör själv vad som räknas som en komponent och vilka filer den ska lita på, så två av dem som riktas mot samma repo ger listor som överlappar men skiljer sig åt.
• Missar det uppenbara. Ett verktyg som löser beroenden från lockfiler har inget att lösa i ett repo utan committade lockfiler, som express 5.2.1. Det kan ändå returnera en lista, gjord av vad det annars känner igen, till exempel GitHub Actions och arbetsflödesfiler.
• Konfigurationen slår igenom. Syft väljer sina catalogers efter skanningstyp, så en enda flagga ändrar vad samma verktyg i samma version rapporterar från samma utcheckning.
• Inget manifest, ingen SBOM. Ett repo helt utan beroendemanifest ger en filbaserad skanner inget att arbeta med, och det varje verktyg då returnerar säger mer om verktyget än om projektet.
• Tunna metadata. De flesta generatorer har ingen källa för NTIA:s leverantörsfält, så det blir tomt oavsett vad repot innehåller.

CRACI kan inte jämföras på det sättet. Det registrerar byggen i stället för att skanna en katalog, så det kan inte köras på samma sätt. Poängen är inte att något av dessa verktyg är dåligt. Den är att en statisk skanning av ett repo är en uppskattning av vad ett bygge kommer att använda, och uppskattningen varierar med verktyget, dess inställningar och filerna som finns.

Vad CRACI ändrar vid källan

SBOM:en kommer från bygget

CRACI är en GitHub Actions-kompatibel runner. Du ändrar runs-on till craci, och dina jobb körs på CRACI i isolerade virtuella maskiner. Under varje jobb registrerar en paketmedveten proxy trafik till paketkällor: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar. Beroendebevisen följer med CI-cachar, så ett paket som återställs från en cache finns kvar i registreringen. SBOM:en, i CycloneDX eller SPDX, omfattar alla transitiva beroenden som bygget faktiskt använde.

Den talar om när den är ofullständig

Varje SBOM från CRACI har en fullständighetsstatus per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du vet om varje SBOM är en fullständig registrering eller har en lucka. Det spelar roll när en revisor frågar hur du vet att din inventering är komplett.

Den registrerar SBOM:en inne i bygget

CRACI genererar SBOM:en inne i sin egen runner, utifrån vad jobbet hämtade. API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Den styr vad bygget kan nå

Eftersom CRACI kör jobbet kan det upprätthålla en egress-policy för nätverket: neka eller tillåt som standard, med 24 inbyggda förinställningar för programvarukällor och typade anpassade källor. Policyer valideras innan jobbet startar och blockerar vid fel. Dependency-Track kan i efterhand tala om att en komponent är riskabel; en egress-policy begränsar vilka källor ett bygge över huvud taget kan hämta från.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp kan du se vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

Att ersätta Dependency-Track med CRACI

CRACI täcker båda halvorna av jobbet som förut krävde en generator och Dependency-Track. Det tar fram SBOM:en i bygget, fortsätter att omvärdera bevakade SBOM:er när nya sårbarheter publiceras, samlar fynd över byggen och repon och låter säkerhetsteam triagera dem och skicka vart och ett till teamet som äger åtgärden. Det finns inget uppladdningssteg att underhålla och ingen server att driva.

Var tydlig med vad du ger upp. Dependency-Tracks policymotor är mogen. CRACI har policyspärrar som blockerar byggen och licenspolicy, medan kommentarer och tröskelvarningar finns på roadmapen. Dependency-Track är också öppen källkod och egenhostat, medan CRACI i dag är en hanterad tjänst, med kundhostade runners på roadmapen för Enterprise. Om det betyder mer än kvaliteten på inventeringen, behåll Dependency-Track.

Varför det här spelar roll i reglerade sektorer

Enligt EU:s Cyber Resilience Act behöver tillverkare veta vad som finns i varje produktrelease och hantera sårbarheter i den, med rapporteringsskyldigheter för aktivt utnyttjade sårbarheter från september 2026. En sårbarhet du inte kan se för att din SBOM missade komponenten är ändå din sårbarhet.

CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad, och exporterar SBOM:er som CycloneDX eller SPDX, inklusive sårbarheter. Inventeringen och bevakningen kommer från samma registrering av vad varje release byggdes av. Se CRA-efterlevnad, industriell IoT och telekom.