Hvad CRACI erstatter i din stak, og hvad den supplerer

Det korte svar: hvad flytter, og hvad bliver

Kortlæg din egen stak med denne tabel. Hver række er en opgave, et værktøj i din stak løser i dag, hvad opgaven skal kunne se for at blive løst, og om CRACI løser den fra den plads, den har.

Opgave i din stak	Hvad opgaven skal kunne se	CRACI	Hvad du beholder, og hvorfor
CI-runnere til Linux-jobs på GitHub Actions: GitHub-hostede, fra en tredjepartsudbyder eller en selvhostet flåde	Et sted at køre jobbet	Erstatter	Runnere til Windows, macOS, GitHub Enterprise Server og andre CI-systemer end GitHub Actions, som CRACI ikke understøtter i dag
Netværksovervågning eller egress-agenter tilføjet til runnere, du beholder	Jobbets udgående trafik	Erstatter på CRACI-runnere	Agenter på runnere, du beholder andre steder
SBOM-generatorer kørt i CI, team for team: manifest-, lockfile- eller image-scannere brugt til at lave SBOM'er	Hvad buildet faktisk hentede	Erstatter for builds på CRACI	Generatorer til software, du ikke bygger på CRACI, f.eks. images, du henter og aldrig bygger
Yoctos indbyggede SBOM-generering (create-spdx) til dækning af forsyningskæden	Hver kilde og hvert værktøj, BitBake-buildet hentede	Erstatter for dækning af forsyningskæden	create-spdx, hvis du er afhængig af dens recipe-metadata: anvendte patches og CVE'er markeret som rettet
Sårbarhedssporing baseret på SBOM'er: upload SBOM'er, match advisories, hold øje med nye	En præcis SBOM pr. release, holdt opdateret	Erstatter for builds på CRACI; leverandørers SBOM'er kan tilføjes	Et dedikeret værktøj, hvis du har brug for noget, CRACI ikke gør: reachability, afhjælpningsmålinger som MTTR eller frister pr. alvorlighed
SBOM'er og komponentlister i regneark	En præcis SBOM pr. release, holdt opdateret	Erstatter	Intet
Kontrol af deklarerede licenser og licenspolitik	Hver komponents deklarerede licens	Delvist	Licensscanning af fuld tekst og på snippet-niveau, attributionsnoter
SAST og kodescanning	Din kildekode	Supplerer	Behold det; det kører uændret som et workflow-trin på en CRACI-runner
Scanning for hemmeligheder og push protection	Dit repository og dine commits	Supplerer	Behold det
DAST og API-test	Din kørende tjeneste	Supplerer	Behold det
Binær- og firmwareanalyse af tredjepartsbinærfiler	En færdig binærfil, du ikke selv har bygget	Supplerer	Behold det
Snippet- og signaturscanning efter kopieret eller vendoret kode	Filindhold i repositoryet	Supplerer	Behold det
Prioritering baseret på reachability	Din kaldgraf	Supplerer	Behold det, hvis du er afhængig af det
Scanning af IaC, clustere og fejlkonfigurationer	Konfiguration og kørende infrastruktur	Supplerer	Behold det
CI/CD-posturetjek af workflow-konfiguration	Workflow-filer og indstillinger	Supplerer	Behold det
Ticketing, PSIRT-sagsstyring, udgivelse af advisories	Din proces	Supplerer	Behold det
Compliance-automatisering: indsamling af dokumentation til SOC 2- eller ISO 27001-audits	Dine kontroller på tværs af systemer	Supplerer	Behold det; CRACI's registreringer er dokumentation, det kan indsamle

Før og efter

Før: GitHub-hostede runnere, en ny SBOM-generator i hvert teams workflow, Yoctos create-spdx, der forlænger buildtiden, og SBOM'er uploadet til et sporingsværktøj eller et regneark, med kodescanning, scanning for hemmeligheder, binæranalyse og ticketing omkring dem. Efter: CRACI-runnere, der kører hvert job, håndhæver dets egress-politik, registrerer dets SBOM og holder den under overvågning. De værktøjer, der læser kode, repositories, binærfiler og din proces, er uændrede.

Hvad CRACI erstatter, og hvorfor

