Vad CRACI ersätter i din stack, och vad det kompletterar

Det korta svaret: vad som flyttar och vad som stannar

Kartlägg din egen stack med den här tabellen. Varje rad är en uppgift som ett verktyg i din stack utför i dag, vad uppgiften behöver se för att utföras och om CRACI utför den från sin position.

Uppgift i din stack	Vad uppgiften behöver se	CRACI	Vad du behåller, och varför
CI-runners för Linux-jobb på GitHub Actions: GitHub-hostade, från en tredjepartsleverantör eller en egen självhostad flotta	Någonstans att köra jobbet	Ersätter	Runners för Windows, macOS, GitHub Enterprise Server och andra CI-system än GitHub Actions, som CRACI inte stöder i dag
Nätverksövervakning eller egress-agenter på runners du behåller	Jobbets utgående trafik	Ersätter på CRACI-runners	Agenter på runners du behåller på annat håll
SBOM-generatorer som körs i CI, team för team: manifest-, lockfile- eller image-skannrar som används för att ta fram SBOM:er	Vad bygget faktiskt hämtade	Ersätter för byggen på CRACI	Generatorer för mjukvara du inte bygger på CRACI, till exempel images du hämtar och aldrig bygger
Yoctos inbyggda SBOM-generering (create-spdx) för täckning av leveranskedjan	Varje källa och verktyg som BitBake-bygget hämtade	Ersätter för täckning av leveranskedjan	create-spdx, om du förlitar dig på dess receptmetadata: tillämpade patchar och CVE:er markerade som åtgärdade
Sårbarhetsspårning utifrån SBOM:er: ladda upp SBOM:er, matcha säkerhetsbulletiner, bevaka nya	En korrekt SBOM per release, hållen aktuell	Ersätter för byggen på CRACI; leverantörers SBOM:er kan läggas till	Ett dedikerat verktyg om du behöver det CRACI inte gör: nåbarhet, åtgärdsmått som MTTR eller tidsfrister per allvarlighetsgrad
SBOM:er och komponentlistor i kalkylark	En korrekt SBOM per release, hållen aktuell	Ersätter	Ingenting
Kontroller av deklarerade licenser och licenspolicy	Varje komponents deklarerade licens	Delvis	Licensskanning på fulltext- och snippetnivå, attributionstexter
SAST och kodskanning	Din källkod	Kompletterar	Behåll det; det körs oförändrat som ett workflow-steg på en CRACI-runner
Hemlighetsskanning och push-skydd	Ditt repositorium och dina commits	Kompletterar	Behåll det
DAST och API-tester	Din körande tjänst	Kompletterar	Behåll det
Binär- och firmwareanalys av tredjepartsbinärer	En färdig binär som du inte byggde	Kompletterar	Behåll det
Snippet- och signaturskanning för kopierad eller inkluderad kod	Filinnehåll i repositoriet	Kompletterar	Behåll det
Nåbarhetsbaserad prioritering	Din anropsgraf	Kompletterar	Behåll det om du förlitar dig på det
Skanning av IaC, kluster och felkonfigurationer	Konfiguration och körande infrastruktur	Kompletterar	Behåll det
CI/CD-posture-kontroller av workflow-konfigurationen	Workflow-filer och inställningar	Kompletterar	Behåll det
Ärendehantering, hantering av PSIRT-ärenden, publicering av säkerhetsbulletiner	Din process	Kompletterar	Behåll det
Compliance-automatisering: insamling av evidens för SOC 2- eller ISO 27001-revisioner	Dina kontroller över olika system	Kompletterar	Behåll det; CRACI:s registreringar är evidens som det kan samla in

Före och efter

Före: GitHub-hostade runners, en annan SBOM-generator i varje teams workflow, Yoctos create-spdx som förlänger byggtiden och SBOM:er som laddas upp till ett spårningsverktyg eller ett kalkylark, med kodskanning, hemlighetsskanning, binäranalys och ärendehantering runt omkring. Efter: CRACI-runners som kör varje jobb, upprätthåller dess egress-policy, registrerar dess SBOM och håller den bevakad. Verktygen som läser kod, repositorier, binärer och din process är oförändrade.

