Hva CRACI erstatter i verktøykjeden din, og hva det fungerer sammen med

Det korte svaret: hva som flyttes, og hva som blir

Kartlegg din egen verktøykjede med denne tabellen. Hver rad er en oppgave et verktøy i verktøykjeden din gjør i dag, hva oppgaven må se for å gjøre den, og om CRACI gjør den fra der det sitter.

Oppgave i verktøykjeden	Hva oppgaven må se	CRACI	Hva du beholder, og hvorfor
CI-runnere for Linux-jobber på GitHub Actions: GitHub-hostede, fra en tredjepartsleverandør eller en selvdrevet flåte	Et sted å kjøre jobben	Erstatter	Runnere for Windows, macOS, GitHub Enterprise Server og andre CI-systemer enn GitHub Actions, som CRACI ikke støtter i dag
Nettverksovervåking eller egress-agenter lagt til runnere du beholder	Jobbens utgående trafikk	Erstatter på CRACI-runnere	Agenter på runnere du beholder andre steder
SBOM-generatorer kjørt i CI, team for team: skannere for manifester, låsefiler eller images brukt til å lage SBOM-er	Hva bygget faktisk hentet inn	Erstatter for bygg på CRACI	Generatorer for programvare du ikke bygger på CRACI, for eksempel images du henter og aldri bygger
Yoctos innebygde SBOM-generering (create-spdx) for dekning av forsyningskjeden	Hver kilde og hvert verktøy BitBake-bygget hentet	Erstatter for dekning av forsyningskjeden	create-spdx, hvis du er avhengig av oppskriftsmetadataene: påførte patcher og CVE-er merket som rettet
Sårbarhetssporing basert på SBOM-er: laste opp SBOM-er, matche sikkerhetsvarsler, følge med på nye	En korrekt SBOM per versjon, holdt oppdatert	Erstatter for bygg på CRACI; leverandør-SBOM-er kan legges til	Et dedikert verktøy hvis du trenger det CRACI ikke gjør: reachability, utbedringsmålinger som MTTR eller frister per alvorlighetsgrad
SBOM-er og komponentlister i regneark	En korrekt SBOM per versjon, holdt oppdatert	Erstatter	Ingenting
Kontroll av deklarerte lisenser og lisenspolicy	Hver komponents deklarerte lisens	Delvis	Lisensskanning av fulltekst og kodeutdrag, attribusjonsmerknader
SAST og kodeskanning	Kildekoden din	Fungerer sammen med	Behold det; det kjører uendret som et workflow-steg på en CRACI-runner
Hemmelighetsskanning og push protection	Repositoriet og commitene dine	Fungerer sammen med	Behold det
DAST og API-testing	Den kjørende tjenesten din	Fungerer sammen med	Behold det
Binær- og fastvareanalyse av tredjeparts binærfiler	En ferdig binærfil du ikke bygde	Fungerer sammen med	Behold det
Skanning av kodeutdrag og signaturer for kopiert eller vendret kode	Filinnholdet i repositoriet	Fungerer sammen med	Behold det
Prioritering basert på reachability	Kallgrafen din	Fungerer sammen med	Behold det hvis du er avhengig av det
Skanning av IaC, klynger og feilkonfigurasjoner	Konfigurasjon og kjørende infrastruktur	Fungerer sammen med	Behold det
CI/CD-sikkerhetskontroller av workflow-konfigurasjonen	Workflow-filer og innstillinger	Fungerer sammen med	Behold det
Saksbehandling, PSIRT-saksstyring, publisering av sikkerhetsvarsler	Prosessen din	Fungerer sammen med	Behold det
Automatisert etterlevelse: innsamling av dokumentasjon for SOC 2- eller ISO 27001-revisjoner	Kontrollene dine på tvers av systemer	Fungerer sammen med	Behold det; CRACIs registreringer er dokumentasjon det kan samle inn

Før og etter

Før: GitHub-hostede runnere, en egen SBOM-generator i hvert teams workflow, Yoctos create-spdx som legger til byggetid, og SBOM-er lastet opp til et sporingsverktøy eller et regneark, med kodeskanning, hemmelighetsskanning, binæranalyse og saksbehandling rundt. Etter: CRACI-runnere som kjører hver jobb, håndhever egress-policyen, registrerer SBOM-en og holder den under overvåking. Verktøyene som leser kode, repositorier, binærfiler og prosessen din, er uendret.

