Wat CRACI in uw stack vervangt, en waar het naast werkt

Het korte antwoord: wat verhuist en wat blijft

Breng uw eigen stack in kaart met deze tabel. Elke rij is een taak die een tool in uw stack vandaag uitvoert, wat die taak moet kunnen zien, en of CRACI die taak vanuit zijn positie uitvoert.

Taak in uw stack	Wat de taak moet zien	CRACI	Wat u houdt, en waarom
CI-runners voor Linux-jobs op GitHub Actions: door GitHub gehost, van een externe runneraanbieder of een eigen self-hosted vloot	Een plek om de job te draaien	Vervangt	Runners voor Windows, macOS, GitHub Enterprise Server en andere CI-systemen dan GitHub Actions, die CRACI vandaag niet ondersteunt
Netwerkmonitoring of egress-agents op runners die u houdt	Het uitgaande verkeer van de job	Vervangt op CRACI-runners	Agents op runners die u elders houdt
SBOM-generators in CI, team voor team: manifest-, lockfile- of imagescanners waarmee SBOM's worden gemaakt	Wat de build daadwerkelijk heeft binnengehaald	Vervangt voor builds op CRACI	Generators voor software die u niet op CRACI bouwt, zoals images die u ophaalt en nooit zelf bouwt
De ingebouwde SBOM-generatie van Yocto (create-spdx) voor de dekking van de softwareketen	Elke bron en elke tool die de BitBake-build heeft opgehaald	Vervangt voor de dekking van de softwareketen	create-spdx, als u op de recept-metadata ervan vertrouwt: toegepaste patches en CVE's die als opgelost zijn gemarkeerd
Kwetsbaarheden volgen op basis van SBOM's: SBOM's uploaden, advisories matchen, nieuwe in de gaten houden	Een nauwkeurige, actuele SBOM per release	Vervangt voor builds op CRACI; SBOM's van leveranciers kunnen worden toegevoegd	Een gespecialiseerde tool als u nodig hebt wat CRACI niet doet: reachability, herstelmetrics zoals MTTR of deadlines per ernst
SBOM's en componentlijsten in spreadsheets	Een nauwkeurige, actuele SBOM per release	Vervangt	Niets
Controles op gedeclareerde licenties en licentiebeleid	De gedeclareerde licentie van elk component	Deels	Licentiescans op volledige tekst en op fragmentniveau, attributievermeldingen
SAST en codescanning	Uw broncode	Werkt ernaast	Houden; het draait ongewijzigd als workflowstap op een CRACI-runner
Secretscanning en pushbeveiliging	Uw repository en commits	Werkt ernaast	Houden
DAST en API-tests	Uw draaiende service	Werkt ernaast	Houden
Binaire en firmware-analyse van binaries van derden	Een afgewerkte binary die u niet zelf hebt gebouwd	Werkt ernaast	Houden
Fragment- en signatuurscanning voor gekopieerde of meegeleverde code	Bestandsinhoud in de repository	Werkt ernaast	Houden
Prioritering op basis van reachability	Uw call graph	Werkt ernaast	Houden als u erop vertrouwt
Scanning van IaC, clusters en misconfiguraties	Configuratie en draaiende infrastructuur	Werkt ernaast	Houden
CI/CD-posturecontroles op de workflowconfiguratie	Workflowbestanden en instellingen	Werkt ernaast	Houden
Ticketing, PSIRT-casemanagement, publicatie van advisories	Uw proces	Werkt ernaast	Houden
Compliance-automatisering: bewijs verzamelen voor SOC 2- of ISO 27001-audits	Uw controls over systemen heen	Werkt ernaast	Houden; de vastleggingen van CRACI zijn bewijs dat het kan verzamelen

Voor en na

Voor: door GitHub gehoste runners, in de workflow van elk team een andere SBOM-generator, create-spdx van Yocto dat buildtijd kost, en SBOM's die naar een tracker of een spreadsheet worden geüpload, met codescanning, secretscanning, binaire analyse en ticketing eromheen. Na: CRACI-runners die elke job uitvoeren, het egressbeleid ervan afdwingen, de SBOM ervan vastleggen en die gemonitord houden. De tools die code, repositories, binaries en uw proces lezen, blijven ongewijzigd.

Wat CRACI vervangt, en waarom