Vad CRACI ersätter, och varför

Var och en av de här uppgifterna sker under bygget. CRACI kan ta över dem eftersom det är där bygget körs. För var och en: mekanismen, vad du ger upp och ett exempel.

Dina runners

CRACI är en runner för GitHub Actions. Du ändrar runs-on till craci, och körningarna syns fortfarande i GitHub som vilket annat Actions-jobb som helst. Varje jobb får en egen virtuell maskin, på Linux x86-64 eller ARM64, i en storlek från 1 till 32 vCPU:er, debiterad per sekund. Du behöver inte skriva om några workflows: dina befintliga steg, skanningssteg inräknade, fortsätter att köras.

CRACI tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en standardrunner med 2 vCPU:er), debiterat per sekund, utan månadsavgift och utan avgift per SBOM. Det gör CRACI till en av de mest prisvärda CI-runnerna. CRACI kör byggen ungefär dubbelt så snabbt som GitHub-hostade runners, tack vare snabbare hårdvara, kortare kötider och cachning.

Runner, per minut	CRACI	GitHub-hostad	Skillnad
2 vCPU x64	$0.004	$0.006	CRACI cirka 33 % billigare
2 vCPU ARM64	$0.004	$0.005	CRACI 20 % billigare
32 vCPU x64	$0.064	$0.082	CRACI cirka 22 % billigare
32 vCPU ARM64	$0.064	$0.050	CRACI 28 % dyrare

GitHubs listpriser per september 2026. GitHub avrundar varje jobb uppåt till en hel minut; CRACI debiterar per sekund. Exempel: ett bygge på 10 minuter på en GitHub-hostad x64-runner med 2 kärnor kostar $0.060. Med ungefär dubbla hastigheten tar det 5 minuter på en CRACI-runner med 2 vCPU:er och kostar $0.020, cirka 67 % mindre. Se priser och priser för CI-runners.

Vad du ger upp. Windows- och macOS-runners, andra CI-system och kundhostade runners finns inte i dag; GitLab CI, Jenkins, Windows, macOS och kundhostade runners finns på roadmapen. GitHub Enterprise Server stöds inte. Runnerna är hanterade, på europeisk infrastruktur. Om du väger hanterade runners mot din egen flotta, läs hanterade eller självhostade runners.

Egress-agenter på runners du behåller

En egress-agent övervakar eller begränsar trafiken från en runner som någon annan driver. På CRACI upprätthåller runnern själv egress-policyn: neka eller tillåt som standard, 24 inbyggda förinställningar för mjukvarukällor, typade egna källor för paketregister och Git samt uttryckliga nätverksregler. Policyn valideras innan jobbet startar och fallerar stängd (fail closed), och CRACI larmar vid policyöverträdelser. Det behövs ingen separat agent på CRACI-runners.

Exempel: ett komprometterat beroende försöker skicka jobbets hemligheter till en värd som bygget aldrig har behövt. Med en default-deny-policy blockeras anslutningen, även vid en attack som ingen har sett förut, eftersom policyn bara tillåter det bygget behöver i stället för att leta efter kända skadliga värdar.

Vad du ger upp. Policyn omfattar jobb på CRACI-runners. Runners du behåller på annat håll behöver fortfarande sin egen kontroll.

SBOM-generatorn i varje teams workflow

En generator läser filerna framför sig, till exempel ett manifest, en lockfile eller en image, och rekonstruerar vad som gick in. Olika generatorer ger olika listor från samma checkout, och team väljer oftast sin egen, så organisationen får flera inventeringar som inte stämmer överens.

CRACI registrerar paketen som varje jobb faktiskt hämtade, inklusive paket som återställts från CI-cachar, och de dolda beroenden som lockfile-baserade verktyg missar: kod som npm-installationshooks laddar ner, Rust-byggskript som laddar ner vid byggtid och basimagen med dess operativsystemslager i ett containerbygge. Varje komponent i SBOM:en fanns i bygget. Varje jobbs SBOM anger sin fullständighet, som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så att en lucka syns i stället för att förbli tyst. Resultatet är en enda inventering för varje repositorium som bygger på CRACI, exporterad som CycloneDX eller SPDX. Ekosystem som registreras i dag: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningar från Yocto och OpenEmbedded.