Hver af disse opgaver sker under buildet. CRACI kan overtage dem, fordi det er der, buildet kører. For hver af dem: mekanismen, hvad du giver afkald på, og et eksempel.

Dine runnere

CRACI er en runner til GitHub Actions. Du ændrer runs-on til craci, og kørslerne vises stadig i GitHub som ethvert andet Actions-job. Hvert job får sin egen virtuelle maskine, på Linux x86-64 eller ARM64, i en størrelse fra 1 til 32 vCPU'er, målt pr. sekund. Der skal ikke skrives workflows om: dine eksisterende trin, også scanningstrin, kører videre.

CRACI tager kun betaling for buildminutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU'er), målt pr. sekund, uden månedligt gebyr og uden betaling pr. SBOM. Det gør den til en af de mest prisvenlige CI-runnere. Den kører builds omkring dobbelt så hurtigt som GitHub-hostede runnere takket være hurtigere hardware, kortere køtider og caching.

Runner, pr. minut	CRACI	GitHub-hostet	Forskel
2 vCPU x64	$0.004	$0.006	CRACI omkring 33% billigere
2 vCPU ARM64	$0.004	$0.005	CRACI 20% billigere
32 vCPU x64	$0.064	$0.082	CRACI omkring 22% billigere
32 vCPU ARM64	$0.064	$0.050	CRACI 28% dyrere

GitHubs listepriser pr. september 2026. GitHub runder hvert job op til et helt minut; CRACI måler pr. sekund. Eksempel: et build på 10 minutter på en GitHub-hostet 2-core x64-runner koster $0.060. Ved omkring dobbelt hastighed tager det 5 minutter på en CRACI-runner med 2 vCPU'er og koster $0.020, omkring 67 % mindre. Se priser og priser på CI-runnere.

Hvad du giver afkald på. Windows- og macOS-runnere, andre CI-systemer og kundehostede runnere er ikke tilgængelige i dag; GitLab CI, Jenkins, Windows, macOS og kundehostede runnere er på roadmappen. GitHub Enterprise Server understøttes ikke. Runnerne er administrerede og kører på europæisk infrastruktur. Hvis du afvejer administrerede runnere mod din egen flåde, så se administrerede vs selvhostede runnere.

Egress-agenter på runnere, du beholder

En egress-agent overvåger eller begrænser trafikken fra en runner, som en anden driver. På CRACI håndhæver runneren selv egress-politikken: standard deny eller allow, 24 indbyggede forudindstillinger for softwarekilder, typede brugerdefinerede kilder til pakkeregistre og Git samt eksplicitte netværksregler. Politikken valideres, før jobbet starter, og fejler lukket, og CRACI advarer om overtrædelser af politikken. En separat agent er ikke nødvendig på CRACI-runnere.

Eksempel: en kompromitteret afhængighed forsøger at sende jobbets hemmeligheder til en host, buildet aldrig har haft brug for. Med en default-deny-politik blokeres forbindelsen, selv ved et angreb, ingen har set før, fordi politikken kun tillader det, buildet har brug for, i stedet for at lede efter kendte ondsindede hosts.

Hvad du giver afkald på. Politikken dækker jobs på CRACI-runnere. Runnere, du beholder andre steder, har stadig brug for deres egen kontrol.

SBOM-generatoren i hvert teams workflow

En generator læser de filer, den har foran sig, f.eks. et manifest, en lockfile eller et image, og rekonstruerer, hvad der gik ind. Forskellige generatorer returnerer forskellige lister fra samme checkout, og teams vælger som regel deres egen, så organisationen ender med flere fortegnelser, der ikke stemmer overens.

CRACI registrerer de pakker, hvert job faktisk hentede, inklusive pakker gendannet fra CI-caches, og de skjulte afhængigheder, som lockfile-baserede værktøjer overser: kode downloadet af npm install-hooks, Rust-build-scripts, der downloader under buildet, og base-imaget med dets styresystemlag i et container-build. Hver komponent i SBOM'en var med i buildet. Hvert jobs SBOM angiver sin fuldstændighed som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så et hul er synligt i stedet for skjult. Resultatet er én fortegnelse for hvert repository, der bygger på CRACI, eksporteret som CycloneDX eller SPDX. Økosystemer, der registreres i dag: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt Yocto- og OpenEmbedded-downloads.