Elk van deze taken vindt plaats tijdens de build. CRACI kan ze overnemen omdat de build daar draait. Per taak: het mechanisme, wat u opgeeft, en een voorbeeld.

Uw runners

CRACI is een runner voor GitHub Actions. U wijzigt runs-on in craci, en de runs verschijnen nog steeds in GitHub zoals elke andere Actions-job. Elke job krijgt een eigen virtuele machine, op Linux x86-64 of ARM64, met een grootte van 1 tot 32 vCPU's, per seconde afgerekend. U hoeft geen workflow te herschrijven: uw bestaande stappen, scanstappen inbegrepen, blijven draaien.

CRACI rekent alleen buildminuten: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU's), per seconde afgerekend, zonder maandelijkse kosten en zonder kosten per SBOM. Daarmee is het een van de voordeligste CI-runners. Builds draaien ongeveer twee keer zo snel als op door GitHub gehoste runners, dankzij snellere hardware, kortere wachtrijen en caching.

Runner, per minuut	CRACI	Door GitHub gehost	Verschil
2 vCPU x64	$0.004	$0.006	CRACI ongeveer 33% goedkoper
2 vCPU ARM64	$0.004	$0.005	CRACI 20% goedkoper
32 vCPU x64	$0.064	$0.082	CRACI ongeveer 22% goedkoper
32 vCPU ARM64	$0.064	$0.050	CRACI 28% duurder

Catalogusprijzen van GitHub per september 2026. GitHub rondt elke job af naar boven op een hele minuut; CRACI rekent per seconde af. Voorbeeld: een build van 10 minuten op een door GitHub gehoste x64-runner met 2 cores kost $0.060. Bij ongeveer dubbele snelheid duurt die op een CRACI-runner met 2 vCPU's 5 minuten en kost hij $0.020, ongeveer 67% minder. Zie prijzen en prijzen van CI-runners.

Wat u opgeeft. Windows- en macOS-runners, andere CI-systemen en door de klant gehoste runners zijn vandaag niet beschikbaar; GitLab CI, Jenkins, Windows, macOS en door de klant gehoste runners staan op de roadmap. GitHub Enterprise Server wordt niet ondersteund. De runners worden beheerd, op Europese infrastructuur. Weegt u beheerde runners af tegen uw eigen vloot, lees dan beheerde vs. self-hosted runners.

Egress-agents op runners die u houdt

Een egress-agent bewaakt of beperkt het verkeer van een runner die iemand anders beheert. Op CRACI dwingt de runner zelf het egressbeleid af: standaard weigeren of toestaan, 24 ingebouwde presets voor softwarebronnen, getypeerde eigen bronnen voor pakketregistries en Git, en expliciete netwerkregels. Het beleid wordt gevalideerd voordat de job start en faalt gesloten (fail closed), en CRACI waarschuwt bij beleidsschendingen. Een aparte agent is op CRACI-runners niet nodig.

Voorbeeld: een gecompromitteerde afhankelijkheid probeert de secrets van de job te versturen naar een host die de build nooit nodig heeft gehad. Met een default-deny-beleid wordt de verbinding geblokkeerd, zelfs bij een aanval die nog niemand eerder heeft gezien, omdat het beleid alleen toestaat wat de build nodig heeft in plaats van te zoeken naar bekende kwaadaardige hosts.

Wat u opgeeft. Het beleid geldt voor jobs op CRACI-runners. Runners die u elders houdt, hebben nog steeds hun eigen controle nodig.

De SBOM-generator in de workflow van elk team

Een generator leest de bestanden die voor hem liggen, zoals een manifest, een lockfile of een image, en reconstrueert wat erin is gegaan. Verschillende generators geven uit dezelfde checkout verschillende lijsten, en teams kiezen meestal hun eigen generator. Zo eindigt de organisatie met meerdere inventarissen die niet op elkaar aansluiten.

CRACI legt de pakketten vast die elke job daadwerkelijk heeft binnengehaald, inclusief pakketten die uit CI-caches zijn teruggezet, en de verborgen afhankelijkheden die op lockfiles gebaseerde tools missen: code die npm-installhooks downloaden, Rust-buildscripts die tijdens de build downloaden, en het basisimage met zijn besturingssysteemlagen in een containerbuild. Elk component in de SBOM zat in de build. De SBOM van elke job vermeldt zijn volledigheid, als Complete, Complete with connections, Incomplete, Unavailable of Not recorded, zodat een gat zichtbaar is in plaats van onopgemerkt te blijven. Het resultaat is één inventaris voor elke repository die op CRACI bouwt, geëxporteerd als CycloneDX of SPDX. Ecosystemen die vandaag worden vastgelegd: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloads van Yocto en OpenEmbedded.