Exempel: expressjs/express 5.2.1 checkar inte in någon lockfile. En generator som löser upp beroenden från lockfiles har ingenting att lösa upp där, och kan ändå returnera ett dokument som inte listar något av npm-beroendena som deklareras i package.json. Ett bygge av samma projekt på CRACI registrerar paketen som npm install hämtade. Mer om metoden i SBOM:er från bygget och SCA- och SBOM-verktyg jämförda; för en egenbyggd generatorstack, se DIY-SBOM-stacken.

Vad du ger upp. Ekosystem som CRACI inte registrerar ännu. Maven och Java finns på roadmapen, och allt som inte finns i listan ovan omfattas inte. Behåll en generator för de byggena.

Yoctos inbyggda SBOM-generering

Yocto skriver sin egen SPDX-SBOM via create-spdx, och den är grundlig när det gäller det BitBake bygger. Den ser inte vad som händer utanför BitBakes metadata. CRACI kör BitBake-bygget och registrerar vad det hämtade. I ett jämförande bygge av core-image-sato sida vid sida, på en nativ ARM64-runner med 32 vCPU:er, hade CRACI:s SBOM alla komponenter som Yoctos SBOM hade, plus 88 som den missade: 23 värdpaket på byggmaskinen, 10 GitHub-källor, bland dem GitHub Action actions/upload-artifact, och 55 andra källor och verktyg som hämtades under bygget. Den registrerade alla 653 versioner av Rust-crates med pkg:cargo-paket-URL:er, så att de kan matchas mot säkerhetsbulletiner. Bygget utan Yoctos SBOM-generering tog 43 % kortare tid: cirka $9.96 mot $5.68 per bygge till CRACI:s pris.

Vad du ger upp. Yoctos SPDX innehåller receptmetadata som CRACI inte registrerar: de tillämpade patcharna och de CVE:er som markerats som åtgärdade. Om du förlitar dig på dem, låt create-spdx vara på. Metoden och hela jämförelsen finns på Yocto-byggen på CRACI.

Från SBOM:er till sårbarhetsspårning

Ett fristående spårningsverktyg måste matas med en SBOM och litar på det det får. CRACI tar fram SBOM:en och håller registreringen. Bevakade SBOM:er omvärderas löpande när nya säkerhetsbulletiner publiceras. Bygghistoriken visar vilka byggen som innehöll ett sårbart beroende, direkt eller transitivt, så att du vet under vilken period du var drabbad, inom planens lagringstid. Fynd fördelas till teamet som äger åtgärden, CRACI meddelar berörda personer om en sårbarhet och dess allvarlighetsgrad, och policygrindar kan blockera ett bygge utifrån fynd, även ett bygge som innehåller en specifik CVE. VEX stöds. Leverantörers SBOM:er kan läggas till, så att inköpta komponenter bevakas tillsammans med dina egna byggen.

Exempel: en säkerhetsbulletin publiceras för en crate som en av dina tjänster kompilerade in för tre månader sedan. CRACI matchar den mot varje bevakad SBOM och visar vilka byggen som innehöll den versionen, utan att någon laddar upp något igen.

Vad du ger upp. CRACI erbjuder inte nåbarhetsanalys eller åtgärdsmått som MTTR, tidsfrister per allvarlighetsgrad eller backlogtrender. Om du är beroende av dem, behåll verktyget som ger dem. Se sårbarhetsspårning för hela funktionen.

Kalkylarket

För team utan SBOM-verktyg är det CRACI ersätter manuellt sammanställande: någon kopierar beroendelistor till ett kalkylark före en release eller en revision. Ett bygge på CRACI tar fram SBOM:en som en bieffekt av körningen, så listan finns för varje bygge, inte bara för dem någon kom ihåg.

Vad CRACI kompletterar, och hur

De här verktygen läser saker som CRACI aldrig läser. CRACI läser inte din källkod efter brister, testar inte körande tjänster och analyserar inte binärer som det inte har byggt. De fortsätter att köras som i dag.

