CRACI en Dependabot

Behoud Dependabot. Dit is wat het dekt.

Staat uw code op GitHub, dan gebruikt u Dependabot waarschijnlijk al. Het doet drie nuttige dingen. Dependabot-meldingen vertellen u wanneer een afhankelijkheid in uw repository overeenkomt met een bekende kwetsbaarheid. Security updates openen pull requests die kwetsbare afhankelijkheden upgraden. Version updates houden afhankelijkheden actueel, ook wanneer er niets kwetsbaar is.

Dit alles steunt op de dependency graph van GitHub, die de manifests en lockfiles in uw repository parseert. GitHub kan die graph exporteren als SPDX-SBOM. Voor ecosystemen zoals Go, Gradle en Maven kunnen kant-en-klare actions afhankelijkheden die tijdens de build zijn opgelost, indienen via de dependency submission API.

Om afhankelijkheden met weinig moeite gepatcht te houden, is Dependabot moeilijk te verslaan, en CRACI opent geen pull requests. Wat CRACI toevoegt, is de andere helft: een vastlegging van wat elke build werkelijk heeft binnengehaald, gemonitord op nieuwe kwetsbaarheden, zodat u weet welke geleverde builds door een nieuwe advisory worden geraakt en welke update-pull-requests u het eerst moet mergen.

De vragen die Dependabot niet beantwoordt

Dependabot is gebouwd rond de repository. Het scant de standaardbranch en leunt op uw manifests en lockfiles. De documentatie van GitHub is daar direct over: meldingen kunnen niet elk beveiligingsprobleem vangen, u moet manifests en lockfiles actueel houden voor een nauwkeurige detectie, en alleen door GitHub beoordeelde advisories leiden tot meldingen.

Dat laat vragen over die een security- of compliancelead op den duur krijgt:

• Wat heeft de build voor release 4.2 werkelijk gedownload, inclusief tools en images die in geen enkel manifest staan?
• Kon een build terwijl hij draaide een willekeurige host op internet bereiken?
• Kunt u bewijzen dat de binary die een klant heeft ontvangen uit die build komt?
• Kunt u dat bewijs maanden later aan een auditor voorleggen?

Om die te beantwoorden is zicht vanuit de build nodig, en daar draait CRACI.

Wat CRACI toevoegt

Zicht tijdens 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, terwijl runs zichtbaar blijven in de GitHub-interface. 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. Pakketten die uit CI-caches worden teruggezet, worden meegenomen, omdat het bewijs van afhankelijkheden met de cache meereist.

Elke SBOM vermeldt hoe volledig hij is, per job en per cache: Complete, Complete with connections, Incomplete, Unavailable of Not recorded. Dat is iets anders dan een graph die maar zo goed is als de bestanden die hij parseert.

Het verschil blijkt in de praktijk. De dependency graph-export van GitHub is opgebouwd uit wat GitHub over de repository weet, dus die kan componenten vermelden die geen enkele bestandsscanner vindt, en die weerspiegelt de standaardbranch in plaats van de commit die u hebt gebouwd. Geen van beide is fout, gezien waarvoor de graph is ontworpen. Ze laten zien waarom een repositoryweergave en een vastlegging van de build verschillende dingen zijn. (CRACI kan niet op die manier worden vergeleken, omdat het builds vastlegt in plaats van mappen te scannen.)

Controles tijdens runtime

Dependabot vertelt u over een kwetsbaar pakket nadat het in uw manifest staat. Het heeft geen zeggenschap over waarmee een build verbinding kan maken. CRACI wel, omdat het de build draait. Egressbeleid is standaard weigeren of standaard toestaan, met 24 ingebouwde presets voor softwarebronnen, getypeerde aangepaste bronnen voor npm, PyPI, apt, apk, de Go-proxy, Nix, Cargo, OCI-registries en Git, en expliciete TLS-, TCP-, UDP- en ICMP-regels. Beleid wordt gevalideerd vóór de start van de job, is fail-closed en geeft een melding bij een overtreding.

Herkomst

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

Compliancebewijs