Hva CRACI erstatter, og hvorfor

Hver av disse oppgavene skjer under bygget. CRACI kan ta dem over fordi det er der bygget kjører. For hver av dem: mekanismen, hva du gir opp, og et eksempel.

Runnerne dine

CRACI er en runner for GitHub Actions. Du endrer runs-on til craci, og kjøringene vises fortsatt i GitHub som alle andre Actions-jobber. Hver jobb får sin egen virtuelle maskin, på Linux x86-64 eller ARM64, i en størrelse fra 1 til 32 vCPU-er, målt per sekund. Du trenger ikke skrive om workflowene: de eksisterende stegene, også skannestegene, fortsetter å kjøre.

CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU-er), målt per sekund, uten månedsavgift og uten kostnad per SBOM. Det gjør CRACI til en av de rimeligste CI-runnerne. Det kjører bygg omtrent dobbelt så raskt som GitHub-hostede runnere, takket være raskere maskinvare, kortere køtider og caching.

Runner, per minutt	CRACI	GitHub-hostet	Forskjell
2 vCPU x64	$0.004	$0.006	CRACI omtrent 33% billigere
2 vCPU ARM64	$0.004	$0.005	CRACI 20% billigere
32 vCPU x64	$0.064	$0.082	CRACI omtrent 22% billigere
32 vCPU ARM64	$0.064	$0.050	CRACI 28% dyrere

GitHubs listepriser per september 2026. GitHub runder hver jobb opp til et helt minutt; CRACI måler per sekund. Eksempel: et bygg på 10 minutter på en GitHub-hostet x64-runner med 2 kjerner koster $0.060. Med omtrent dobbel hastighet tar det 5 minutter på en CRACI-runner med 2 vCPU-er og koster $0.020, omtrent 67% mindre. Se priser og priser for CI-runnere.

Hva du gir opp. Windows- og macOS-runnere, andre CI-systemer og kundehostede runnere er ikke tilgjengelige i dag; GitLab CI, Jenkins, Windows, macOS og kundehostede runnere står på veikartet. GitHub Enterprise Server støttes ikke. Runnerne er administrerte, på europeisk infrastruktur. Hvis du veier administrerte runnere mot din egen flåte, se administrerte og selvdrevne runnere.

Egress-agenter på runnere du beholder

En egress-agent overvåker eller begrenser trafikken fra en runner som noen andre drifter. På CRACI håndhever runneren selv egress-policyen: avvis eller tillat som standard, 24 innebygde forhåndsinnstillinger for programvarekilder, typede egendefinerte kilder for pakkeregistre og Git, og eksplisitte nettverksregler. Policyen valideres før jobben starter og feiler lukket (fail closed), og CRACI varsler om policybrudd. En separat agent trengs ikke på CRACI-runnere.

Eksempel: en kompromittert avhengighet prøver å sende jobbens hemmeligheter til en vert bygget aldri har trengt. Med en policy som avviser som standard, blokkeres tilkoblingen, selv ved et angrep ingen har sett før, fordi policyen bare tillater det bygget trenger i stedet for å se etter kjente ondsinnede verter.

Hva du gir opp. Policyen dekker jobber på CRACI-runnere. Runnere du beholder andre steder, trenger fortsatt sin egen kontroll.

SBOM-generatoren i hvert teams workflow

En generator leser filene den har foran seg, for eksempel et manifest, en låsefil eller et image, og rekonstruerer hva som gikk inn. Ulike generatorer gir ulike lister fra samme checkout, og team velger som regel sin egen, så organisasjonen ender opp med flere oversikter som ikke stemmer overens.

CRACI registrerer pakkene hver jobb faktisk hentet inn, også pakker gjenopprettet fra CI-cacher, og de skjulte avhengighetene som låsefilbaserte verktøy går glipp av: kode lastet ned av npm-installasjonshooks, Rust-byggeskript som laster ned under bygget, og basisimaget med operativsystemlagene i et containerbygg. Hver komponent i SBOM-en var med i bygget. Hver jobbs SBOM oppgir hvor komplett den er, som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så et hull blir synlig i stedet for å gå upåaktet hen. Resultatet er én oversikt for hvert repositorium som bygger på CRACI, eksportert som CycloneDX eller SPDX. Økosystemer som registreres i dag: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, pluss nedlastinger fra Yocto og OpenEmbedded.

