Che cosa sostituisce CRACI nel Suo stack e a che cosa si affianca

La risposta breve: che cosa passa a CRACI e che cosa resta

Mappi il Suo stack con questa tabella. Ogni riga è un'attività che uno strumento del Suo stack svolge oggi, ciò che quell'attività deve vedere per essere svolta, e se CRACI la svolge dalla posizione che occupa.

Attività nel Suo stack	Che cosa deve vedere l'attività	CRACI	Che cosa mantiene, e perché
Runner CI per job Linux su GitHub Actions: ospitati da GitHub, di un fornitore terzo di runner o una flotta self-hosted	Un posto dove eseguire il job	Sostituisce	Runner per Windows, macOS, GitHub Enterprise Server e sistemi CI diversi da GitHub Actions, che oggi CRACI non supporta
Monitoraggio di rete o agenti di egress aggiunti ai runner che mantiene	Il traffico in uscita del job	Sostituisce sui runner CRACI	Agenti sui runner che mantiene altrove
Generatori di SBOM eseguiti in CI, team per team: scanner di manifest, lockfile o immagini usati per produrre SBOM	Ciò che la build ha effettivamente scaricato	Sostituisce per le build su CRACI	Generatori per il software che non compila su CRACI, come le immagini che scarica e non compila mai
Generazione SBOM integrata in Yocto (create-spdx) per la copertura della supply chain	Ogni sorgente e strumento scaricato dalla build BitBake	Sostituisce per la copertura della supply chain	create-spdx, se fa affidamento sui suoi metadati delle recipe: patch applicate e CVE segnalate come corrette
Monitoraggio delle vulnerabilità a partire dalle SBOM: caricare SBOM, confrontare gli advisory, controllare quelli nuovi	Una SBOM accurata per release, sempre aggiornata	Sostituisce per le build su CRACI; si possono aggiungere SBOM dei fornitori	Uno strumento dedicato se Le serve ciò che CRACI non fa: reachability, metriche di remediation come MTTR o scadenze per gravità
SBOM ed elenchi di componenti tenuti in fogli di calcolo	Una SBOM accurata per release, sempre aggiornata	Sostituisce	Nulla
Controlli sulle licenze dichiarate e policy sulle licenze	La licenza dichiarata di ogni componente	In parte	Scansione delle licenze a testo completo e a livello di snippet, note di attribuzione
SAST e scansione del codice	Il Suo codice sorgente	Si affianca	Lo mantenga; viene eseguito senza modifiche come step del workflow su un runner CRACI
Scansione dei segreti e push protection	Il Suo repository e i Suoi commit	Si affianca	La mantenga
DAST e test delle API	Il Suo servizio in esecuzione	Si affianca	Li mantenga
Analisi di binari e firmware di terze parti	Un binario finito che Lei non ha compilato	Si affianca	La mantenga
Scansione di snippet e firme per codice copiato o vendorizzato	Il contenuto dei file nel repository	Si affianca	La mantenga
Prioritizzazione basata sulla reachability	Il Suo call graph	Si affianca	La mantenga se ci fa affidamento
Scansione di IaC, cluster e configurazioni errate	Configurazione e infrastruttura in esecuzione	Si affianca	La mantenga
Controlli di postura CI/CD sulla configurazione dei workflow	File e impostazioni dei workflow	Si affianca	Li mantenga
Ticketing, gestione dei casi PSIRT, pubblicazione degli advisory	Il Suo processo	Si affianca	Li mantenga
Automazione della compliance: raccolta di evidenze per audit SOC 2 o ISO 27001	I Suoi controlli su tutti i sistemi	Si affianca	La mantenga; le registrazioni di CRACI sono evidenze che può raccogliere

Il prima e il dopo

Prima: runner ospitati da GitHub, un generatore di SBOM diverso nel workflow di ogni team, il create-spdx di Yocto che allunga i tempi di build, e SBOM caricate in un tracker o in un foglio di calcolo, con scansione del codice, scansione dei segreti, analisi dei binari e ticketing tutto intorno. Dopo: runner CRACI che eseguono ogni job, applicano la sua policy di egress, ne registrano la SBOM e la mantengono sotto monitoraggio. Gli strumenti che leggono codice, repository, binari e il Suo processo restano invariati.

