123% flere rapporterede CVE'er pr. dag i 2026 end sidste år.

Sammenligning

CRACI og Dependabot

Dependabot er ofte det første forsyningskædeværktøj, et GitHub-team slår til, og det bør forblive slået til. CRACI tilføjer det, Dependabot aldrig blev designet til at se: hvad dine builds faktisk gjorde.

Opdateret

Behold Dependabot. Her er, hvad det dækker.

Hjemmesiden for Dependabot
github.com

Ligger din kode på GitHub, bruger du sandsynligvis allerede Dependabot. Det gør tre nyttige ting. Dependabot-alarmer fortæller dig, når en afhængighed i dit repository matcher en kendt sårbarhed. Sikkerhedsopdateringer åbner pull requests, der opgraderer sårbare afhængigheder. Versionsopdateringer holder afhængigheder opdaterede, selv når intet er sårbart.

Alt dette bygger på GitHubs afhængighedsgraf, som parser manifesterne og lockfiles i dit repository. GitHub kan eksportere den graf som en SPDX-SBOM. For økosystemer som Go, Gradle og Maven kan færdige actions indsende afhængigheder, der er resolvet på build-tidspunktet, via dependency submission API.

Til at holde afhængigheder patchede med lille indsats er Dependabot svært at slå, og CRACI åbner ikke pull requests. Det, CRACI tilføjer, er den anden halvdel: en registrering af, hvad hvert build faktisk hentede, overvåget for nye sårbarheder, så du ved, hvilke leverede builds en ny advisory berører, og hvilke pull requests med opdateringer du skal merge først.

De spørgsmål, Dependabot ikke besvarer

Dependabot er bygget op om repositoriet. Det scanner standard-branchen og er afhængigt af dine manifester og lockfiles. GitHubs dokumentation er direkte om det: Alarmer kan ikke fange alle sikkerhedsproblemer, du bør holde manifest- og lock-filer opdaterede for at få præcis detektion, og kun advisories gennemgået af GitHub udløser alarmer.

Det efterlader spørgsmål, en sikkerheds- eller compliance-ansvarlig før eller siden vil blive stillet:

  • Hvad downloadede buildet for release 4.2 faktisk, inklusive værktøjer og images, der ikke står i noget manifest?
  • Kunne et build nå en vilkårlig host på internettet, mens det kørte?
  • Kan du bevise, at den binærfil, en kunde modtog, kom fra det build?
  • Kan du fremlægge den dokumentation for en revisor måneder senere?

At besvare dem kræver et blik inde fra buildet, og det er dér, CRACI kører.

Funktion CRACI Dependabot
Kører dine builds Jobs kører på CRACI-runnere Læser repository-data, ikke buildet
Afhængigheder registreret fra buildet Observerede hentninger, inklusive gendannelser fra CI-cache Manifester og lockfiles plus dependency submission API
SBOM-eksport CycloneDX og SPDX, fuldstændighed pr. job og cache SPDX-eksport af afhængighedsgrafen
Egress-politik for build-netværket Default deny eller allow, blokerer ved fejl (fail closed) Uden for dets område
Sårbarhedsalarmer Samlet på tværs af builds og repositories Fra advisories gennemgået af GitHub
Overvågning for nye advisories Overvågede SBOM'er genvurderes løbende Alarmer for standard-branchen, når advisories tilføjes
Åbner pull requests med opdateringer Sikkerhedsopdateringer og versionsopdateringer
Triage og videresendelse til ejerteams På tværs af builds og repositories Alarmer pr. repository
Virker uden at skifte runnere Jobs skal køre på CRACI Bygget ind i GitHub-repositories
Compliance-dokumentation SBOM'er i CycloneDX eller SPDX, registreringer via API; ingen rapporteksport Alarmvisninger og SPDX-eksporten i GitHub
  • Inkluderet
  • Delvist
  • Ikke inkluderet

Hvad CRACI tilføjer

Indsigt under 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, mens kørsler stadig vises i GitHubs brugerflade. 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. Pakker gendannet fra CI-caches føres videre, fordi dokumentationen for afhængighederne følger med cachen.

Hver SBOM angiver, hvor komplet den er, pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Det er noget andet end en graf, der kun er så god som de filer, den parser.

Forskellen viser sig i praksis. GitHubs eksport af afhængighedsgrafen er bygget ud fra det, GitHub ved om repositoriet, så den kan angive komponenter, som ingen filbaseret scanner finder, og den afspejler standard-branchen frem for det commit, du byggede. Ingen af delene er forkert i forhold til, hvad grafen er designet til. De viser, hvorfor et blik på repositoriet og en build-registrering er to forskellige ting. (CRACI kan ikke sammenlignes på den måde, da det registrerer builds i stedet for at scanne mapper.)

Kontrol under kørsel