Verktyg som läser din kod och ditt repositorium

SAST, hemlighetsskanning och push-skydd, snippet- och signaturskanning, IaC-skanning och CI/CD-posture-kontroller granskar alla din kod, dina commits eller din konfiguration. Steg i ditt workflow körs oförändrade på en CRACI-runner, och funktioner på repositorienivå påverkas inte, eftersom de aldrig kördes på runnern. Ett kodskanningssteg kan ligga i samma jobb som ditt bygge. SAST ligger utanför omfånget av ett medvetet val: det finns gott om utmärkta SAST-verktyg som fungerar tillsammans med CRACI. Se SAST vs SCA för hur de två sortens fynd skiljer sig åt.

Verktyg som granskar det du inte byggde

Binär- och firmwareanalys av leverantörers binärer, skannrar för images du hämtar men aldrig bygger och DAST mot körande tjänster tittar alla på något som byggdes någon annanstans eller redan körs. CRACI registrerar byggen; en binär som kommer från en leverantör byggdes någonstans som CRACI aldrig såg. Om leverantören ger dig en SBOM kan CRACI bevaka den tillsammans med dina egna byggen.

Nåbarhetsbaserad prioritering läser din anropsgraf, som CRACI inte analyserar. Behåll den om du förlitar dig på den; se nåbarhetsanalys för vad den kan och inte kan säga dig.

Processystem

Ärendehantering, hantering av PSIRT-ärenden, publicering av säkerhetsbulletiner och plattformar för compliance-automatisering driver din process över många system. CRACI skickar fynd till teamet som äger dem och håller evidensen från bygget; behåll dina processverktyg för resten. Registreringar lämnar CRACI som CycloneDX- eller SPDX-SBOM:er och via API:et, som returnerar SBOM:er, nätverksspår och provenance-data. För revisionssidan, se SBOM-kontroller för SOC 2. För licensarbete utöver deklarerade licenser, som attributionstexter och granskning av fulltext, se licensefterlevnad för öppen källkod. CRACI för med varje komponents deklarerade licens och upprätthåller regler för licenspolicy, inklusive att blockera ett bygge på grund av en licens.

Så hittar du var bytet sker i din egen stack

Fem frågor du kan besvara på en eftermiddag. Varje svar visar om en rad i din stack flyttar.

1. Körs dina byggen på GitHub Actions på Linux? Om ja, flyttar runnerna. Om inte, ersätter CRACI ingenting i dag.
2. Vem tar fram SBOM:er i dag, och hur många olika generatorer används? Varje generator i ett repositorium som du flyttar till CRACI är en rad som försvinner.
3. Bygger du Yocto-images? Om ja, kontrollera om någon förlitar sig på de tillämpade patcharna och åtgärdade CVE:erna i utdata från create-spdx innan du stänger av det.
4. Vart tar SBOM:erna vägen när de har tagits fram: ett spårningsverktyg, ett kalkylark, ingenstans? Det verktyget eller den processen är den andra raden som försvinner, om du inte behöver nåbarhet eller åtgärdsmått därifrån.
5. Vilka av dina säkerhetsverktyg läser kod, repositorier eller tredjepartsbinärer? De stannar. Skriv ner dem, så att ingen förväntar sig att CRACI ska ersätta dem.

Ett genomräknat exempel

En påhittad enhetstillverkare, inte baserad på något verkligt företag: Linux-byggen på GitHub-hostade runners, två team som använder två olika SBOM-generatorer, en Yocto-produktlinje med create-spdx påslaget, SBOM:er samlade i ett delat kalkylark, en kodskanningssvit och ett ärendehanteringssystem. Säkerhetsteamet svarar ja på fråga 1 och 3, hittar två generatorer på fråga 2 och ett kalkylark på fråga 4, och listar kodskanning, hemlighetsskanning och ärendehanteringssystemet på fråga 5. Ingen använder patchmetadatan i Yoctos SPDX.

Flyttar till CRACI	Stannar
GitHub-hostade runners för Linux-jobben	Kodskanning, som ett steg på CRACI-runners
Båda SBOM-generatorerna	Hemlighetsskanning
create-spdx, eftersom ingen behöver dess patchmetadata	Ärendehanteringssystemet
SBOM-kalkylarket

