Strumenti e piattaforme CI/CD a confronto

A chi si rivolge

Lei sta scegliendo una piattaforma CI/CD, o sta riesaminando quella che usa, e in lista c'è una nuova domanda. Un cliente, un auditor o il Cyber Resilience Act dell'UE chiede che cosa è entrato in ogni release. Ogni piattaforma qui presentata può eseguire le Sue build. La differenza sta nell'origine di quelle evidenze e in quanta parte deve metterne insieme Lei.

CRACI è su questa pagina per questo motivo, e non è una piattaforma CI. È un runner per GitHub Actions: Lei mantiene GitHub Actions e cambia runs-on in craci. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. Le pipeline GitLab CI, CircleCI e Buildkite non girano su di esso. CRACI lo sviluppiamo noi, quindi ne tenga conto; gli altri prodotti sono descritti in base alla loro documentazione.

Da dove dovrebbe provenire la SBOM?

Una piattaforma può ottenerla da tre punti.

1. Il repository. La piattaforma analizza manifest e lockfile. Il dependency graph di GitHub e il dependency scanning basato su SBOM di GitLab funzionano così. Questo metodo è sempre attivo ed economico da eseguire, e descrive ciò che il progetto dichiara. Non vede gli script di installazione, le toolchain scaricate né i pacchetti ripristinati da una cache, e l'esportazione di GitHub riflette il branch predefinito anziché un commit fissato.
2. Uno strumento che Lei aggiunge alla pipeline. Lei esegue un generatore di SBOM come step, tramite un orb CircleCI o sui Suoi agent Buildkite. È flessibile, e il risultato dipende dallo strumento e dalla sua configurazione: ogni generatore legge un insieme diverso di file e li risolve in modo diverso, quindi due generatori puntati sullo stesso checkout pulito non restituiranno lo stesso elenco di componenti. CRACI non si può confrontare in questi termini, perché registra le build invece di scansionare una directory.
3. Il runner che ha osservato la build. La SBOM viene registrata dal traffico generato dal job durante l'esecuzione. È ciò che fa CRACI.

La provenance segue la stessa divisione. Le artifact attestation di GitHub, uno step che si aggiunge a un workflow, forniscono SLSA v1.0 Build Level 2, o Level 3 con i reusable workflow. GitLab Runner può generare uno statement di provenance SLSA 1.0 in tutti i piani. Buildkite Package Registries può pubblicare una provenance SLSA che secondo Buildkite soddisfa il Build Level 1, nei piani Enterprise. L'API di CRACI restituisce i dati di provenance dal runner che ha osservato il job, non firmati e senza livello SLSA.

In sintesi

La colonna GitHub Actions comprende le funzionalità della piattaforma GitHub che i team usano insieme: il dependency graph, Dependabot, le artifact attestation e GitHub Advanced Security. I prezzi sono aggiornati a settembre 2026.

Le piattaforme

CRACI, un runner sicuro per GitHub Actions

CRACI sostituisce il runner, non GitHub Actions. Installi la GitHub App di CRACI e cambi runs-on; le esecuzioni continuano a comparire nell'interfaccia di GitHub. Durante l'esecuzione di ogni job, un proxy che riconosce i pacchetti registra ciò che ha scaricato, compresi i pacchetti ripristinati dalle cache CI, e produce una SBOM CycloneDX o SPDX con uno stato di completezza per job e per cache. Le policy di egress vengono convalidate prima dell'avvio del job e operano in modalità fail closed. Ideale per i team GitHub Actions che distribuiscono software e hanno bisogno di evidenze per ogni release. Attenzione: oggi solo GitHub Actions e Linux (GitLab CI, Jenkins, Windows e macOS sono in roadmap), e nessuna SAST né scansione dei segreti.

Generazione di SBOM in fase di build

GitHub Actions

CI/CD integrata in GitHub, con runner in hosting Linux, Windows e macOS e runner self-hosted per le Sue macchine. I piani includono da 2.000 a 50.000 minuti al mese, e un runner Linux standard a 2 core costa $0.006 al minuto a settembre 2026. Attorno ci sono il dependency graph, gli avvisi e gli aggiornamenti di sicurezza di Dependabot, le artifact attestation e i prodotti a pagamento GitHub Secret Protection e GitHub Code Security. Ideale per il codice che si trova già su GitHub. Attenzione a una SBOM che descrive il repository, non la build, a meno che non aggiunga Lei stesso un generatore.

CRACI vs runner ospitati da GitHub e CRACI e GitHub Advanced Security

GitLab CI

Parte di una piattaforma DevSecOps completa: controllo del codice sorgente, merge request, pianificazione e CI/CD in un solo prodotto. SAST di base, rilevamento dei segreti e scansione dei container sono disponibili in tutti i piani; Ultimate aggiunge dependency scanning, scansione continua delle vulnerabilità, DAST e il vulnerability report. I runner in hosting coprono Linux su x86-64 e arm64, con Windows e macOS in beta. A settembre 2026, Free include 400 minuti di calcolo e Premium costa $29 per utente al mese con fatturazione annuale. Ideale per chi vuole un unico fornitore per l'intero ciclo di vita. Attenzione al rilevamento delle dipendenze dai lockfile e alle attestazioni SLSA Level 3 firmate che GitLab classifica come sperimentali.

