CRACI vs Dependency-Track

Hva Dependency-Track gjør bra

OWASP Dependency-Track er et sterkt valg for komponentanalyse. Det er åpen kildekode under Apache 2.0-lisensen, det sporer komponentbruk på tvers av alle versjoner av alle applikasjoner i porteføljen din, og det henter sårbarhetsinformasjon fra flere kilder, blant dem National Vulnerability Database og GitHub Advisories. Policymotoren dekker regler for sikkerhet, lisens og drift, og det både leser og lager CycloneDX VEX-dokumenter. API-first-utformingen passer CI/CD: Pipelines laster opp SBOM-er til /api/v1/bom.

Team i regulerte sektorer liker det fordi det er transparent, selvhostet og bygget rundt et standardformat. Det svake punktet er ikke analysen. Det er det som går inn i den.

Analysen avhenger av input

Dependency-Track leser SBOM-er; det genererer dem ikke. Hvert funn, hvert policybrudd og hver porteføljevisning avhenger av SBOM-en pipelinen din sender. Hvis SBOM-en mangler en avhengighet, kan ikke Dependency-Track flagge den. Hvis to generatorer er uenige, viser Dependency-Track den du lastet opp.

I praksis er SBOM-generatorer ofte uenige, og årsakene står i deres egen dokumentasjon:

• Ingen felles grunn. Hver generator avgjør selv hva som teller som en komponent og hvilke filer den skal stole på, så to av dem rettet mot samme repository gir overlappende, men forskjellige lister.
• Bommer på det åpenbare. Et verktøy som løser avhengigheter fra lockfiler, har ingenting å løse i et repository uten committede lockfiler, som express 5.2.1. Det kan likevel returnere en liste, satt sammen av det andre det kjenner igjen, for eksempel GitHub Actions og workflow-filer.
• Konfigurasjon gir utslag. Syft velger catalogers etter skannetype, så ett flagg endrer hva det samme verktøyet i samme versjon rapporterer fra samme utsjekk.
• Uten manifest, ingen SBOM. Et repository uten noe avhengighetsmanifest gir en filbasert skanner ingenting å jobbe med, og det hvert verktøy da returnerer, sier mer om verktøyet enn om prosjektet.
• Tynne metadata. De fleste generatorer har ingen kilde til NTIA-leverandørfeltet, så det blir tomt uansett hva repositoriet inneholder.

CRACI kan ikke sammenlignes på denne måten. Det registrerer bygg i stedet for å skanne en mappe, så det kan ikke kjøres på samme måte. Poenget er ikke at noen av disse verktøyene er dårlige. Poenget er at en statisk skanning av et repository er et anslag over hva et bygg kommer til å bruke, og anslaget varierer med verktøyet, innstillingene og filene som finnes.

Hva CRACI endrer ved kilden

SBOM-en kommer fra bygget

CRACI er en GitHub Actions-kompatibel runner. Du endrer runs-on til craci, og jobbene dine kjører på CRACI i isolerte virtuelle maskiner. Under hver jobb registrerer en pakkebevisst proxy trafikk til pakkekilder: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, pluss nedlastingsforhåndsinnstillinger. Dokumentasjonen av avhengigheter følger med CI-cacher, så en pakke gjenopprettet fra en cache er fortsatt med i registreringen. SBOM-en, i CycloneDX eller SPDX, inkluderer alle transitive avhengigheter bygget faktisk brukte.

Den forteller deg når den er ufullstendig

Hver SBOM fra CRACI har en fullstendighetsstatus per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du vet om hver SBOM er en fullstendig registrering eller har et hull. Det betyr noe når en revisor spør hvordan du vet at inventaret ditt er fullstendig.

Den registrerer SBOM-en inne i bygget

CRACI genererer SBOM-en inne i sin egen runner, ut fra det jobben hentet. API-et returnerer SBOM-er, nettverksspor og provenance.

Den kontrollerer hva bygget kan nå

Fordi CRACI kjører jobben, kan det håndheve en egress-policy for nettverket: default deny eller default allow, med 24 innebygde forhåndsinnstillinger for programvarekilder og typede egendefinerte kilder. Policyer valideres før jobben starter, og blokkerer ved feil (fail closed). Dependency-Track kan fortelle deg i etterkant at en komponent er risikabel; en egress-policy begrenser hvilke kilder et bygg i det hele tatt kunne hente fra.

Et inventar over hva som er rullet ut hvor

Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Når en ny sårbarhet dukker opp, kan du se hvilke produkter som kjører den berørte versjonen, i stedet for å sette det sammen fra utgivelsesnotater og regneark.

Slik erstatter du Dependency-Track med CRACI

CRACI dekker begge halvdelene av jobben som før krevde en generator og Dependency-Track. Det lager SBOM-en i bygget, fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres, samler funn på tvers av bygg og repositorier, og lar sikkerhetsteam prioritere dem og sende hvert av dem til teamet som eier rettingen. Det er ikke noe opplastingssteg å vedlikeholde og ingen server å drifte.

Vær klar over hva du gir opp. Policymotoren i Dependency-Track er moden. CRACI har policy gates som blokkerer bygg, og lisenspolicy, mens kommentarer og terskelvarsler står på veikartet. Dependency-Track er også åpen kildekode og selvhostet, mens CRACI er en administrert tjeneste i dag, med kundehostede runnere på veikartet for Enterprise. Hvis dette betyr mer enn kvaliteten på inventaret, bør du beholde Dependency-Track.

Hvorfor dette betyr noe i regulerte sektorer

Under EUs Cyber Resilience Act må produsenter vite hva som er i hver produktutgivelse, og håndtere sårbarheter i den, med rapporteringsplikter for aktivt utnyttede sårbarheter fra september 2026. En sårbarhet du ikke kan se fordi SBOM-en din manglet komponenten, er fortsatt din sårbarhet.

CRACI automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen selskaper trenger for sin bredere CRA-samsvarsprosess, og eksporterer SBOM-er som CycloneDX eller SPDX, inkludert sårbarheter. Inventaret og overvåkingen kommer fra den samme registreringen av hva hver utgivelse ble bygget av. Se CRA-samsvar, industriell IoT og telekom.