CRACI vs. Dependency-Track

Hvad Dependency-Track gør godt

OWASP Dependency-Track er et stærkt valg til komponentanalyse. Det er open source under Apache 2.0-licensen, sporer brugen af komponenter på tværs af hver version af hver applikation i din portefølje og henter sårbarhedsdata fra flere kilder, blandt andet National Vulnerability Database og GitHub Advisories. Dets politikmotor dækker sikkerheds-, licens- og driftsregler, og det læser og producerer CycloneDX VEX-dokumenter. Dets API-first-design passer til CI/CD: Pipelines uploader SBOM'er til /api/v1/bom.

Teams i regulerede sektorer kan lide det, fordi det er gennemsigtigt, selvhostet og bygget op om et standardformat. Dets svage punkt er ikke analysen. Det er det, der går ind i den.

Analysen afhænger af sit input

Dependency-Track læser SBOM'er; det genererer dem ikke. Hvert fund, hvert politikbrud og hver porteføljevisning afhænger af den SBOM, din pipeline sender. Mangler SBOM'en en afhængighed, kan Dependency-Track ikke markere den. Er to generatorer uenige, viser Dependency-Track den, du tilfældigvis uploadede.

I praksis er SBOM-generatorer meget uenige, og årsagerne står i deres egen dokumentation:

• Intet fælles grundlag. Hver generator afgør selv, hvad der tæller som en komponent, og hvilke filer der er til at stole på, så to af dem, der peges mod ét repository, returnerer overlappende, men forskellige lister.
• De overser det åbenlyse. Et værktøj, der resolver afhængigheder ud fra lock-filer, har intet at resolve i et repository, der ikke committer nogen, og det gør express 5.2.1 ikke. Det kan alligevel returnere en liste bestående af det, det ellers genkender, for eksempel GitHub Actions og workflow-filer.
• Udsving efter konfiguration. Syft vælger sine katalogiseringsværktøjer efter scanningstype, så ét flag ændrer, hvad det samme værktøj i samme version rapporterer fra samme checkout.
• Intet manifest, ingen SBOM. Et repository uden noget afhængighedsmanifest giver en filbaseret scanner intet at arbejde ud fra, og det, hvert værktøj så returnerer, siger mere om værktøjet end om projektet.
• Tynde metadata. De fleste generatorer har ingen kilde til NTIA's leverandørfelt, så det ender tomt, uanset hvad repositoriet indeholder.

CRACI kan ikke sammenlignes på den måde. Det registrerer builds i stedet for at scanne en mappe, så det kan ikke køres på samme måde. Pointen er ikke, at nogen af disse værktøjer er dårlige. Pointen er, at en statisk scanning af et repository er et skøn over, hvad et build vil bruge, og at skønnet varierer med værktøjet, dets indstillinger og de filer, der er til stede.

Hvad CRACI ændrer ved kilden

SBOM'en kommer fra buildet

CRACI er en GitHub Actions-kompatibel runner. Du ændrer runs-on til craci, og dine jobs kører på CRACI i isolerede virtuelle maskiner. Under hvert job registrerer en pakkebevidst proxy trafikken til pakkekilder: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets. Dokumentationen for afhængighederne følger med CI-caches, så en pakke gendannet fra en cache stadig er i registreringen. SBOM'en, i CycloneDX eller SPDX, indeholder alle transitive afhængigheder, buildet faktisk brugte.

Det siger til, når den er ufuldstændig

Hver CRACI-SBOM har en fuldstændighedsstatus pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Du ved, om hver SBOM er en fuld registrering eller har et hul. Det betyder noget, når en revisor spørger, hvordan du ved, at dit inventar er komplet.

Det registrerer SBOM'en inde i buildet

CRACI genererer SBOM'en inde i sin egen runner ud fra det, jobbet hentede. API'et returnerer SBOM'er, netværkstraces og provenance.

Det kontrollerer, hvad buildet kan nå

Fordi CRACI kører jobbet, kan det håndhæve en egress-politik for netværket: default deny eller default allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder. Politikker valideres, før jobbet starter, og blokerer ved fejl (fail closed). Dependency-Track kan fortælle dig bagefter, at en komponent er risikabel; en egress-politik begrænser fra starten, hvilke kilder et build kunne hente fra.

Et inventar over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Sådan erstatter du Dependency-Track med CRACI

CRACI dækker begge halvdele af det arbejde, der før krævede en generator og Dependency-Track. Det producerer SBOM'en i buildet, bliver ved med at genvurdere overvågede SBOM'er, når nye sårbarheder offentliggøres, samler fund på tværs af builds og repositories og lader sikkerhedsteams triagere dem og sende hvert enkelt videre til det team, der ejer rettelsen. Der er ikke noget upload-trin at vedligeholde og ingen server at drive.

Vær klar over, hvad du giver afkald på. Dependency-Tracks politikmotor er moden. CRACI har policy-gates, der blokerer builds, og licenspolitik, mens kommentarer og tærskelalarmer er på roadmappen. Dependency-Track er også open source og selvhostet, mens CRACI er en managed tjeneste i dag, med kundehostede runnere på roadmappen til Enterprise. Betyder det mere end kvaliteten af inventaret, så behold Dependency-Track.

Derfor betyder det noget i regulerede sektorer

Under EU's Cyber Resilience Act skal producenter vide, hvad der er i hver produktrelease, og håndtere sårbarheder i den, med rapporteringsforpligtelser for aktivt udnyttede sårbarheder fra september 2026. En sårbarhed, du ikke kan se, fordi din SBOM overså komponenten, er stadig din sårbarhed.

CRACI automatiserer en væsentlig del af den indsigt i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere proces for CRA-compliance, og eksporterer SBOM'er som CycloneDX eller SPDX, inklusive sårbarheder. Inventaret og overvågningen kommer fra den samme registrering af, hvad hver release blev bygget af. Se CRA-compliance, industriel IoT og telekom.