Eksempel: expressjs/express 5.2.1 committer ingen lockfile. En generator, der opløser afhængigheder ud fra lockfiles, har intet at opløse der og kan alligevel returnere et dokument, der ikke nævner én eneste af de npm-afhængigheder, der er deklareret i package.json. Et build af samme projekt på CRACI registrerer de pakker, npm install hentede. Mere om metoden i SBOM'er fra buildtidspunktet og SCA- og SBOM-værktøjer sammenlignet; for en gør-det-selv-stak af generatorer, se gør-det-selv-SBOM-stakken.

Hvad du giver afkald på. Økosystemer, som CRACI endnu ikke registrerer. Maven og Java er på roadmappen, og alt, der ikke står på listen ovenfor, er ikke dækket. Behold en generator til de builds.

Yoctos indbyggede SBOM-generering

Yocto skriver sin egen SPDX-SBOM via create-spdx, og den er grundig med det, BitBake bygger. Den kan ikke se, hvad der sker uden for BitBakes metadata. CRACI kører BitBake-buildet og registrerer, hvad det hentede. I et sammenlignende build af core-image-sato på en native ARM64-runner med 32 vCPU'er havde CRACI's SBOM hver komponent, som Yoctos SBOM havde, plus 88, den overså: 23 host-pakker på build-maskinen, 10 GitHub-kilder, herunder GitHub Action'en actions/upload-artifact, og 55 andre kilder og værktøjer hentet under buildet. Den registrerede alle 653 Rust-crate-versioner med pkg:cargo-pakke-URL'er, så de kan matches mod advisories. Buildet uden Yoctos SBOM-generering tog 43 % kortere tid: omkring $9.96 mod $5.68 pr. build til CRACI's pris.

Hvad du giver afkald på. Yoctos SPDX indeholder recipe-metadata, som CRACI ikke registrerer: de anvendte patches og de CVE'er, der er markeret som rettet. Hvis du er afhængig af dem, så lad create-spdx være slået til. Metoden og den fulde sammenligning findes på Yocto-builds på CRACI.

Fra SBOM'er til sårbarhedssporing

Et selvstændigt sporingsværktøj skal fodres med en SBOM og stoler på det, det får. CRACI producerer SBOM'en og opbevarer registreringen. Overvågede SBOM'er revurderes løbende, efterhånden som nye advisories udgives. Build-historikken viser, hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du kender den periode, du var berørt, inden for din plans opbevaringsperiode. Fund triageres til det team, der ejer rettelsen, CRACI underretter de relevante personer om en sårbarhed og dens alvorlighed, og policy gates kan blokere et build på grund af fund, herunder et build, der indeholder en bestemt CVE. VEX understøttes. Leverandørers SBOM'er kan tilføjes, så indkøbte komponenter overvåges sammen med dine egne builds.

Eksempel: der udgives en advisory for en crate, som en af dine tjenester kompilerede ind for tre måneder siden. CRACI matcher den mod hver overvåget SBOM og viser, hvilke builds der indeholdt den version, uden at nogen skal uploade noget igen.

Hvad du giver afkald på. CRACI tilbyder ikke reachability-analyse eller afhjælpningsmålinger som MTTR, frister pr. alvorlighed eller backlog-tendenser. Hvis du er afhængig af dem, så behold det værktøj, der leverer dem. Se sårbarhedssporing for hele funktionaliteten.

Regnearket

For teams uden SBOM-værktøjer er det, CRACI erstatter, manuelt sammenstykningsarbejde: nogen kopierer afhængighedslister ind i et regneark før en release eller en audit. Et build på CRACI producerer SBOM'en som en bivirkning af kørslen, så listen findes for hvert build, ikke kun for dem, nogen huskede.

Hvad CRACI supplerer, og hvordan

Disse værktøjer læser ting, som CRACI aldrig læser. CRACI læser ikke din kildekode for fejl, tester ikke kørende tjenester og analyserer ikke binærfiler, den ikke selv har bygget. De kører videre, som de gør nu.