På runnerraden kostar ett bygge på 10 minuter, som kostar $0.060 på en GitHub-hostad x64-runner med 2 kärnor, cirka $0.020 på CRACI med den högre hastigheten. De andra verktygens kostnader får företaget fylla i själv.

När CRACI inte är svaret

• Dina pipelines körs på GitLab CI, Jenkins, Azure DevOps eller ett annat CI-system. CRACI stöder bara GitHub Actions i dag, med GitLab CI och Jenkins på roadmapen, så det ersätter ingenting ännu.
• Dina byggen behöver Windows- eller macOS-runners eller GitHub Enterprise Server, eller måste köras på din egen infrastruktur.
• Ditt största problem är brus från kodskanning i din egen kod. Det är en fråga om att finjustera SAST; se SAST vs SCA och så minskar du bruset kring sårbarheter.
• Din största risk är firmware och binärer du får från leverantörer, inte kod du bygger.
• Din stack består mest av Java och Maven, som finns på roadmapen, eller .NET, som inte finns i listan över ekosystem som CRACI registrerar.
• Du behöver nåbarhetsbaserad prioritering eller hantering av PSIRT-ärenden redan i dag.

För en steg-för-steg-bild av produkten, se så fungerar CRACI; för själva SBOM:en, SBOM-generering.

Vad CRACI ersätter: vanliga frågor

Vad ersätter CRACI?

Dina GitHub Actions-runners för Linux-jobb, SBOM-generatorerna som team kör i CI för byggen som flyttar till CRACI, Yoctos create-spdx för täckning av leveranskedjan, egress-agenter på runners och fristående sårbarhetsspårning utifrån SBOM:er för de byggena. Det ersätter inte verktyg som läser din kod, dina repositorier eller tredjepartsbinärer.

Är CRACI ett tillägg till vårt SCA-verktyg, eller ersätter det något?

Det ersätter uppgifter i byggledet: runnern, SBOM-genereringen och spårningen som följer av SBOM:en. Om det ersätter ditt SCA-verktyg beror på vad du använder det till. Om det läser din kod, gör snippet- eller binäranalys eller ger dig nåbarhet, stannar de delarna.

Behöver vi fortfarande vår SBOM-generator om vi kör byggen på CRACI?

Inte för byggen som körs på CRACI och använder ekosystem som det registrerar. CRACI registrerar paketen som varje jobb hämtade och exporterar SBOM:en som CycloneDX eller SPDX. Behåll en generator för mjukvara du inte bygger på CRACI, till exempel images du hämtar, och för ekosystem som CRACI inte registrerar ännu, till exempel Maven.

Behöver vi fortfarande Yoctos inbyggda SBOM-generering (create-spdx)?

För täckning av leveranskedjan, nej: i ett jämförande core-image-sato-bygge sida vid sida hade CRACI:s SBOM alla komponenter som Yoctos hade, plus 88 som den missade, och bygget utan create-spdx tog 43 % kortare tid. Låt create-spdx vara på om du förlitar dig på dess tillämpade patchar och CVE:er markerade som åtgärdade, som CRACI inte registrerar.

Ersätter CRACI kodskanning eller hemlighetsskanning?

Nej. CRACI läser inte din källkod eller dina commits efter brister eller hemligheter. Behåll de verktygen. Kodskanningssteg körs oförändrade i ditt workflow på en CRACI-runner, och funktioner på repositorienivå påverkas inte.

Ersätter CRACI binär- eller firmwareanalys?

Nej. CRACI registrerar de byggen det kör. För firmware och binärer du får från leverantörer är binäranalys rätt verktyg. Om en leverantör ger dig en SBOM kan CRACI bevaka den tillsammans med dina egna byggen.

Kan vi behålla våra befintliga säkerhetssteg i GitHub Actions på CRACI-runners?

Ja. CRACI ersätter runnern, inte GitHub Actions: du sätter runs-on till craci och dina workflows, steg och resultat stannar i GitHub. Skanningssteg, teststeg och alla andra steg fortsätter att köras som förut.