Eksempel: expressjs/express 5.2.1 har ingen låsefil i repositoriet. En generator som løser opp avhengigheter fra låsefiler, har ingenting å løse opp der, og kan likevel returnere et dokument som ikke lister noen av npm-avhengighetene som er deklarert i package.json. Et bygg av det samme prosjektet på CRACI registrerer pakkene npm install hentet. Mer om metoden i SBOM-er fra byggetidspunktet og SCA- og SBOM-verktøy sammenlignet; for en hjemmesnekret generatorstack, se DIY-SBOM-stacken.

Hva du gir opp. Økosystemer CRACI ikke registrerer ennå. Maven og Java står på veikartet, og alt som ikke står på listen over, dekkes ikke. Behold en generator for de byggene.

Yoctos innebygde SBOM-generering

Yocto skriver sin egen SPDX-SBOM gjennom create-spdx, og den er grundig når det gjelder det BitBake bygger. Den kan ikke se hva som skjer utenfor BitBakes metadata. CRACI kjører BitBake-bygget og registrerer hva det hentet. I et parallelt bygg av core-image-sato på en native ARM64-runner med 32 vCPU-er hadde CRACIs SBOM alle komponentene Yoctos SBOM hadde, pluss 88 som den manglet: 23 vertspakker på byggemaskinen, 10 GitHub-kilder, blant dem GitHub-actionen actions/upload-artifact, og 55 andre kilder og verktøy hentet under bygget. Den registrerte alle 653 Rust-crateversjoner med pkg:cargo-pakke-URL-er, så de kan matches mot sikkerhetsvarsler. Bygget uten Yoctos SBOM-generering tok 43% kortere tid: omtrent $9.96 mot $5.68 per bygg til CRACIs pris.

Hva du gir opp. Yoctos SPDX inneholder oppskriftsmetadata som CRACI ikke registrerer: patchene som er påført, og CVE-ene som er merket som rettet. Hvis du er avhengig av dem, la create-spdx være på. Metoden og hele sammenligningen finner du på Yocto-bygg på CRACI.

Fra SBOM-er til sårbarhetssporing

Et frittstående sporingsverktøy må mates med en SBOM og stoler på det det får. CRACI lager SBOM-en og tar vare på registreringen. Overvåkede SBOM-er vurderes kontinuerlig på nytt etter hvert som nye sikkerhetsvarsler publiseres. Bygghistorikken viser hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet hvilken periode du var berørt, innenfor planens lagringstid. Funn triageres til teamet som eier rettingen, CRACI varsler de relevante personene om en sårbarhet og alvorlighetsgraden, og policy gates kan blokkere et bygg på grunnlag av funn, også et bygg som inneholder en bestemt CVE. VEX støttes. Leverandør-SBOM-er kan legges til, så innkjøpte komponenter overvåkes sammen med dine egne bygg.

Eksempel: et sikkerhetsvarsel publiseres for en crate som en av tjenestene dine kompilerte inn for tre måneder siden. CRACI matcher det mot alle overvåkede SBOM-er og viser hvilke bygg som inneholdt den versjonen, uten at noen laster opp noe på nytt.

Hva du gir opp. CRACI tilbyr ikke reachability-analyse eller utbedringsmålinger som MTTR, frister per alvorlighetsgrad eller backlog-trender. Hvis du er avhengig av dem, behold verktøyet som gir deg dem. Se sårbarhetssporing for hele funksjonen.

Regnearket

For team uten SBOM-verktøy er det CRACI erstatter, manuell sammenstilling: noen kopierer avhengighetslister inn i et regneark før en utgivelse eller en revisjon. Et bygg på CRACI lager SBOM-en som en bivirkning av at det kjører, så listen finnes for hvert bygg, ikke bare for dem noen husket.

Hva CRACI fungerer sammen med, og hvordan

Disse verktøyene leser ting CRACI aldri leser. CRACI leser ikke kildekoden din på jakt etter feil, tester ikke kjørende tjenester og analyserer ikke binærfiler det ikke har bygget. De fortsetter å kjøre slik de gjør nå.

Verktøy som leser koden og repositoriet ditt