Værktøjer, der læser din kode og dit repository

SAST, scanning for hemmeligheder og push protection, snippet- og signaturscanning, IaC-scanning og CI/CD-posturetjek undersøger alle din kode, dine commits eller din konfiguration. Trin i dit workflow kører uændret på en CRACI-runner, og funktioner på repository-niveau påvirkes ikke, fordi de aldrig kørte på runneren. Et kodescanningstrin kan ligge i samme job som dit build. SAST er bevidst uden for scope: der findes masser af fremragende SAST-værktøjer, der fungerer sammen med CRACI. Se SAST vs SCA for, hvordan de to slags fund adskiller sig.

Værktøjer, der undersøger det, du ikke selv har bygget

Binær- og firmwareanalyse af leverandørers binærfiler, scannere til images, du henter, men aldrig bygger, og DAST mod kørende tjenester ser alle på noget, der er bygget andetsteds eller allerede kører. CRACI registrerer builds; en binærfil, der kommer fra en leverandør, er bygget et sted, CRACI aldrig har set. Hvis leverandøren giver dig en SBOM, kan CRACI overvåge den sammen med dine egne builds.

Prioritering baseret på reachability læser din kaldgraf, som CRACI ikke analyserer. Behold den, hvis du er afhængig af den; se reachability-analyse for, hvad den kan og ikke kan fortælle dig.

Processystemer

Ticketing, PSIRT-sagsstyring, udgivelse af advisories og platforme til compliance-automatisering styrer din proces på tværs af mange systemer. CRACI sender fund til det ansvarlige team og opbevarer dokumentationen fra buildet; behold dine procesværktøjer til resten. Registreringer forlader CRACI som CycloneDX- eller SPDX-SBOM'er og via API'et, der returnerer SBOM'er, netværkssporinger og provenance-data. For audit-siden, se SBOM-tjek til SOC 2. For licensarbejde ud over deklarerede licenser, f.eks. noter og gennemgang af fuld tekst, se licensoverholdelse for open source. CRACI medtager hver komponents deklarerede licens og håndhæver regler for licenspolitik, herunder blokering af et build på grund af en licens.

Sådan finder du skillelinjen i din egen stak

Fem spørgsmål, du kan besvare på en eftermiddag. Hvert svar fortæller dig, om en linje i din stak flytter.

1. Kører dine builds på GitHub Actions på Linux? Hvis ja, flytter runnerne. Hvis ikke, erstatter CRACI intet i dag.
2. Hvem genererer SBOM'er i dag, og hvor mange forskellige generatorer er i brug? Hver generator på et repository, du flytter til CRACI, er en linje, der forsvinder.
3. Bygger du Yocto-images? Hvis ja, så tjek, om nogen er afhængige af de anvendte patches og rettede CVE'er i output fra create-spdx, før du slår den fra.
4. Hvor ender SBOM'erne, når de er genereret: i et sporingsværktøj, et regneark, ingen steder? Det værktøj eller den proces er den anden linje, der forsvinder, medmindre du har brug for reachability eller afhjælpningsmålinger fra den.
5. Hvilke af dine sikkerhedsværktøjer læser kode, repositories eller tredjepartsbinærfiler? De bliver. Skriv dem ned, så ingen forventer, at CRACI erstatter dem.

Et gennemregnet eksempel

En illustrativ enhedsproducent, ikke baseret på nogen virkelig virksomhed: Linux-builds på GitHub-hostede runnere, to teams, der bruger to forskellige SBOM-generatorer, en Yocto-produktlinje med create-spdx slået til, SBOM'er samlet i et delt regneark, en kodescanningssuite og et ticketsystem. Sikkerhedsteamet svarer ja til spørgsmål 1 og 3, finder to generatorer til spørgsmål 2 og et regneark til spørgsmål 4 og nævner kodescanning, scanning for hemmeligheder og ticketsystemet til spørgsmål 5. Ingen bruger patch-metadataene i Yoctos SPDX.

Flytter til CRACI	Bliver
GitHub-hostede runnere til Linux-jobs	Kodescanning, kørt som et trin på CRACI-runnere
Begge SBOM-generatorer	Scanning for hemmeligheder
create-spdx, da ingen har brug for dens patch-metadata	Ticketsystemet
SBOM-regnearket