CRACI vs GitLab CI

CircleCI

Una piattaforma CI/CD in hosting matura e flessibile, che si collega a GitHub, GitLab e Bitbucket. Esegue i job su resource class Docker, Linux, Arm, Windows, macOS e GPU, con runner self-hosted per le Sue macchine. Il Docker layer caching è incluso in tutti i piani, e il test splitting distribuisce le suite su executor paralleli in base ai tempi di esecuzione. Le sue indicazioni sulla supply chain si concentrano sulla protezione delle credenziali con contexts e OIDC. A settembre 2026, il piano Free include 30.000 crediti al mese. Ideale per piattaforme miste e grandi suite di test. Attenzione a SBOM e scansioni che dipendono dagli orb e dagli strumenti che Lei collega.

CRACI vs CircleCI

Buildkite

Una piattaforma ibrida: il control plane SaaS di Buildkite orchestra, e gli agent che eseguono i job risiedono sulla Sua infrastruttura, quindi codice sorgente e segreti restano nel Suo ambiente. Sono disponibili anche agent in hosting, a $0.004 per vCPU-minuto su Linux a settembre 2026. Le pipeline firmate consentono agli agent di rifiutare i job modificati dopo il caricamento, e Test Engine gestisce i test instabili e il test splitting. Ideale per le build che devono girare sul Suo hardware o sulla Sua rete. Attenzione a una sicurezza della build che spetta a Lei progettare: le indicazioni stesse di Buildkite raccomandano di applicare controlli rigorosi sull'egress di rete dei Suoi agent.

CRACI vs Buildkite

Dove si colloca CRACI

CRACI è un'aggiunta a GitHub Actions, non il sostituto di una piattaforma CI. Su GitHub, una configurazione comune prevede GitHub Advanced Security e Dependabot su ogni pull request, e CRACI come runner che registra ogni build e applica la policy di egress. Le SBOM monitorate vengono rivalutate man mano che emergono nuove vulnerabilità e si esportano in CycloneDX o SPDX, vulnerabilità comprese. CRACI 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 Cyber Resilience Act.

Se le Sue pipeline sono su GitLab CI, CircleCI o Buildkite, usare CRACI significa spostare quelle pipeline su GitHub Actions. GitLab CI e Jenkins sono in roadmap. CRACI non è la scelta giusta quando:

• Vuole un'unica piattaforma per codice, pianificazione, CI e scansioni. GitLab è pensato per questo.
• Le build devono girare sul Suo hardware o sulla Sua rete. Buildkite e i runner self-hosted sono adatti; oggi CRACI è gestito, con runner ospitati dal cliente in roadmap per Enterprise.
• Le servono build Windows, macOS o GPU. Oggi CRACI è solo Linux; Windows e macOS sono in roadmap.
• Le serve oggi un livello SLSA documentato. Le artifact attestation di GitHub lo forniscono.

Veda i prezzi di CRACI e l'integrazione CI/CD.

CRACI a confronto con ciascuno strumento

• CRACI e Runner ospitati da GitHub a confronto Stessi workflow, build più veloci, costi più bassi.
• CRACI e GitLab CI a confronto Gli scanner di una piattaforma DevSecOps contro un runner che registra.
• CRACI e CircleCI a confronto CI ospitata contro evidenze in fase di build.
• CRACI e Buildkite a confronto Agent self-hosted contro runner che registrano le build.
• CRACI e Blacksmith a confronto Runner veloci contro una CI con la sicurezza della supply chain integrata.
• CRACI e Depot a confronto Accelerazione delle build contro evidenze delle build.
• CRACI e Namespace a confronto Infrastruttura CI veloce contro runner che registrano le build.
• CRACI e WarpBuild a confronto Runner veloci e BYOC contro runner con evidenze.
• CRACI e RunsOn a confronto Runner nel Suo account AWS contro runner che registrano le build.
• CRACI e Ubicloud a confronto Runner a basso costo contro una CI con la sicurezza della supply chain integrata.
• CRACI e Avrea a confronto Osservabilità della CI contro evidenze in fase di build.
• CRACI e Harness a confronto Scansioni SBOM nella pipeline contro un runner che registra la build.
• CRACI e Northflank a confronto Una piattaforma di build e deploy contro un runner che registra le build.
• CRACI e Jenkins a confronto Un server CI da gestire in proprio contro runner gestiti che registrano le build.
• CRACI e Azure Pipelines a confronto Job paralleli contro runner al minuto con evidenze delle build.

Fianco a fianco

Più strumenti in una sola pagina, per quando sceglie una categoria e non un singolo prodotto.

• Runner GitHub Actions a confronto GitHub-hosted, CRACI, Blacksmith, Depot, Namespace e WarpBuild fianco a fianco.