Confronto
CRACI vs GitLab CI
GitLab scansiona il Suo progetto e riporta ciò che dichiarano i suoi lockfile. CRACI è il runner, quindi registra ciò che ogni build ha effettivamente scaricato. La differenza sta nell'origine della Sua SBOM e della Sua provenance.
Aggiornato il
La risposta breve
GitLab è una piattaforma DevSecOps completa: controllo del codice sorgente, merge request, pianificazione e CI/CD in un unico prodotto, con un ampio insieme di scanner di sicurezza e gestione delle vulnerabilità nel piano Ultimate. Se vuole un solo vendor per l'intero ciclo di vita del software, GitLab è costruito per questo.
CRACI è più mirato. È un runner compatibile con GitHub Actions che registra ogni dipendenza esterna scaricata da una build, controlla che cosa la build può raggiungere e trasforma quella registrazione in SBOM, dati di provenance ed evidenze per il CRA. La differenza di fondo è tra una CI tradizionale con scanner aggiunti e una CI in cui il runner stesso è la registrazione di sicurezza.
Un punto pratico viene prima di tutto. Oggi CRACI supporta solo GitHub Actions; GitLab CI e Jenkins sono in roadmap. Se le Sue pipeline sono su GitLab CI, dovrebbe spostarle su GitHub Actions per usare i runner CRACI, oppure attendere il supporto a GitLab CI, che è in roadmap.
| Funzionalità | CRACI | GitLab |
|---|---|---|
| Dipendenze registrate dalla build | Download osservati, compresi i pacchetti dalle cache CI | Gli scanner leggono lockfile ed export del grafo delle dipendenze |
| Esportazione SBOM | CycloneDX o SPDX per build, con stato di completezza | Report CycloneDX; esportazione dell'elenco dipendenze in Ultimate |
| Policy di egress di rete per la build | Negazione o autorizzazione predefinita, fail closed | Controlli di rete propri sui runner self-managed |
| Provenance della build | Dati di provenance tramite l'API; non firmati | Dichiarazione di provenance SLSA 1.0 dal runner |
| Monitoraggio continuo delle vulnerabilità | Le SBOM monitorate vengono rivalutate di continuo | Scansione continua delle vulnerabilità in Ultimate |
| Reporting di conformità | SBOM in CycloneDX o SPDX, registrazioni tramite API; nessuna esportazione di report | Funzionalità di conformità e governance in Ultimate |
| SAST, rilevamento di secret, DAST | SAST e secret di base in tutti i piani; DAST in Ultimate | |
| Controllo del codice sorgente e pianificazione | Funziona con i Suoi repository GitHub | Repository, merge request e pianificazione in un'unica piattaforma |
| Sistemi CI supportati | Oggi GitHub Actions; GitLab CI e Jenkins in roadmap | GitLab CI/CD, ospitato o self-managed |
| Piattaforme dei runner ospitati | Linux su x86-64 e ARM64, da 1 a 32 vCPU. Windows e macOS in roadmap. | Linux su x86-64 e arm64; runner ospitati Windows e macOS in beta. |
| Prezzi | Pagamento per minuto di build: $0.004 per minuto a 2 vCPU, misurato al secondo. Nessun canone mensile e nessun costo per SBOM. | Gratuito con 400 minuti di calcolo; Premium $29 per utente al mese con fatturazione annuale; Ultimate con prezzo su misura (a settembre 2026). |
- Incluso
- In parte
- Non incluso
- In roadmap
Che cosa fa bene GitLab
Un'unica piattaforma. Codice, revisioni, pipeline, risultati di sicurezza e pianificazione stanno nello stesso posto, con un unico modello di permessi. Per molte organizzazioni questo da solo risolve la questione.
Scansione di sicurezza, per piano. Conviene essere precisi su ciò che include ogni piano. Secondo GitLab, SAST di base, rilevamento di secret e scansione dei container sono disponibili in tutti i piani, compreso Free. In Free e Premium, queste scansioni producono artefatti di report JSON. Ultimate aggiunge il workflow attorno a queste scansioni: risultati nelle merge request, il report delle vulnerabilità, l'elenco delle dipendenze, le approvazioni di sicurezza e GitLab Advanced SAST. Dependency scanning, scansione continua delle vulnerabilità e DAST sono funzionalità di Ultimate. La scansione dei container può inoltre produrre un report SBOM CycloneDX in ogni piano.
Provenance. GitLab Runner può generare una dichiarazione di provenance degli artefatti nel formato SLSA 1.0 in tutti i piani. Esistono anche attestazioni firmate SLSA Level 3, ma GitLab le indica come esperimento su GitLab.com per Ultimate, dietro un feature flag disabilitato per impostazione predefinita.
Scelta del runner. I runner ospitati da GitLab coprono Linux su x86-64 (da 2 a 32 vCPU) e arm64, con Windows e macOS in beta. Può anche eseguire runner propri ovunque, e GitLab afferma che i job sui runner propri non consumano minuti di calcolo. GitLab Dedicated aggiunge la residenza dei dati in una regione a Sua scelta.
In che cosa CRACI è diverso
La SBOM proviene dalla build, non dal lockfile
Il dependency scanning basato su SBOM di GitLab rileva le dipendenze da lockfile supportati o da export del grafo delle dipendenze. È un approccio solido quando il lockfile racconta tutta la storia. Le build spesso fanno di più: eseguono script di installazione, scaricano toolchain, ripristinano cache e scaricano immagini base.
CRACI vede questa attività perché è il runner. Un proxy che riconosce i pacchetti osserva il traffico verso le sorgenti dei pacchetti durante l'esecuzione del job, 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 anche un pacchetto ripristinato da una cache viene conteggiato. Ogni job produce una SBOM in CycloneDX o SPDX.
La completezza è dichiarata, non presunta
Ogni SBOM riporta uno stato di completezza per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Quando la registrazione ha una lacuna, Lei può vederla.
La rete della build è una policy
Le policy di egress di CRACI sono a negazione o autorizzazione predefinita, con 24 preset integrati di sorgenti software e sorgenti personalizzate tipizzate per npm, PyPI, apt, apk, il proxy Go, Nix, Cargo, registry OCI e Git. Le policy vengono validate prima dell'avvio del job, operano in modalità fail closed e inviano un avviso in caso di violazione. Su GitLab, il controllo di rete delle build è quello che Lei configura attorno ai Suoi runner.
Provenance
L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance e non dichiara alcun livello SLSA.
Monitorare ciò che è stato distribuito
CRACI aggrega le vulnerabilità tra build e repository e continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory.
Quale scegliere
- Resti su GitLab se il Suo codice e le Sue pipeline sono su GitLab e vuole un'unica piattaforma, oppure se Le servono SAST, DAST e rilevamento di secret nello stesso prodotto.
- Scelga CRACI se il Suo codice è su GitHub, usa GitHub Actions e Le servono evidenze di ciò che è entrato in ogni release, controllo su ciò che le build possono raggiungere e SBOM che possa difendere in un audit.
- Usi entrambi se la Sua organizzazione utilizza entrambe le piattaforme. GitLab continua a coprire i propri progetti e scanner; CRACI esegue la parte GitHub Actions e registra quelle build.
Per il Cyber Resilience Act
Ai sensi del Cyber Resilience Act dell'UE, i fabbricanti devono sapere che cosa c'è in ogni release del prodotto e gestirne le vulnerabilità. Gli obblighi di segnalazione delle vulnerabilità si applicano da settembre 2026, e il regolamento si applica integralmente da dicembre 2027. GitLab Ultimate aiuta a trovare e gestire le vulnerabilità nei Suoi progetti. CRACI registra con che cosa è stata compilata ogni release, continua a monitorarla ed esporta le SBOM in CycloneDX o SPDX. 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. Nessuno dei due strumenti La rende conforme da solo.
Aggiungere CRACI
Per un repository su GitHub, installi la CRACI GitHub App sulla Sua organizzazione, per tutti i repository o per un insieme selezionato, e cambi l'etichetta del runner:
runs-on: craciWorkflow, action e interfaccia di GitHub restano invariati. CRACI sostituisce il runner, non GitHub Actions. Approfondisca la generazione di SBOM in fase di build e le evidenze per il CRA, oppure consulti i prezzi.
Veda che cosa scarica davvero una build
Esegua un workflow GitHub Actions su CRACI e confronti la sua SBOM con quella prodotta oggi dai Suoi scanner.
Prenota una demo