Voorbeeld: expressjs/express 5.2.1 commit geen lockfile. Een generator die afhankelijkheden uit lockfiles resolvet, heeft daar niets te resolven en kan toch een document opleveren dat geen enkele van de npm-afhankelijkheden uit package.json vermeldt. Een build van hetzelfde project op CRACI legt de pakketten vast die npm install heeft opgehaald. Meer over de methode in SBOM's tijdens de build en SCA- en SBOM-tools vergeleken; voor een zelfgebouwde generatorstack, zie de DIY-SBOM-stack.

Wat u opgeeft. Ecosystemen die CRACI nog niet vastlegt. Maven en Java staan op de roadmap, en alles wat niet in de lijst hierboven staat, wordt niet gedekt. Houd voor die builds een generator.

De ingebouwde SBOM-generatie van Yocto

Yocto schrijft via create-spdx een eigen SPDX-SBOM, en die is grondig in wat BitBake bouwt. Wat buiten de metadata van BitBake gebeurt, ziet het niet. CRACI voert de BitBake-build uit en legt vast wat die heeft opgehaald. In een vergelijkende build van core-image-sato naast elkaar, op een native ARM64-runner met 32 vCPU's, bevatte de SBOM van CRACI elk component uit de SBOM van Yocto, plus 88 die daarin ontbraken: 23 hostpakketten op de buildmachine, 10 GitHub-bronnen, waaronder de GitHub Action actions/upload-artifact, en 55 andere bronnen en tools die tijdens de build zijn opgehaald. Alle 653 versies van Rust-crates werden vastgelegd met pkg:cargo-package URL's, zodat ze tegen advisories kunnen worden gematcht. De build zonder de SBOM-generatie van Yocto duurde 43% korter: ongeveer $9.96 tegenover $5.68 per build tegen de prijs van CRACI.

Wat u opgeeft. De SPDX van Yocto bevat recept-metadata die CRACI niet vastlegt: de toegepaste patches en de CVE's die als opgelost zijn gemarkeerd. Vertrouwt u daarop, laat create-spdx dan aanstaan. De methode en de volledige vergelijking staan op Yocto-builds op CRACI.

Van SBOM's naar het volgen van kwetsbaarheden

Een losse tracker moet met een SBOM worden gevoed en vertrouwt op wat hij krijgt. CRACI maakt de SBOM en houdt de vastlegging bij. Gemonitorde SBOM's worden continu opnieuw beoordeeld zodra er nieuwe advisories verschijnen. De buildgeschiedenis laat zien welke builds een kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u getroffen was, binnen de bewaartermijn van uw abonnement. Bevindingen worden toegewezen aan het team dat de fix bezit, CRACI informeert de betrokken mensen over een kwetsbaarheid en de ernst ervan, en policy gates kunnen een build blokkeren op basis van bevindingen, ook een build die een specifieke CVE bevat. VEX wordt ondersteund. SBOM's van leveranciers kunnen worden toegevoegd, zodat ingekochte componenten naast uw eigen builds worden gemonitord.

Voorbeeld: er verschijnt een advisory voor een crate die een van uw services drie maanden geleden heeft meegecompileerd. CRACI matcht die tegen elke gemonitorde SBOM en laat zien welke builds die versie bevatten, zonder dat iemand opnieuw iets uploadt.

Wat u opgeeft. CRACI biedt geen reachability-analyse en geen herstelmetrics zoals MTTR, deadlines per ernst of backlogtrends. Bent u daarvan afhankelijk, houd dan de tool die ze levert. Zie het volgen van kwetsbaarheden voor de volledige functionaliteit.

De spreadsheet

Voor teams zonder SBOM-tooling vervangt CRACI het handmatige samenstellen: iemand kopieert vóór een release of een audit afhankelijkheidslijsten naar een spreadsheet. Een build op CRACI maakt de SBOM als bijproduct van het draaien, dus de lijst bestaat voor elke build, niet alleen voor de builds waar iemand aan dacht.

Waar CRACI naast werkt, en hoe