Che cosa sostituisce CRACI, e perché

Ognuna di queste attività avviene durante la build. CRACI può farsene carico perché è il luogo in cui la build viene eseguita. Per ciascuna: il meccanismo, a che cosa rinuncia e un esempio.

I Suoi runner

CRACI è un runner per GitHub Actions. Lei cambia runs-on in craci e le esecuzioni continuano a comparire in GitHub come qualsiasi altro job di Actions. Ogni job ottiene la propria macchina virtuale, su Linux x86-64 o ARM64, con dimensioni da 1 a 32 vCPU, misurata al secondo. Non serve riscrivere i workflow: gli step esistenti, compresi quelli di scansione, continuano a funzionare.

CRACI addebita solo i minuti di build: $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile e senza costi per SBOM. Questo lo rende uno dei runner CI più convenienti. Esegue le build circa due volte più velocemente dei runner ospitati da GitHub, grazie a hardware più veloce, tempi di coda più brevi e caching.

Runner, al minuto	CRACI	Ospitato da GitHub	Differenza
2 vCPU x64	$0.004	$0.006	CRACI circa il 33% più economico
2 vCPU ARM64	$0.004	$0.005	CRACI il 20% più economico
32 vCPU x64	$0.064	$0.082	CRACI circa il 22% più economico
32 vCPU ARM64	$0.064	$0.050	CRACI il 28% più costoso

Prezzi di listino GitHub a settembre 2026. GitHub arrotonda ogni job al minuto intero superiore; CRACI misura al secondo. Esempio: una build di 10 minuti su un runner x64 a 2 core ospitato da GitHub costa $0.060. A circa il doppio della velocità richiede 5 minuti su un runner CRACI da 2 vCPU e costa $0.020, circa il 67% in meno. Veda prezzi e prezzi dei runner CI.

A che cosa rinuncia. I runner Windows e macOS, altri sistemi CI e i runner ospitati dal cliente oggi non sono disponibili; GitLab CI, Jenkins, Windows, macOS e i runner ospitati dal cliente sono nella roadmap. GitHub Enterprise Server non è supportato. I runner sono gestiti, su infrastruttura europea. Se sta valutando runner gestiti rispetto a una flotta propria, veda runner gestiti e self-hosted a confronto.

Agenti di egress sui runner che mantiene

Un agente di egress osserva o limita il traffico di un runner gestito da qualcun altro. Su CRACI è il runner stesso ad applicare la policy di egress: deny o allow come impostazione predefinita, 24 preset integrati per le sorgenti software, sorgenti personalizzate tipizzate per registry di pacchetti e Git, e regole di rete esplicite. La policy viene convalidata prima dell'avvio del job e in caso di errore blocca tutto (fail closed), e CRACI invia avvisi sulle violazioni della policy. Sui runner CRACI non serve un agente separato.

Esempio: una dipendenza compromessa cerca di inviare i segreti del job a un host di cui la build non ha mai avuto bisogno. Con una policy default-deny la connessione viene bloccata, anche in un attacco mai visto prima, perché la policy consente solo ciò di cui la build ha bisogno invece di cercare host noti come malevoli.

A che cosa rinuncia. La policy copre i job sui runner CRACI. I runner che mantiene altrove hanno ancora bisogno di un proprio controllo.

Il generatore di SBOM nel workflow di ogni team

Un generatore legge i file che ha davanti, come un manifest, un lockfile o un'immagine, e ricostruisce ciò che vi è entrato. Generatori diversi restituiscono elenchi diversi dallo stesso checkout, e di solito ogni team sceglie il proprio, così l'organizzazione si ritrova con più inventari che non coincidono.

CRACI registra i pacchetti che ogni job ha effettivamente scaricato, compresi quelli ripristinati dalle cache CI, e le dipendenze nascoste che gli strumenti basati sui lockfile non vedono: codice scaricato dagli hook di npm install, script di build Rust che scaricano durante la build, e l'immagine di base con i suoi layer di sistema operativo in una build di container. Ogni componente della SBOM era nella build. La SBOM di ogni job indica la propria completezza, come Complete, Complete with connections, Incomplete, Unavailable o Not recorded, così una lacuna è visibile invece di passare inosservata. Il risultato è un unico inventario per ogni repository che esegue le build su CRACI, esportato in CycloneDX o SPDX. Ecosistemi registrati oggi: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai download di Yocto e OpenEmbedded.

