A che cosa può accedere CRACI e che cosa conserva

Perché questa domanda merita una risposta chiara

Un runner CI vede più della maggior parte degli strumenti del Suo stack. Esegue il checkout del sorgente, installa le dipendenze e detiene i secret che i Suoi workflow usano per pubblicare pacchetti e distribuire. Quando la GitHub Action tj-actions/changed-files è stata compromessa a marzo 2025, CISA ha riferito che il codice malevolo ha esposto secret tra cui chiavi di accesso, personal access token di GitHub, token npm e chiavi RSA private. Il runner è il luogo in cui risiedono quei secret mentre un job è in esecuzione.

Quindi, prima di indirizzare un workflow verso CRACI, dovrebbe sapere esattamente a che cosa può accedere. Le risposte sono qui sotto, e il CRACI Trust Center e docs.craci.com forniscono i dettagli.

A che cosa serve la GitHub App

CRACI sostituisce il runner, non GitHub Actions. Lei mantiene i Suoi workflow, cambia runs-on in craci per i job che sceglie e le esecuzioni continuano a comparire nell'interfaccia di GitHub. Perché funzioni, la Sua organizzazione installa la CRACI GitHub App.

Durante l'installazione, concede all'App l'accesso a tutti i repository oppure a un insieme selezionato. Solo i repository a cui concede l'accesso possono eseguire workflow su CRACI.

I permessi esatti richiesti dall'App sono elencati nella schermata di installazione di GitHub e può rivederli in seguito nelle impostazioni della Sua organizzazione. In breve, l'App può leggere il Suo codice e le Sue esecuzioni di Actions, e gestisce i runner che registra per la Sua organizzazione.

Dove viene eseguito il Suo codice

I job vengono eseguiti in macchine virtuali isolate. L'esecuzione delle build avviene su infrastruttura bare metal europea. Il Suo codice sorgente viene elaborato all'interno della VM del job per la durata della build.

Ogni job viene eseguito su una di tre immagini: CRACI Slim, CRACI Slim ARM64 o un'immagine Ubuntu 24.04 compatibile con GitHub. Oggi i runner sono solo Linux; Windows e macOS sono in roadmap.

Il modo in cui i job vengono isolati, e che cosa accade alla VM di un job quando termina, è documentato su docs.craci.com e nel Trust Center.

Che cosa conserva CRACI e per quanto tempo

CRACI elabora il Suo codice sorgente nella VM del job durante la build e non lo conserva. Ciò che conserva sono le evidenze che registra su ogni build, oltre alle cache salvate dai Suoi workflow:

• Metadati di build
• Dati sui pacchetti, ossia le dipendenze scaricate da ogni job
• Tracce di rete del job
• SBOM
• Record di provenance
• Cache
• Record di audit

Una cache contiene ciò che il Suo workflow vi inserisce, quindi tratti il contenuto delle cache come qualsiasi altro output di build.

Il periodo di conservazione predefinito è di 180 giorni. I piani Enterprise possono impostare un periodo di conservazione personalizzato. La cancellazione e la cifratura dei dati sono trattate nel Trust Center.

Hosting e residenza dei dati

CRACI è ospitato in Europa e offre la residenza dei dati nell'UE, con esecuzione delle build su infrastruttura bare metal europea. La piattaforma gira su Hetzner, un provider tedesco, in un data center a Tuusula, in Finlandia. Veda la residenza dei dati per sapere quali dati gestisce CRACI.

Controlli sulla build stessa

Un runner che vede i Suoi secret dovrebbe anche permetterLe di limitare dove possono andare. Le policy di egress di rete di CRACI impostano per ogni job un default di deny o allow, con 24 preset integrati per le fonti software più comuni e sorgenti personalizzate tipizzate per registry come npm, PyPI, Cargo, Go proxy e OCI. Può anche scrivere regole esplicite TLS, TCP, UDP e ICMP. Le policy vengono convalidate prima dell'avvio del job, operano in modalità fail closed e rifiutano i campi sconosciuti. Gli alert segnalano le violazioni delle policy.

I job escono da un intervallo stabile di IP di egress, così può autorizzare i runner CRACI nei Suoi firewall in base all'indirizzo.

Accesso all'interno della Sua organizzazione

• I piani Enterprise supportano il single sign-on SAML, con Google Workspace come identity provider.
• Un audit log amministrativo registra le azioni amministrative. È disponibile nell'interfaccia e non può ancora essere esportato.
• I token API vengono creati dagli amministratori, possono essere revocati in qualsiasi momento e scadono dopo 90 giorni.

Come mantenere limitato l'ambito

Non deve affidare a CRACI l'intera organizzazione per valutarlo.

1. Installi su repository selezionati. Scelga "Only select repositories" quando installa l'App e ne indichi uno o due. Può ampliare o ridurre l'insieme in seguito dalle impostazioni della Sua organizzazione, in Settings, GitHub Apps, CRACI, Configure. La modifica ha effetto immediato.
2. Sposti un job alla volta. Su CRACI vengono eseguiti solo i job con runs-on: craci. Tutto il resto rimane sul runner che usa oggi.
3. Inizi da un job con pochi secret. Un job di test o di lint Le mostra la SBOM e le evidenze di rete senza mettere credenziali di pubblicazione o deployment su un nuovo runner.
4. Attivi una policy di egress default-deny. Autorizzi le fonti di pacchetti di cui il job ha bisogno e nient'altro.
5. Sappia come uscire. In GitHub può sospendere l'App, bloccandone l'accesso ma lasciandola installata, oppure disinstallarla, rimuovendone l'accesso alla Sua organizzazione.

La nostra postura di sicurezza

La nostra pagina sulla sicurezza spiega il nostro approccio: documentato, non dichiarato. Il Trust Center riunisce le policy, i controlli e la documentazione alla base della piattaforma, ed è il luogo in cui può richiedere materiale per una valutazione del fornitore.

Questa pagina non dichiara alcuna certificazione. Per lo stato attuale del nostro programma di sicurezza e di eventuali attività di audit, consulti il Trust Center.