CRACI vs Dependency-Track

Waar Dependency-Track goed in is

OWASP Dependency-Track is een sterke keuze voor componentanalyse. Het is open source onder de Apache 2.0-licentie, volgt het gebruik van componenten over elke versie van elke applicatie in uw portfolio, en haalt kwetsbaarheidsinformatie op uit verschillende bronnen, waaronder de National Vulnerability Database en GitHub Advisories. De beleidsengine dekt beveiligings-, licentie- en operationele regels, en het verwerkt en maakt CycloneDX VEX-documenten. Het API-first ontwerp past bij CI/CD: pipelines uploaden SBOM's naar /api/v1/bom.

Teams in gereguleerde sectoren waarderen het omdat het transparant en self-hosted is en rond een standaardformaat is gebouwd. Het zwakke punt is niet de analyse. Het is wat erin gaat.

Analyse hangt af van de input

Dependency-Track verwerkt SBOM's; het genereert ze niet. Elke bevinding, beleidsovertreding en portfolioweergave hangt af van de SBOM die uw pipeline stuurt. Mist de SBOM een afhankelijkheid, dan kan Dependency-Track die niet markeren. Zijn twee generatoren het oneens, dan toont Dependency-Track de SBOM die u hebt geüpload.

In de praktijk zijn SBOM-generatoren het vaak oneens, en de redenen staan in hun eigen documentatie:

• Geen gemeenschappelijke basis. Elke generator bepaalt zelf wat als component telt en welke bestanden hij vertrouwt, dus twee generatoren op één repository leveren overlappende maar verschillende lijsten op.
• Het voor de hand liggende missen. Een tool die afhankelijkheden uit lockfiles oplost, heeft niets op te lossen in een repository die er geen commit, zoals express 5.2.1. Hij kan toch een lijst teruggeven, gemaakt van wat hij verder herkent, zoals GitHub Actions en workflowbestanden.
• Schommelingen door configuratie. Syft kiest zijn catalogers op scantype, dus één vlag verandert wat dezelfde tool in dezelfde versie rapporteert vanuit dezelfde checkout.
• Geen manifest, geen SBOM. Een repository zonder enig afhankelijkheidsmanifest geeft een bestandsscanner niets om mee te werken, en wat elke tool dan teruggeeft, zegt meer over de tool dan over het project.
• Magere metadata. De meeste generatoren hebben geen bron voor het NTIA-leveranciersveld, dus dat blijft leeg, wat de repository ook bevat.

CRACI kan niet op deze manier worden vergeleken. Het legt builds vast in plaats van een map te scannen, dus het kan niet op dezelfde manier worden gedraaid. Het punt is niet dat een van deze tools slecht is. Het punt is dat een statische scan van een repository een schatting is van wat een build zal gebruiken, en die schatting varieert met de tool, de instellingen en de aanwezige bestanden.

Wat CRACI aan de bron verandert

De SBOM komt uit de build

CRACI is een met GitHub Actions compatibele runner. U wijzigt runs-on in craci, en uw jobs draaien op CRACI in geïsoleerde virtuele machines. Tijdens elke job legt een proxy die pakketten herkent het verkeer naar pakketbronnen vast: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets. Het bewijs van afhankelijkheden reist mee met CI-caches, dus een pakket dat uit een cache is teruggezet, staat nog steeds in de vastlegging. De SBOM, in CycloneDX of SPDX, bevat alle transitieve afhankelijkheden die de build werkelijk heeft gebruikt.

Het vertelt u wanneer het onvolledig is

Elke CRACI-SBOM heeft een volledigheidsstatus per job en per cache: Complete, Complete with connections, Incomplete, Unavailable of Not recorded. U weet of elke SBOM een volledige vastlegging is of een gat heeft. Dat telt wanneer een auditor vraagt hoe u weet dat uw inventaris volledig is.

Het legt de SBOM vast binnen de build

CRACI genereert de SBOM binnen zijn eigen runner, op basis van wat de job heeft opgehaald. De API levert SBOM's, netwerktraces en herkomstgegevens.

Het bepaalt wat de build kan bereiken

Omdat CRACI de job draait, kan het een egressbeleid voor het netwerk afdwingen: standaard weigeren of standaard toestaan, met 24 ingebouwde presets voor softwarebronnen en getypeerde aangepaste bronnen. Beleid wordt gevalideerd vóór de start van de job en is fail-closed. Dependency-Track kan u achteraf vertellen dat een component riskant is; een egressbeleid beperkt bij voorbaat uit welke bronnen een build kan ophalen.

Een inventaris van wat waar is uitgerold

De inventarisweergave van CRACI toont precies welke softwareversies in welke producten zijn uitgerold, wereldwijd. Duikt er een nieuwe kwetsbaarheid op, dan ziet u welke producten de getroffen versie draaien, in plaats van dat uit release notes en spreadsheets bij elkaar te moeten zoeken.

Dependency-Track vervangen door CRACI

CRACI dekt beide helften van het werk waarvoor eerder een generator en Dependency-Track nodig waren. Het maakt de SBOM in de build, blijft gemonitorde SBOM's opnieuw beoordelen wanneer er nieuwe kwetsbaarheden worden gepubliceerd, bundelt bevindingen over builds en repositories heen, en laat securityteams ze triëren en elke bevinding doorsturen naar het team dat verantwoordelijk is voor de fix. Er is geen uploadstap om te onderhouden en geen server om te draaien.

Wees u bewust van wat u opgeeft. De beleidsengine van Dependency-Track is volwassen. CRACI heeft policy gates die builds blokkeren en licentiebeleid, terwijl opmerkingen en drempelmeldingen op de roadmap staan. Dependency-Track is ook open source en self-hosted, terwijl CRACI vandaag een beheerde dienst is, met door de klant gehoste runners op de roadmap voor Enterprise. Wegen die zwaarder dan de kwaliteit van de inventaris, houd dan Dependency-Track.

Waarom dit telt in gereguleerde sectoren

Onder de EU Cyber Resilience Act moeten fabrikanten weten wat er in elke productrelease zit en kwetsbaarheden daarin afhandelen, met meldplichten voor actief misbruikte kwetsbaarheden vanaf september 2026. Een kwetsbaarheid die u niet ziet omdat uw SBOM het component miste, is nog steeds uw kwetsbaarheid.

CRACI automatiseert een aanzienlijk deel van het inzicht in de softwareketen en het bewijs dat bedrijven nodig hebben voor hun bredere CRA-nalevingsproces, en exporteert SBOM's als CycloneDX of SPDX, inclusief kwetsbaarheden. De inventaris en de monitoring komen uit dezelfde vastlegging van waaruit elke release is gebouwd. Zie CRA-compliance, industrieel IoT en telecom.