Esempio: expressjs/express 5.2.1 non include alcun lockfile nel repository. Un generatore che risolve le dipendenze dai lockfile lì non ha nulla da risolvere, eppure può restituire un documento che non elenca nessuna delle dipendenze npm dichiarate in package.json. Una build dello stesso progetto su CRACI registra i pacchetti scaricati da npm install. Approfondisca il metodo in SBOM in fase di build e strumenti SCA e SBOM a confronto; per uno stack di generatori fai da te, veda lo stack SBOM fai da te.

A che cosa rinuncia. Agli ecosistemi che CRACI non registra ancora. Maven e Java sono nella roadmap, e tutto ciò che non compare nell'elenco precedente non è coperto. Mantenga un generatore per quelle build.

La generazione SBOM integrata in Yocto

Yocto scrive la propria SBOM SPDX tramite create-spdx, ed è accurata su ciò che BitBake compila. Non può vedere ciò che accade al di fuori dei metadati di BitBake. CRACI esegue la build BitBake e registra ciò che ha scaricato. In una build di confronto di core-image-sato su un runner ARM64 nativo con 32 vCPU, la SBOM di CRACI conteneva ogni componente presente nella SBOM di Yocto, più 88 che questa non aveva rilevato: 23 pacchetti host sulla macchina di build, 10 sorgenti GitHub, tra cui la GitHub Action actions/upload-artifact, e 55 altre sorgenti e strumenti scaricati durante la build. Ha registrato tutte le 653 versioni di crate Rust con package URL pkg:cargo, così possono essere confrontate con gli advisory. La build senza la generazione SBOM di Yocto ha richiesto il 43% di tempo in meno: circa $9.96 contro $5.68 per build al prezzo di CRACI.

A che cosa rinuncia. L'SPDX di Yocto contiene metadati delle recipe che CRACI non registra: le patch applicate e le CVE segnalate come corrette. Se fa affidamento su questi dati, lasci attivo create-spdx. Il metodo e il confronto completo sono in build Yocto su CRACI.

Dalle SBOM al monitoraggio delle vulnerabilità

Un tracker autonomo deve essere alimentato con una SBOM e si fida di ciò che riceve. CRACI produce la SBOM e conserva la registrazione. Le SBOM monitorate vengono rivalutate continuamente man mano che vengono pubblicati nuovi advisory. La cronologia delle build mostra quali build contenevano una dipendenza vulnerabile, diretta o transitiva, così Lei conosce il periodo in cui era esposto, entro la retention del Suo piano. I finding vengono assegnati al team responsabile della correzione, CRACI notifica alle persone interessate una vulnerabilità e la sua gravità, e i policy gate possono bloccare una build in base ai finding, anche una build che contiene una specifica CVE. VEX è supportato. Si possono aggiungere SBOM dei fornitori, così i componenti acquistati vengono monitorati insieme alle Sue build.

Esempio: viene pubblicato un advisory per un crate che uno dei Suoi servizi ha compilato tre mesi fa. CRACI lo confronta con ogni SBOM monitorata e mostra quali build contenevano quella versione, senza che nessuno debba ricaricare nulla.

A che cosa rinuncia. CRACI non offre analisi di reachability né metriche di remediation come MTTR, scadenze per gravità o andamento del backlog. Se ne ha bisogno, mantenga lo strumento che le fornisce. Veda monitoraggio delle vulnerabilità per tutte le funzionalità.

Il foglio di calcolo

Per i team senza strumenti SBOM, ciò che CRACI sostituisce è l'assemblaggio manuale: qualcuno copia gli elenchi delle dipendenze in un foglio di calcolo prima di una release o di un audit. Una build su CRACI produce la SBOM come effetto collaterale dell'esecuzione, quindi l'elenco esiste per ogni build, non solo per quelle di cui qualcuno si è ricordato.

A che cosa si affianca CRACI, e come

Questi strumenti leggono cose che CRACI non legge mai. CRACI non legge il Suo codice sorgente alla ricerca di difetti, non testa i servizi in esecuzione e non analizza binari che non ha compilato. Continuano a funzionare come oggi.

