CRACI och Dependabot

Behåll Dependabot. Det här täcker det.

Om din kod ligger på GitHub använder du förmodligen redan Dependabot. Det gör tre nyttiga saker. Dependabot-varningar talar om när ett beroende i ditt repo matchar en känd sårbarhet. Säkerhetsuppdateringar öppnar pull requests som uppgraderar sårbara beroenden. Versionsuppdateringar håller beroenden aktuella även när inget är sårbart.

Allt detta bygger på GitHubs beroendegraf, som tolkar manifesten och lockfilerna i ditt repo. GitHub kan exportera grafen som en SBOM i SPDX. För ekosystem som Go, Gradle och Maven kan färdiga actions skicka in beroenden som lösts vid byggtid via dependency submission API.

För att hålla beroenden patchade med liten insats är Dependabot svårslaget, och CRACI öppnar inte pull requests. Det CRACI lägger till är den andra halvan: en registrering av vad varje bygge faktiskt hämtade, bevakad för nya sårbarheter, så att du vet vilka levererade byggen ett nytt säkerhetsmeddelande påverkar och vilka pull requests med uppdateringar du ska merga först.

Frågorna Dependabot inte besvarar

Dependabot är byggt kring repot. Det skannar standardgrenen och förlitar sig på dina manifest och lockfiler. GitHubs dokumentation är tydlig med det: varningar kan inte fånga alla säkerhetsproblem, du bör hålla manifest och lockfiler uppdaterade för korrekt upptäckt, och bara säkerhetsmeddelanden som GitHub har granskat utlöser varningar.

Det lämnar frågor som en säkerhets- eller efterlevnadsansvarig förr eller senare får:

• Vad laddade bygget för release 4.2 faktiskt ner, inklusive verktyg och avbilder som inte finns i något manifest?
• Kunde ett bygge nå en godtycklig värd på internet medan det kördes?
• Kan du bevisa att binären som en kund fick kom från det bygget?
• Kan du ta fram de bevisen för en revisor flera månader senare?

Att besvara dem kräver en vy inifrån bygget, och det är där CRACI körs.

Vad CRACI lägger till

Insyn under bygget

CRACI är en GitHub Actions-kompatibel runner. Du ändrar runs-on till craci och dina jobb körs på CRACI i isolerade virtuella maskiner, medan körningarna fortfarande syns i GitHubs gränssnitt. Under varje jobb registrerar en paketmedveten proxy trafik till paketkällor: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar. Paket som återställs från CI-cachar följer med, eftersom beroendebevisen följer med cachen.

Varje SBOM anger hur komplett den är, per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Det är något annat än en graf som bara är så bra som filerna den tolkar.

Skillnaden syns i praktiken. Exporten av GitHubs beroendegraf bygger på vad GitHub vet om repot, så den kan lista komponenter som ingen filbaserad skanner hittar, och den speglar standardgrenen snarare än commiten du byggde. Inget av beteendena är fel för det grafen är tänkt att göra. De visar varför en vy av repot och en registrering av bygget är olika saker. (CRACI kan inte jämföras på det sättet, eftersom det registrerar byggen i stället för att skanna kataloger.)

Kontroller under körning

Dependabot berättar om ett sårbart paket efter att det har hamnat i ditt manifest. Det har inget att säga till om vart ett bygge kan ansluta. Det har CRACI, eftersom det kör bygget. Egress-policyer nekar eller tillåter som standard, med 24 inbyggda förinställningar för programvarukällor, typade anpassade källor för npm, PyPI, apt, apk, Go-proxyn, Nix, Cargo, OCI-register och Git, och explicita regler för TLS, TCP, UDP och ICMP. Policyer valideras innan jobbet startar, blockerar vid fel och utlöser en varning vid överträdelse.

Proveniens

CRACI genererar SBOM:en inne i sin egen runner, utifrån vad jobbet hämtade. API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Bevis för efterlevnad