Deze tools lezen dingen die CRACI nooit leest. CRACI leest uw broncode niet op fouten, test geen draaiende services en analyseert geen binaries die het niet zelf heeft gebouwd. Ze blijven draaien zoals ze nu doen.

Tools die uw code en repository lezen

SAST, secretscanning en pushbeveiliging, fragment- en signatuurscanning, IaC-scanning en CI/CD-posturecontroles inspecteren allemaal uw code, uw commits of uw configuratie. Stappen in uw workflow draaien ongewijzigd op een CRACI-runner, en functies op repositoryniveau worden niet geraakt, omdat ze nooit op de runner draaiden. Een codescanningstap kan in dezelfde job staan als uw build. SAST valt bewust buiten de scope: er zijn genoeg uitstekende SAST-tools die naast CRACI werken. Zie SAST vs. SCA voor hoe de twee soorten bevindingen verschillen.

Tools die inspecteren wat u niet zelf hebt gebouwd

Binaire en firmware-analyse van binaries van leveranciers, scanners voor images die u ophaalt maar nooit bouwt, en DAST op draaiende services kijken allemaal naar iets dat elders is gebouwd of al draait. CRACI legt builds vast; een binary die van een leverancier komt, is gebouwd op een plek die CRACI nooit heeft gezien. Geeft de leverancier u een SBOM, dan kan CRACI die naast uw eigen builds monitoren.

Prioritering op basis van reachability leest uw call graph, die CRACI niet analyseert. Houd die als u erop vertrouwt; zie reachability-analyse voor wat die u wel en niet kan vertellen.

Processystemen

Ticketing, PSIRT-casemanagement, publicatie van advisories en platforms voor compliance-automatisering sturen uw proces over veel systemen heen. CRACI stuurt bevindingen naar het team dat eigenaar is en bewaart het bewijs uit de build; houd uw procestools voor de rest. Vastleggingen verlaten CRACI als CycloneDX- of SPDX-SBOM's en via de API, die SBOM's, netwerktraces en provenancegegevens teruggeeft. Voor de auditkant, zie SBOM-controles voor SOC 2. Voor licentiewerk dat verder gaat dan gedeclareerde licenties, zoals vermeldingen en review van de volledige tekst, zie open source-licentiecompliance. CRACI houdt de gedeclareerde licentie van elk component bij en dwingt regels voor licentiebeleid af, tot het blokkeren van een build op een licentie toe.

Zo vindt u het vervangingspunt in uw eigen stack

Vijf vragen die u in een middag kunt beantwoorden. Elk antwoord vertelt u of een regel in uw stack verhuist.

1. Draaien uw builds op GitHub Actions op Linux? Zo ja, dan verhuizen de runners. Zo niet, dan vervangt CRACI vandaag niets.
2. Wie maakt vandaag SBOM's, en hoeveel verschillende generators zijn er in gebruik? Elke generator op een repository die u naar CRACI verhuist, is een regel die verdwijnt.
3. Bouwt u Yocto-images? Zo ja, controleer dan of iemand vertrouwt op de toegepaste patches en opgeloste CVE's in de uitvoer van create-spdx voordat u het uitzet.
4. Waar gaan SBOM's naartoe nadat ze zijn gemaakt: een tracker, een spreadsheet, nergens? Die tool of dat proces is de tweede regel die verdwijnt, tenzij u er reachability of herstelmetrics uit nodig hebt.
5. Welke van uw securitytools lezen code, repositories of binaries van derden? Die blijven. Schrijf ze op, zodat niemand verwacht dat CRACI ze vervangt.

Een uitgewerkt voorbeeld

Een fictieve apparatenbouwer, niet gebaseerd op een bestaand bedrijf: Linux-builds op door GitHub gehoste runners, twee teams met twee verschillende SBOM-generators, een Yocto-productlijn met create-spdx aan, SBOM's verzameld in een gedeelde spreadsheet, een codescanningsuite en een ticketingsysteem. Het securityteam beantwoordt vraag 1 en 3 met ja, vindt twee generators bij vraag 2 en een spreadsheet bij vraag 4, en noemt bij vraag 5 codescanning, secretscanning en het ticketingsysteem. Niemand gebruikt de patch-metadata in de Yocto-SPDX.