Strumenti che leggono il Suo codice e il Suo repository

SAST, scansione dei segreti e push protection, scansione di snippet e firme, scansione IaC e controlli di postura CI/CD esaminano tutti il Suo codice, i Suoi commit o la Sua configurazione. Gli step del Suo workflow vengono eseguiti senza modifiche su un runner CRACI, e le funzionalità a livello di repository non ne risentono perché non sono mai state eseguite sul runner. Uno step di scansione del codice può stare nello stesso job della build. SAST è fuori ambito per scelta: molti ottimi strumenti SAST funzionano insieme a CRACI. Veda SAST e SCA a confronto per capire in che cosa differiscono i due tipi di finding.

Strumenti che esaminano ciò che Lei non ha compilato

L'analisi di binari e firmware dei fornitori, gli scanner per le immagini che scarica ma non compila mai e il DAST sui servizi in esecuzione esaminano qualcosa che è stato compilato altrove o che è già in esecuzione. CRACI registra le build; un binario che arriva da un fornitore è stato compilato in un luogo che CRACI non ha mai visto. Se il fornitore Le fornisce una SBOM, CRACI può monitorarla insieme alle Sue build.

La prioritizzazione basata sulla reachability legge il Suo call graph, che CRACI non analizza. La mantenga se ci fa affidamento; veda analisi della reachability per sapere che cosa può e non può dirLe.

Sistemi di processo

Ticketing, gestione dei casi PSIRT, pubblicazione degli advisory e piattaforme di automazione della compliance gestiscono il Suo processo su molti sistemi. CRACI indirizza i finding al team responsabile e conserva le evidenze della build; per il resto mantenga i Suoi strumenti di processo. Le registrazioni escono da CRACI come SBOM CycloneDX o SPDX e tramite l'API, che restituisce SBOM, tracce di rete e dati di provenienza. Per la parte di audit, veda controlli SBOM per SOC 2. Per il lavoro sulle licenze oltre le licenze dichiarate, come note e revisione del testo completo, veda conformità delle licenze open source. CRACI riporta la licenza dichiarata di ogni componente e applica regole di policy sulle licenze, compreso il blocco di una build per una licenza.

Come individuare il punto di sostituzione nel Suo stack

Cinque domande a cui può rispondere in un pomeriggio. Ogni risposta Le dice se una voce del Suo stack si sposta.

1. Le Sue build vengono eseguite su GitHub Actions su Linux? Se sì, i runner passano a CRACI. Se no, oggi CRACI non sostituisce nulla.
2. Chi genera le SBOM oggi, e quanti generatori diversi sono in uso? Ogni generatore su un repository che sposta su CRACI è una voce che scompare.
3. Compila immagini Yocto? Se sì, verifichi se qualcuno fa affidamento sulle patch applicate e sulle CVE corrette nell'output di create-spdx prima di disattivarlo.
4. Dove finiscono le SBOM dopo essere state generate: in un tracker, in un foglio di calcolo, da nessuna parte? Quello strumento o processo è la seconda voce che scompare, a meno che non Le servano la reachability o le metriche di remediation che fornisce.
5. Quali dei Suoi strumenti di sicurezza leggono codice, repository o binari di terze parti? Quelli restano. Li annoti, così nessuno si aspetterà che CRACI li sostituisca.

Un esempio concreto

Un produttore di dispositivi a titolo illustrativo, non basato su alcuna azienda reale: build Linux su runner ospitati da GitHub, due team che usano due generatori di SBOM diversi, una linea di prodotti Yocto con create-spdx attivo, SBOM raccolte in un foglio di calcolo condiviso, una suite di scansione del codice e un sistema di ticketing. Il suo team di sicurezza risponde sì alle domande 1 e 3, trova due generatori per la domanda 2 e un foglio di calcolo per la domanda 4, ed elenca scansione del codice, scansione dei segreti e sistema di ticketing per la domanda 5. Nessuno usa i metadati delle patch nell'SPDX di Yocto.

Passa a CRACI	Resta
Runner ospitati da GitHub per i job Linux	Scansione del codice, eseguita come step sui runner CRACI
Entrambi i generatori di SBOM	Scansione dei segreti
create-spdx, perché nessuno ha bisogno dei suoi metadati delle patch	Il sistema di ticketing
Il foglio di calcolo delle SBOM

