CRACI og Dependabot

Behold Dependabot. Dette dekker det.

Ligger koden din på GitHub, bruker du sannsynligvis allerede Dependabot. Det gjør tre nyttige ting. Dependabot-varsler forteller deg når en avhengighet i repositoriet ditt matcher en kjent sårbarhet. Sikkerhetsoppdateringer åpner pull requests som oppgraderer sårbare avhengigheter. Versjonsoppdateringer holder avhengigheter oppdatert selv når ingenting er sårbart.

Alt dette bygger på dependency graph i GitHub, som tolker manifestene og lockfilene i repositoriet ditt. GitHub kan eksportere den grafen som en SPDX-SBOM. For økosystemer som Go, Gradle og Maven kan ferdige actions sende inn avhengigheter løst ved byggetid via dependency submission API.

For å holde avhengigheter oppdatert med lite innsats er Dependabot vanskelig å slå, og CRACI åpner ikke pull requests. Det CRACI tilfører, er den andre halvdelen: en oversikt over hva hvert bygg faktisk hentet, overvåket for nye sårbarheter, så du vet hvilke leverte bygg et nytt sikkerhetsvarsel berører, og hvilke pull requests med oppdateringer du bør merge først.

Spørsmålene Dependabot ikke svarer på

Dependabot er bygget rundt repositoriet. Det skanner standardgrenen og er avhengig av manifestene og lockfilene dine. GitHubs dokumentasjon er tydelig på dette: Varsler kan ikke fange opp alle sikkerhetsproblemer, du bør holde manifester og lockfiler oppdatert for nøyaktig oppdagelse, og bare sikkerhetsvarsler GitHub har gjennomgått, utløser varsler.

Det etterlater spørsmål en sikkerhets- eller samsvarsansvarlig før eller siden vil få:

• Hva lastet bygget for utgivelse 4.2 faktisk ned, inkludert verktøy og images som ikke står i noe manifest?
• Kunne et bygg nå en vilkårlig vert på internett mens det kjørte?
• Kan du bevise at binærfilen en kunde mottok, kom fra det bygget?
• Kan du fremskaffe den dokumentasjonen for en revisor måneder senere?

For å svare på dette trenger du innsyn fra innsiden av bygget, og det er der CRACI kjører.

Hva CRACI tilfører

Innsyn under 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, mens kjøringene fortsatt vises i GitHub-grensesnittet. 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. Pakker gjenopprettet fra CI-cacher blir tatt med videre, fordi dokumentasjonen av avhengigheter følger med cachen.

Hver SBOM angir hvor fullstendig den er, per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Det er noe annet enn en graf som bare er så god som filene den tolker.

Forskjellen viser seg i praksis. Eksporten av dependency graph i GitHub bygges fra det GitHub vet om repositoriet, så den kan liste opp komponenter ingen filbasert skanner finner, og den gjenspeiler standardgrenen snarere enn commiten du bygget. Ingen av delene er feil for det grafen er laget for. De viser hvorfor en repository-visning og en byggeoversikt er forskjellige ting. (CRACI kan ikke sammenlignes på den måten, siden det registrerer bygg i stedet for å skanne mapper.)

Kontroller under kjøring

Dependabot forteller deg om en sårbar pakke etter at den står i manifestet ditt. Det har ingenting å si over hva et bygg kan koble seg til. Det har CRACI, fordi det kjører bygget. Egress-policyer er default deny eller default allow, med 24 innebygde forhåndsinnstillinger for programvarekilder, typede egendefinerte kilder for npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registre og Git, og eksplisitte regler for TLS, TCP, UDP og ICMP. Policyer valideres før jobben starter, blokkerer ved feil (fail closed) og utløser et varsel ved brudd.

Provenance

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

Samsvarsdokumentasjon