Verhuist naar CRACI	Blijft
Door GitHub gehoste runners voor de Linux-jobs	Codescanning, als stap op CRACI-runners
Beide SBOM-generators	Secretscanning
create-spdx, omdat niemand de patch-metadata ervan nodig heeft	Het ticketingsysteem
De SBOM-spreadsheet

Op de runnerregel kost een build van 10 minuten die $0.060 kost op een door GitHub gehoste x64-runner met 2 cores ongeveer $0.020 op CRACI, dankzij de versnelling. De kosten van de andere tools vult het bedrijf zelf in.

Wanneer CRACI niet het antwoord is

• Uw pipelines draaien op GitLab CI, Jenkins, Azure DevOps of een ander CI-systeem. CRACI ondersteunt vandaag alleen GitHub Actions, met GitLab CI en Jenkins op de roadmap, dus het vervangt nog niets.
• Uw builds hebben Windows- of macOS-runners of GitHub Enterprise Server nodig, of moeten op uw eigen infrastructuur draaien.
• Uw grootste probleem is ruis uit codescanning in uw eigen code. Dat is een kwestie van SAST afstellen; zie SAST vs. SCA en hoe u ruis in kwetsbaarheden vermindert.
• Uw grootste risico zit in firmware en binaries die u van leveranciers ontvangt, niet in code die u bouwt.
• Uw stack bestaat vooral uit Java en Maven, die op de roadmap staan, of uit .NET, dat niet in de lijst staat van ecosystemen die CRACI vastlegt.
• U hebt vandaag prioritering op basis van reachability of PSIRT-casemanagement nodig.

Voor een stapsgewijs beeld van het product, zie hoe CRACI werkt; voor de SBOM zelf, SBOM-generatie.

Wat CRACI vervangt: veelgestelde vragen

Wat vervangt CRACI?

Uw GitHub Actions-runners voor Linux-jobs, de SBOM-generators die teams in CI draaien voor builds die naar CRACI verhuizen, create-spdx van Yocto voor de dekking van de softwareketen, egress-agents op runners, en het los volgen van kwetsbaarheden op basis van SBOM's voor die builds. Tools die uw code, repositories of binaries van derden lezen, vervangt het niet.

Is CRACI een aanvulling op onze SCA-tool, of vervangt het iets?

Het vervangt taken in de buildlaag: de runner, de SBOM-generatie en de tracking die uit de SBOM volgt. Of dat uw SCA-tool vervangt, hangt af van waarvoor u die gebruikt. Leest die uw code, doet die fragment- of binaire analyse of geeft die u reachability, dan blijven die onderdelen.

Hebben we onze SBOM-generator nog nodig als we builds op CRACI draaien?

Niet voor builds die op CRACI draaien en de ecosystemen gebruiken die het vastlegt. CRACI legt de pakketten vast die elke job heeft binnengehaald en exporteert de SBOM als CycloneDX of SPDX. Houd een generator voor software die u niet op CRACI bouwt, zoals images die u ophaalt, en voor ecosystemen die CRACI nog niet vastlegt, zoals Maven.

Hebben we de ingebouwde SBOM-generatie van Yocto (create-spdx) nog nodig?

Voor de dekking van de softwareketen niet: in een vergelijkende core-image-sato-build naast elkaar bevatte de SBOM van CRACI elk component uit die van Yocto, plus 88 die daarin ontbraken, en de build zonder create-spdx duurde 43% korter. Laat create-spdx aanstaan als u vertrouwt op de toegepaste patches en de als opgelost gemarkeerde CVE's, die CRACI niet vastlegt.

Vervangt CRACI codescanning of secretscanning?

Nee. CRACI leest uw broncode of commits niet op fouten of secrets. Houd die tools. Codescanningstappen draaien ongewijzigd in uw workflow op een CRACI-runner, en functies op repositoryniveau worden niet geraakt.

Vervangt CRACI binaire of firmware-analyse?

Nee. CRACI legt de builds vast die het uitvoert. Voor firmware en binaries die u van leveranciers ontvangt, is binaire analyse het juiste gereedschap. Geeft een leverancier u een SBOM, dan kan CRACI die naast uw eigen builds monitoren.

Kunnen we onze bestaande securitystappen in GitHub Actions behouden op CRACI-runners?

Ja. CRACI vervangt de runner, niet GitHub Actions: u zet runs-on op craci en uw workflows, stappen en resultaten blijven in GitHub. Scanstappen, teststappen en alle andere stappen blijven draaien zoals voorheen.