Dependabot fortæller dig om en sårbar pakke, efter at den er kommet ind i dit manifest. Det har ingen indflydelse på, hvad et build kan forbinde sig til. Det har CRACI, fordi det kører buildet. Egress-politikker er default deny eller default allow, med 24 indbyggede presets for softwarekilder, typede brugerdefinerede kilder til npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registries og Git og eksplicitte TLS-, TCP-, UDP- og ICMP-regler. Politikker valideres, før jobbet starter, blokerer ved fejl (fail closed) og udløser en alarm ved et brud.

Provenance

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

Compliance-dokumentation

Regler som EU's Cyber Resilience Act beder producenter om at vide, hvad der er i hver produktrelease, og om at håndtere sårbarheder i den. CRACI samler sårbarheder på tværs af builds og repositories, bliver ved med at genvurdere overvågede SBOM'er, når nye advisories dukker op, og eksporterer SBOM'er som CycloneDX eller SPDX, inklusive sårbarheder. Det 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. Læs mere om hvad CRA er og CRA-dokumentation.

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 bruger teams begge

  • Dependabot holder afhængigheder patchede på standard-branchen og åbner pull requests, når advisories dukker op.
  • CRACI kører GitHub Actions-jobbene, registrerer, hvad hvert build hentede, begrænser, hvad builds kan forbinde sig til, overvåger det, hvert build hentede, for nye sårbarheder og opbevarer dokumentationen for releasen.

Der er intet at migrere. Dependabot fortsætter med at virke på dine repositories, og dine workflows fortsætter med at køre på GitHub Actions, bare på en anden runner.

CRACI understøtter GitHub Actions i dag, det samme sted som Dependabot. Læs om SBOM-generering under buildet, sporing af sårbarheder og priser.

CRACI og Dependabot: almindelige spørgsmål

Hvad hvert værktøj dækker, SBOM'er, priser og compliance

Erstatter CRACI Dependabot?

Nej. Behold Dependabot slået til. Det markerer sårbare afhængigheder i dine repositories og åbner pull requests, der opgraderer dem. CRACI kører dine GitHub Actions-jobs og registrerer, hvad hvert build faktisk hentede, styrer, hvad builds kan forbinde sig til, og overvåger det leverede for nye sårbarheder.

Erstatter CRACI's sårbarhedsvisninger Dependabot-alarmer?

Nej. De besvarer et andet spørgsmål. Dependabot-alarmer handler om standard-branchen i ét repository. CRACI samler sårbarheder på tværs af builds og repositories og bliver ved med at genvurdere overvågede SBOM'er, så du kan se, hvilke builds der deler en sårbar afhængighed, og sikkerhedsteams kan triagere fund og sende dem til det team, der ejer rettelsen. Policy-gates kan blokere et build; tærskelalarmer er på roadmappen.

Åbner CRACI pull requests som Dependabot?

Nej. Dependabots sikkerhedsopdateringer og versionsopdateringer åbner pull requests; det gør CRACI ikke. Det, CRACI tilføjer, er build-registreringen, så du, når en ny advisory dukker op, ved, hvilke leverede builds den berører, og hvilke pull requests med opdateringer du skal merge først.

Hvordan adskiller SBOM'erne fra GitHub og CRACI sig?

GitHub eksporterer afhængighedsgrafen som en SPDX-SBOM, bygget ud fra manifesterne og lockfiles i repositoriet og dependency submission API, og den afspejler standard-branchen. CRACI registrerer SBOM'en, mens hvert build kører, og eksporterer den som CycloneDX eller SPDX med en fuldstændighedsstatus pr. job og pr. cache, der fortæller dig, om registreringen havde et hul.

Hjælper CRACI, når en afhængighed ikke står i noget manifest?

Ja, hvis buildet henter den fra en pakkekilde. Fordi CRACI registrerer trafik under jobbet, dukker et værktøj, der er downloadet af et script, eller en pakke gendannet fra en cache stadig op i build-registreringen, og SBOM'ens fuldstændighedsstatus fortæller dig, om noget ikke kunne registreres.

Hvad koster Dependabot og CRACI?

Dependabots sikkerhedsopdateringer og versionsopdateringer er inkluderet i alle GitHub-planer, også Free (pr. september 2026). CRACI tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), målt pr. sekund, uden månedligt gebyr og uden betaling pr. SBOM. Se priser for aktuelle vilkår.

Er CRACI kun til teams med compliance-krav?

Nej, men det er dér, dokumentationen betaler sig mest. Sælger du software i EU, gør Cyber Resilience Act en komponentfortegnelse pr. release og håndtering af sårbarheder til en del af arbejdet. For alle andre er viden om, hvad dine builds henter, stadig grundlaget for hændelseshåndtering i forsyningskæden. Book en demo for at se build-registreringen for et af dine egne workflows.

Se det, Dependabot ikke kan se

Kør ét GitHub Actions-workflow på CRACI, og sammenlign dets build-registrering med din afhængighedsgraf.

Book en demo