SAST, hemmelighetsskanning og push protection, skanning av kodeutdrag og signaturer, IaC-skanning og CI/CD-sikkerhetskontroller undersøker alle koden, commitene eller konfigurasjonen din. Steg i workflowen din kjører uendret på en CRACI-runner, og funksjoner på repositorienivå påvirkes ikke fordi de aldri kjørte på runneren. Et kodeskanningssteg kan ligge i samme jobb som bygget ditt. SAST er bevisst utenfor omfanget: det finnes mange utmerkede SAST-verktøy som fungerer sammen med CRACI. Se SAST og SCA for hvordan de to typene funn skiller seg fra hverandre.

Verktøy som undersøker det du ikke har bygget

Binær- og fastvareanalyse av leverandørers binærfiler, skannere for images du henter men aldri bygger, og DAST mot kjørende tjenester ser alle på noe som ble bygget et annet sted eller allerede kjører. CRACI registrerer bygg; en binærfil som kommer fra en leverandør, ble bygget et sted CRACI aldri så. Hvis leverandøren gir deg en SBOM, kan CRACI overvåke den sammen med dine egne bygg.

Prioritering basert på reachability leser kallgrafen din, som CRACI ikke analyserer. Behold det hvis du er avhengig av det; se reachability-analyse for hva den kan og ikke kan fortelle deg.

Prosessystemer

Saksbehandling, PSIRT-saksstyring, publisering av sikkerhetsvarsler og plattformer for automatisert etterlevelse driver prosessen din på tvers av mange systemer. CRACI ruter funn til teamet som eier dem, og tar vare på dokumentasjonen fra bygget; behold prosessverktøyene dine til resten. Registreringene forlater CRACI som SBOM-er i CycloneDX eller SPDX og gjennom API-et, som returnerer SBOM-er, nettverksspor og provenance-data. For revisjonssiden, se SBOM-kontroller for SOC 2. For lisensarbeid utover deklarerte lisenser, for eksempel merknader og gjennomgang av fulltekst, se etterlevelse av åpen kildekode-lisenser. CRACI tar med hver komponents deklarerte lisens og håndhever regler for lisenspolicy, blant annet ved å blokkere et bygg på grunn av en lisens.

Slik finner du erstatningspunktet i din egen verktøykjede

Fem spørsmål du kan svare på i løpet av en ettermiddag. Hvert svar forteller deg om en linje i verktøykjeden din flyttes.

1. Kjører byggene dine på GitHub Actions på Linux? Hvis ja, flyttes runnerne. Hvis ikke, erstatter CRACI ingenting i dag.
2. Hvem genererer SBOM-er i dag, og hvor mange ulike generatorer er i bruk? Hver generator på et repositorium du flytter til CRACI, er en linje som forsvinner.
3. Bygger du Yocto-images? Hvis ja, sjekk om noen er avhengig av de påførte patchene og rettede CVE-ene i utdataene fra create-spdx før du slår det av.
4. Hvor havner SBOM-ene etter at de er generert: i et sporingsverktøy, i et regneark, ingen steder? Det verktøyet eller den prosessen er den andre linjen som forsvinner, med mindre du trenger reachability eller utbedringsmålinger fra det.
5. Hvilke av sikkerhetsverktøyene dine leser kode, repositorier eller tredjeparts binærfiler? De blir. Skriv dem ned, så ingen forventer at CRACI skal erstatte dem.

Et gjennomarbeidet eksempel

En illustrativ enhetsprodusent, ikke basert på noe virkelig selskap: Linux-bygg på GitHub-hostede runnere, to team som bruker to ulike SBOM-generatorer, en Yocto-produktlinje med create-spdx på, SBOM-er samlet i et delt regneark, en pakke for kodeskanning og et saksbehandlingssystem. Sikkerhetsteamet svarer ja på spørsmål 1 og 3, finner to generatorer for spørsmål 2 og et regneark for spørsmål 4, og lister opp kodeskanning, hemmelighetsskanning og saksbehandlingssystemet for spørsmål 5. Ingen bruker patchmetadataene i Yoctos SPDX.

Flyttes til CRACI	Blir
GitHub-hostede runnere for Linux-jobbene	Kodeskanning, kjørt som et steg på CRACI-runnere
Begge SBOM-generatorene	Hemmelighetsskanning
create-spdx, siden ingen trenger patchmetadataene	Saksbehandlingssystemet
SBOM-regnearket