Regelverk som EUs Cyber Resilience Act ber produsenter om å vite hva som er i hver produktutgivelse, og å håndtere sårbarheter i den. CRACI samler sårbarheter på tvers av bygg og repositorier, fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som nye sikkerhetsvarsler kommer, og eksporterer SBOM-er som CycloneDX eller SPDX, inkludert sårbarheter. Det automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen selskaper trenger for sin bredere CRA-samsvarsprosess. Les mer om hva CRA er og CRA-dokumentasjon.

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 bruker team begge

• Dependabot holder avhengigheter oppdatert på standardgrenen og åpner pull requests når sikkerhetsvarsler kommer.
• CRACI kjører GitHub Actions-jobbene, registrerer hva hvert bygg hentet, begrenser hvor bygg kan koble seg til, overvåker det hvert bygg hentet, for nye sårbarheter, og tar vare på utgivelsesdokumentasjonen.

Det er ingenting å migrere. Dependabot fortsetter å virke på repositoriene dine, og workflowene dine fortsetter å kjøre på GitHub Actions, bare på en annen runner.

CRACI og Dependabot: vanlige spørsmål

Hva hvert verktøy dekker, SBOM-er, priser og samsvar

Erstatter CRACI Dependabot?

Nei. Behold Dependabot. Det flagger sårbare avhengigheter i repositoriene dine og åpner pull requests som oppgraderer dem. CRACI kjører GitHub Actions-jobbene dine og registrerer hva hvert bygg faktisk hentet, kontrollerer hvor bygg kan koble seg til, og overvåker det som er levert, for nye sårbarheter.

Erstatter CRACIs sårbarhetsvisninger Dependabot-varsler?

Nei. De svarer på et annet spørsmål. Dependabot-varsler handler om standardgrenen i ett repository. CRACI samler sårbarheter på tvers av bygg og repositorier og fortsetter å vurdere overvåkede SBOM-er på nytt, så du kan se hvilke bygg som deler en sårbar avhengighet, og sikkerhetsteam kan prioritere funn og sende dem til teamet som eier rettingen. Policy gates kan blokkere et bygg; terskelvarsler står på veikartet.

Åpner CRACI pull requests slik Dependabot gjør?

Nei. Sikkerhetsoppdateringer og versjonsoppdateringer i Dependabot åpner pull requests; det gjør ikke CRACI. Det CRACI tilfører, er byggeoversikten, så når et nytt sikkerhetsvarsel kommer, vet du hvilke leverte bygg det berører, og hvilke pull requests med oppdateringer du bør merge først.

Hvordan skiller SBOM-ene fra GitHub og CRACI seg fra hverandre?

GitHub eksporterer dependency graph som en SPDX-SBOM, bygget fra manifestene og lockfilene i repositoriet og dependency submission API, og den gjenspeiler standardgrenen. CRACI registrerer SBOM-en mens hvert bygg kjører, og eksporterer den som CycloneDX eller SPDX, med en fullstendighetsstatus per jobb og per cache som forteller deg om registreringen hadde et hull.

Hjelper CRACI når en avhengighet ikke står i noe manifest?

Ja, hvis bygget henter den fra en pakkekilde. Fordi CRACI registrerer trafikken under jobben, dukker et verktøy lastet ned av et skript eller en pakke gjenopprettet fra en cache likevel opp i byggeoversikten, og fullstendighetsstatusen til SBOM-en forteller deg om noe ikke kunne registreres.

Hva koster Dependabot og CRACI?

Sikkerhetsoppdateringer og versjonsoppdateringer i Dependabot følger med alle GitHub-planer, også Free (per september 2026). CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), målt per sekund, uten månedsavgift og uten betaling per SBOM. Se priser for gjeldende vilkår.

Er CRACI bare for team med samsvarskrav?

Nei, men det er der dokumentasjonen lønner seg mest. Selger du programvare i EU, gjør Cyber Resilience Act et komponentinventar per utgivelse og sårbarhetshåndtering til en del av jobben. For alle andre er det å vite hva byggene henter, fortsatt grunnlaget for hendelseshåndtering i leverandørkjeden. Book en demo for å se byggeoversikten for en av dine egne workflows.