Regelgeving zoals de EU Cyber Resilience Act vraagt fabrikanten te weten wat er in elke productrelease zit en kwetsbaarheden daarin af te handelen. CRACI bundelt kwetsbaarheden over builds en repositories heen, blijft gemonitorde SBOM's opnieuw beoordelen wanneer er nieuwe advisories verschijnen, en exporteert SBOM's als CycloneDX of SPDX, inclusief kwetsbaarheden. Het automatiseert een aanzienlijk deel van het inzicht in de softwareketen en het bewijs dat bedrijven nodig hebben voor hun bredere CRA-nalevingsproces. Lees meer over wat de CRA is en CRA-bewijs.

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.

Hoe teams beide gebruiken

• Dependabot houdt afhankelijkheden gepatcht op de standaardbranch en opent pull requests wanneer er advisories verschijnen.
• CRACI draait de GitHub Actions-jobs, legt vast wat elke build heeft opgehaald, beperkt waarmee builds verbinding kunnen maken, monitort wat elke build heeft binnengehaald op nieuwe kwetsbaarheden, en bewaart het releasebewijs.

Er valt niets te migreren. Dependabot blijft op uw repositories werken, en uw workflows blijven op GitHub Actions draaien, alleen op een andere runner.

CRACI en Dependabot: veelgestelde vragen

Wat elke tool dekt, SBOM's, prijzen en compliance

Vervangt CRACI Dependabot?

Nee. Laat Dependabot aan staan. Het markeert kwetsbare afhankelijkheden in uw repositories en opent pull requests die ze upgraden. CRACI draait uw GitHub Actions-jobs en legt vast wat elke build werkelijk heeft binnengehaald, bepaalt waarmee builds verbinding kunnen maken en monitort wat is geleverd op nieuwe kwetsbaarheden.

Vervangen de kwetsbaarheidsoverzichten van CRACI de Dependabot-meldingen?

Nee. Ze beantwoorden een andere vraag. Dependabot-meldingen gaan over de standaardbranch van één repository. CRACI bundelt kwetsbaarheden over builds en repositories heen en blijft gemonitorde SBOM's opnieuw beoordelen, zodat u kunt zien welke builds een kwetsbare afhankelijkheid delen, en securityteams bevindingen kunnen triëren en doorsturen naar het team dat verantwoordelijk is voor de fix. Policy gates kunnen een build blokkeren; drempelmeldingen staan op de roadmap.

Opent CRACI pull requests zoals Dependabot?

Nee. Dependabot security updates en version updates openen pull requests; CRACI niet. Wat CRACI toevoegt, is de vastlegging van de build, zodat u bij een nieuwe advisory weet welke geleverde builds daardoor worden geraakt en welke update-pull-requests u het eerst moet mergen.

Hoe verschillen de SBOM's van GitHub en CRACI?

GitHub exporteert de dependency graph als SPDX-SBOM, opgebouwd uit de manifests en lockfiles in de repository en de dependency submission API, en die weerspiegelt de standaardbranch. CRACI legt de SBOM vast terwijl elke build draait en exporteert die als CycloneDX of SPDX, met een volledigheidsstatus per job en per cache die aangeeft of de vastlegging een gat had.

Helpt CRACI wanneer een afhankelijkheid in geen enkel manifest staat?

Ja, als de build die ophaalt van een pakketbron. Omdat CRACI het verkeer tijdens de job vastlegt, verschijnt een tool die door een script is gedownload of een pakket dat uit een cache is teruggezet toch in de vastlegging van de build, en de volledigheidsstatus van de SBOM vertelt u of iets niet kon worden vastgelegd.

Wat kosten Dependabot en CRACI?

Dependabot security updates en version updates zitten in elk GitHub-plan, inclusief Free (per september 2026). CRACI rekent alleen buildminuten: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU), per seconde gemeten, zonder maandbedrag en zonder kosten per SBOM. Zie prijzen voor de actuele voorwaarden.

Is CRACI alleen voor teams met compliance-eisen?

Nee, maar daar betaalt het bewijs zich het meest uit. Verkoopt u software in de EU, dan maakt de Cyber Resilience Act een componenteninventaris per release en het afhandelen van kwetsbaarheden onderdeel van het werk. Voor alle anderen blijft weten wat uw builds ophalen de basis van incidentrespons in de softwareketen. Boek een demo om de vastlegging van een van uw eigen workflows te zien.