På runnerlinjen koster et bygg på 10 minutter, som koster $0.060 på en GitHub-hostet x64-runner med 2 kjerner, omtrent $0.020 på CRACI med hastighetsgevinsten. Kostnadene for de andre verktøyene må selskapet selv fylle inn.

Når CRACI ikke er svaret

• Pipelinene dine kjører på GitLab CI, Jenkins, Azure DevOps eller et annet CI-system. CRACI støtter bare GitHub Actions i dag, med GitLab CI og Jenkins på veikartet, så det erstatter ingenting ennå.
• Byggene dine trenger Windows- eller macOS-runnere eller GitHub Enterprise Server, eller må kjøre på din egen infrastruktur.
• Hovedproblemet ditt er støy fra kodeskanning i din egen kode. Det er et spørsmål om å justere SAST; se SAST og SCA og slik reduserer du støy fra sårbarheter.
• Hovedrisikoen din er fastvare og binærfiler du mottar fra leverandører, ikke kode du bygger.
• Verktøykjeden din er hovedsakelig Java og Maven, som står på veikartet, eller .NET, som ikke er på listen over økosystemer CRACI registrerer.
• Du trenger prioritering basert på reachability eller PSIRT-saksstyring i dag.

For en steg-for-steg-gjennomgang av produktet, se slik fungerer CRACI; for selve SBOM-en, SBOM-generering.

Hva CRACI erstatter: vanlige spørsmål

Hva erstatter CRACI?

GitHub Actions-runnerne dine for Linux-jobber, SBOM-generatorene team kjører i CI for bygg som flyttes til CRACI, Yoctos create-spdx for dekning av forsyningskjeden, egress-agenter på runnere og frittstående sårbarhetssporing basert på SBOM-er for de byggene. Det erstatter ikke verktøy som leser koden, repositoriene eller tredjeparts binærfiler.

Er CRACI et tillegg til SCA-verktøyet vårt, eller erstatter det noe?

Det erstatter oppgaver i byggelaget: runneren, SBOM-genereringen og sporingen som følger av SBOM-en. Om det erstatter SCA-verktøyet ditt, avhenger av hva du bruker det til. Hvis det leser koden din, gjør analyse av kodeutdrag eller binærfiler eller gir deg reachability, blir de delene.

Trenger vi fortsatt SBOM-generatoren vår hvis vi kjører bygg på CRACI?

Ikke for bygg som kjører på CRACI og bruker økosystemene det registrerer. CRACI registrerer pakkene hver jobb hentet inn, og eksporterer SBOM-en som CycloneDX eller SPDX. Behold en generator for programvare du ikke bygger på CRACI, for eksempel images du henter, og for økosystemer CRACI ikke registrerer ennå, for eksempel Maven.

Trenger vi fortsatt Yoctos innebygde SBOM-generering (create-spdx)?

For dekning av forsyningskjeden, nei: i et parallelt core-image-sato-bygg hadde CRACIs SBOM alle komponentene Yoctos hadde, pluss 88 som den manglet, og bygget uten create-spdx tok 43% kortere tid. La create-spdx være på hvis du er avhengig av de påførte patchene og CVE-ene merket som rettet, som CRACI ikke registrerer.

Erstatter CRACI kodeskanning eller hemmelighetsskanning?

Nei. CRACI leser ikke kildekoden eller commitene dine på jakt etter feil eller hemmeligheter. Behold de verktøyene. Kodeskanningssteg kjører uendret i workflowen din på en CRACI-runner, og funksjoner på repositorienivå påvirkes ikke.

Erstatter CRACI binær- eller fastvareanalyse?

Nei. CRACI registrerer byggene det kjører. For fastvare og binærfiler du mottar fra leverandører, er binæranalyse det riktige verktøyet. Hvis en leverandør gir deg en SBOM, kan CRACI overvåke den sammen med dine egne bygg.

Kan vi beholde de eksisterende sikkerhetsstegene i GitHub Actions på CRACI-runnere?

Ja. CRACI erstatter runneren, ikke GitHub Actions: du setter runs-on til craci, og workflowene, stegene og resultatene blir i GitHub. Skannesteg, teststeg og alle andre steg fortsetter å kjøre som før.