Per la voce runner, una build di 10 minuti che costa $0.060 su un runner x64 a 2 core ospitato da GitHub costa circa $0.020 su CRACI grazie alla maggiore velocità. Spetta all'azienda inserire i costi degli altri strumenti.

Quando CRACI non è la risposta

• Le Sue pipeline girano su GitLab CI, Jenkins, Azure DevOps o un altro sistema CI. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins nella roadmap, quindi per ora non sostituisce nulla.
• Le Sue build richiedono runner Windows o macOS o GitHub Enterprise Server, oppure devono girare sulla Sua infrastruttura.
• Il Suo problema principale è il rumore della scansione del codice nel Suo codice. È un problema di tuning della SAST; veda SAST e SCA a confronto e come ridurre il rumore delle vulnerabilità.
• Il Suo rischio principale sono firmware e binari che riceve dai fornitori, non il codice che compila.
• Il Suo stack è soprattutto Java e Maven, che sono nella roadmap, oppure .NET, che non è nell'elenco degli ecosistemi registrati da CRACI.
• Le servono oggi la prioritizzazione basata sulla reachability o la gestione dei casi PSIRT.

Per una panoramica passo per passo del prodotto, veda come funziona CRACI; per la SBOM in sé, generazione di SBOM.

Che cosa sostituisce CRACI: domande frequenti

Che cosa sostituisce CRACI?

I Suoi runner GitHub Actions per i job Linux, i generatori di SBOM che i team eseguono in CI per le build che passano a CRACI, il create-spdx di Yocto per la copertura della supply chain, gli agenti di egress sui runner e il monitoraggio autonomo delle vulnerabilità a partire dalle SBOM per quelle build. Non sostituisce gli strumenti che leggono il Suo codice, i Suoi repository o binari di terze parti.

CRACI è un'aggiunta al nostro strumento SCA o sostituisce qualcosa?

Sostituisce attività del livello di build: il runner, la generazione delle SBOM e il monitoraggio che deriva dalla SBOM. Se questo prenda il posto del Suo strumento SCA dipende da come lo usa. Se legge il Suo codice, esegue analisi di snippet o di binari o Le fornisce la reachability, quelle parti restano.

Ci serve ancora il nostro generatore di SBOM se eseguiamo le build su CRACI?

Non per le build eseguite su CRACI che usano gli ecosistemi registrati. CRACI registra i pacchetti scaricati da ogni job ed esporta la SBOM in CycloneDX o SPDX. Mantenga un generatore per il software che non compila su CRACI, come le immagini che scarica, e per gli ecosistemi che CRACI non registra ancora, come Maven.

Ci serve ancora la generazione SBOM integrata in Yocto (create-spdx)?

Per la copertura della supply chain no: in una build di confronto di core-image-sato, la SBOM di CRACI conteneva ogni componente presente in quella di Yocto, più 88 che questa non aveva rilevato, e la build senza create-spdx ha richiesto il 43% di tempo in meno. Lasci attivo create-spdx se fa affidamento sulle patch applicate e sulle CVE segnalate come corrette, che CRACI non registra.

CRACI sostituisce la scansione del codice o dei segreti?

No. CRACI non legge il Suo codice sorgente né i Suoi commit alla ricerca di difetti o segreti. Mantenga quegli strumenti. Gli step di scansione del codice vengono eseguiti senza modifiche nel Suo workflow su un runner CRACI, e le funzionalità a livello di repository non ne risentono.

CRACI sostituisce l'analisi di binari o firmware?

No. CRACI registra le build che esegue. Per firmware e binari che riceve dai fornitori, l'analisi dei binari è lo strumento giusto. Se un fornitore Le fornisce una SBOM, CRACI può monitorarla insieme alle Sue build.

Possiamo mantenere i nostri step di sicurezza esistenti in GitHub Actions sui runner CRACI?

Sì. CRACI sostituisce il runner, non GitHub Actions: Lei imposta runs-on su craci e i Suoi workflow, step e risultati restano in GitHub. Gli step di scansione, di test e qualsiasi altro step continuano a funzionare come prima.