På runnerlinjen koster et build på 10 minutter, der koster $0.060 på en GitHub-hostet 2-core x64-runner, omkring $0.020 på CRACI med hastighedsforøgelsen. De andre værktøjers omkostninger må virksomheden selv udfylde.

Når CRACI ikke er svaret

• Dine pipelines kører på GitLab CI, Jenkins, Azure DevOps eller et andet CI-system. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen, så den erstatter intet endnu.
• Dine builds kræver Windows- eller macOS-runnere eller GitHub Enterprise Server eller skal køre på din egen infrastruktur.
• Dit største problem er støj fra kodescanning i din egen kode. Det er et spørgsmål om at tune SAST; se SAST vs SCA og sådan reducerer du støj fra sårbarheder.
• Din største risiko er firmware og binærfiler, du modtager fra leverandører, ikke kode, du selv bygger.
• Din stak er primært Java og Maven, som er på roadmappen, eller .NET, som ikke er på listen over økosystemer, CRACI registrerer.
• Du har brug for prioritering baseret på reachability eller PSIRT-sagsstyring i dag.

For et trin-for-trin-overblik over produktet, se sådan fungerer CRACI; for selve SBOM'en, SBOM-generering.

Hvad CRACI erstatter: ofte stillede spørgsmål

Hvad erstatter CRACI?

Dine GitHub Actions-runnere til Linux-jobs, de SBOM-generatorer, teams kører i CI, for builds, der flytter til CRACI, Yoctos create-spdx til dækning af forsyningskæden, egress-agenter på runnere og selvstændig sårbarhedssporing baseret på SBOM'er for de builds. Den erstatter ikke værktøjer, der læser din kode, dine repositories eller tredjepartsbinærfiler.

Er CRACI en tilføjelse til vores SCA-værktøj, eller erstatter den noget?

Den erstatter opgaver i build-laget: runneren, SBOM-genereringen og den sporing, der følger af SBOM'en. Om det fortrænger dit SCA-værktøj, afhænger af, hvad du bruger det til. Hvis det læser din kode, laver snippet- eller binæranalyse eller giver dig reachability, bliver de dele.

Har vi stadig brug for vores SBOM-generator, hvis vi kører builds på CRACI?

Ikke til builds, der kører på CRACI og bruger de økosystemer, den registrerer. CRACI registrerer de pakker, hvert job hentede, og eksporterer SBOM'en som CycloneDX eller SPDX. Behold en generator til software, du ikke bygger på CRACI, f.eks. images, du henter, og til økosystemer, CRACI endnu ikke registrerer, f.eks. Maven.

Har vi stadig brug for Yoctos indbyggede SBOM-generering (create-spdx)?

Til dækning af forsyningskæden nej: i et sammenlignende core-image-sato-build havde CRACI's SBOM hver komponent, som Yoctos havde, plus 88, den overså, og buildet uden create-spdx tog 43 % kortere tid. Lad create-spdx være slået til, hvis du er afhængig af dens anvendte patches og CVE'er markeret som rettet, som CRACI ikke registrerer.

Erstatter CRACI kodescanning eller scanning for hemmeligheder?

Nej. CRACI læser ikke din kildekode eller dine commits for fejl eller hemmeligheder. Behold de værktøjer. Kodescanningstrin kører uændret i dit workflow på en CRACI-runner, og funktioner på repository-niveau påvirkes ikke.

Erstatter CRACI binær- eller firmwareanalyse?

Nej. CRACI registrerer de builds, den kører. Til firmware og binærfiler, du modtager fra leverandører, er binæranalyse det rette værktøj. Hvis en leverandør giver dig en SBOM, kan CRACI overvåge den sammen med dine egne builds.

Kan vi beholde vores eksisterende sikkerhedstrin i GitHub Actions på CRACI-runnere?

Ja. CRACI erstatter runneren, ikke GitHub Actions: du sætter runs-on til craci, og dine workflows, trin og resultater bliver i GitHub. Scanningstrin, testtrin og alle andre trin kører videre som før.