Regelverk som EU:s Cyber Resilience Act kräver att tillverkare vet vad som finns i varje produktrelease och hanterar sårbarheter i den. CRACI samlar sårbarheter över byggen och repon, fortsätter att omvärdera bevakade SBOM:er när nya säkerhetsmeddelanden dyker upp och exporterar SBOM:er som CycloneDX eller SPDX, inklusive sårbarheter. Det automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad. Läs mer om vad CRA är och CRA-bevis.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp kan du se vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

Så använder team båda

• Dependabot håller beroenden patchade på standardgrenen och öppnar pull requests när säkerhetsmeddelanden kommer.
• CRACI kör GitHub Actions-jobben, registrerar vad varje bygge hämtade, begränsar vart byggen kan ansluta, bevakar det varje bygge hämtade för nya sårbarheter och behåller bevisen för varje release.

Det finns inget att migrera. Dependabot fortsätter att arbeta på dina repon, och dina arbetsflöden fortsätter att köras på GitHub Actions, bara på en annan runner.

CRACI och Dependabot: vanliga frågor

Vad varje verktyg täcker, SBOM:er, priser och efterlevnad

Ersätter CRACI Dependabot?

Nej. Behåll Dependabot påslaget. Det flaggar sårbara beroenden i dina repon och öppnar pull requests som uppgraderar dem. CRACI kör dina GitHub Actions-jobb och registrerar vad varje bygge faktiskt hämtade, styr vart byggen kan ansluta och bevakar det som levererats för nya sårbarheter.

Ersätter CRACI:s sårbarhetsvyer Dependabot-varningar?

Nej. De besvarar en annan fråga. Dependabot-varningar gäller standardgrenen i ett repo. CRACI samlar sårbarheter över byggen och repon och fortsätter att omvärdera bevakade SBOM:er, så att du kan se vilka byggen som delar ett sårbart beroende, och säkerhetsteam kan triagera fynd och skicka dem till teamet som äger åtgärden. Policyspärrar kan blockera ett bygge; tröskelvarningar finns på roadmapen.

Öppnar CRACI pull requests som Dependabot?

Nej. Dependabots säkerhetsuppdateringar och versionsuppdateringar öppnar pull requests; det gör inte CRACI. Det CRACI lägger till är registreringen av bygget, så när ett nytt säkerhetsmeddelande kommer vet du vilka levererade byggen det påverkar och vilka pull requests med uppdateringar du ska merga först.

Hur skiljer sig SBOM:erna från GitHub och CRACI åt?

GitHub exporterar beroendegrafen som en SBOM i SPDX, byggd från manifesten och lockfilerna i repot och dependency submission API, och den speglar standardgrenen. CRACI registrerar SBOM:en medan varje bygge körs och exporterar den som CycloneDX eller SPDX, med en fullständighetsstatus per jobb och per cache som talar om ifall registreringen hade en lucka.

Hjälper CRACI när ett beroende inte finns i något manifest?

Ja, om bygget hämtar det från en paketkälla. Eftersom CRACI registrerar trafik under jobbet syns ett verktyg som laddats ner av ett skript eller ett paket som återställts från en cache ändå i registreringen av bygget, och SBOM:ens fullständighetsstatus talar om ifall något inte kunde registreras.

Vad kostar Dependabot och CRACI?

Dependabots säkerhetsuppdateringar och versionsuppdateringar ingår i alla GitHub-planer, inklusive Free (per september 2026). CRACI tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en runner med standardvalet 2 vCPU), mätt per sekund, utan månadsavgift och utan avgift per SBOM. Se priser för aktuella villkor.

Är CRACI bara för team med efterlevnadskrav?

Nej, men det är där bevisen ger mest. Om du säljer programvara i EU gör Cyber Resilience Act en komponentinventering per release och sårbarhetshantering till en del av jobbet. För alla andra är kunskapen om vad dina byggen hämtar ändå grunden för incidenthantering i leveranskedjan. Boka en demo för att se registreringen av bygget för ett av dina egna arbetsflöden.