CRACI vs CircleCI

La risposta breve

CircleCI è una piattaforma CI/CD matura e flessibile. Si collega a GitHub, GitLab e Bitbucket, esegue i job su un'ampia gamma di macchine, dai container Docker a macOS e alle GPU, e consente di impacchettare la configurazione riutilizzabile in orb. Sul fronte della sicurezza, CircleCI protegge le credenziali e lascia la scansione agli orb e agli strumenti di terze parti.

CRACI adotta l'approccio opposto: il runner è la registrazione di sicurezza. Esegue i job GitHub Actions, osserva ogni dipendenza esterna scaricata da ciascuna build, applica una policy di egress alla rete di build e produce SBOM, dati di provenance ed evidenze per il CRA da ciò che ha visto. È la differenza tra una CI tradizionale e una CI attenta alla sicurezza.

Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. CircleCI non è ancora supportato. I team su CircleCI dovrebbero spostare una pipeline su GitHub Actions per usare i runner CRACI, oppure attendere gli altri sistemi CI, che sono in roadmap.

Che cosa fa bene CircleCI

Ampiezza delle risorse di calcolo. CircleCI offre resource class Docker, Linux VM, Arm, Windows, macOS e GPU, così un'unica piattaforma può compilare un backend, un client Windows e un'app iOS. I runner self-hosted estendono tutto questo alle Sue macchine Linux, Windows e macOS e a Kubernetes, e il tempo dei job sui runner non consuma crediti.

Funzionalità per la velocità. Il Docker layer caching è disponibile in tutti i piani. Il test splitting distribuisce una suite su executor paralleli per nome, dimensione dei file o tempi storici di esecuzione, riducendo il tempo reale sulle grandi suite di test.

Configurazione riutilizzabile. Gli orb impacchettano job, comandi ed executor così che i team possano riutilizzarli tra progetti, e rendono semplice collegare strumenti di terze parti, compresi gli scanner di sicurezza.

Igiene delle credenziali. Le indicazioni di CircleCI sulla supply chain si concentrano sulla protezione dei segreti: suddividerli in contexts, mettere le chiavi di deploy e di firma in contexts riservati governati dai gruppi del Suo VCS e usare token OIDC così che i job raggiungano i servizi cloud senza credenziali di lunga durata salvate in CircleCI.

In che cosa CRACI è diverso

La build è la fonte di verità

Su una piattaforma CI tradizionale, una SBOM è prodotta da uno strumento che Lei aggiunge alla pipeline, che di solito legge manifest e lockfile. CRACI invece osserva la build. Un proxy che riconosce i pacchetti registra il traffico verso le sorgenti dei pacchetti mentre il job è in esecuzione, per npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download. Le evidenze sulle dipendenze viaggiano con le cache CI, quindi un pacchetto ripristinato da una cache viene comunque conteggiato.

Lei sa quanto è completa la SBOM

Ogni job produce una SBOM CycloneDX o SPDX con uno stato di completezza per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

La rete di build ha una policy

La funzionalità IP ranges di CircleCI instrada i job attraverso indirizzi CircleCI noti, così i Suoi sistemi possono inserirli in allowlist. Questo risolve l'accesso in ingresso. CRACI aggiunge il controllo nella direzione opposta: policy di egress per ogni job, negazione o autorizzazione predefinita, con 24 preset integrati di sorgenti software, sorgenti personalizzate tipizzate e regole esplicite TLS, TCP, UDP e ICMP. Le policy vengono convalidate prima dell'avvio del job e operano in modalità fail closed. CRACI fornisce anche un intervallo IP di egress stabile.

Provenance e monitoraggio dalla stessa registrazione

L'API restituisce SBOM, tracce di rete e provenance. CRACI aggrega le vulnerabilità di tutte le build e di tutti i repository e continua a rivalutare le SBOM monitorate.

Quale scegliere

• Resti su CircleCI se il Suo codice è su GitLab o Bitbucket, se dipende da build Windows, macOS o GPU, o se esegue i job sul Suo hardware.
• Consideri CRACI se il Suo codice è su GitHub e sta valutando GitHub Actions rispetto a CircleCI, e distribuisce software per cui deve dimostrare che cosa è entrato in ogni release.
• Li usi entrambi durante una migrazione graduale: mantenga le pipeline macOS e Windows su CircleCI ed esegua i workflow GitHub Actions Linux su CRACI dove le evidenze di build contano di più.

Per il Cyber Resilience Act

Il Cyber Resilience Act dell'UE richiede ai fabbricanti di sapere che cosa c'è in ogni release e di gestirne le vulnerabilità, con obblighi di segnalazione da settembre 2026 e piena applicazione da dicembre 2027. Su CircleCI, queste evidenze provengono dagli scanner e dagli orb che Lei collega alle Sue pipeline. CRACI le produce dalla registrazione della build ed esporta le SBOM in CycloneDX o SPDX, vulnerabilità comprese. Automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui le aziende hanno bisogno per il loro più ampio processo di conformità al CRA.

Spostare una pipeline su CRACI

CRACI esegue workflow GitHub Actions, quindi una pipeline CircleCI ha prima bisogno di un equivalente GitHub Actions. Una volta disponibile, installi la GitHub App di CRACI nella Sua organizzazione e imposti l'etichetta del runner:

runs-on: craci

Le esecuzioni continuano a comparire nell'interfaccia di GitHub. I job dispongono di Docker Engine, Buildx e Compose v2, di dimensioni dei runner da 1 a 32 vCPU con 3 GB di RAM ciascuna e del supporto alla cache di GitHub Actions. Scopra di più sulla generazione di SBOM in fase di build, oppure veda i prezzi e il programma per startup.