Confronto
CRACI vs Harness
Harness è una piattaforma di software delivery con una propria CI e un modulo Supply Chain Security che genera SBOM e provenance SLSA nella pipeline. CRACI è il runner su cui girano i Suoi job GitHub Actions, quindi la SBOM, la policy di rete e la provenance provengono dalla build stessa.
Aggiornato il
La risposta breve
Harness, fondata nel 2017 e con sede a San Francisco, vende una piattaforma per tutto ciò che viene dopo la scrittura del codice: continuous integration, continuous delivery, feature flag, gestione dei costi cloud, chaos engineering e test di sicurezza. Il suo modulo Supply Chain Security (SCS) aggiunge generazione di SBOM, provenance SLSA, policy gate OPA e controlli di postura per repository e pipeline. Se vuole un solo vendor per l'intera pipeline di delivery, su più provider Git, Harness è costruita per questo.
CRACI è più mirato e va più a fondo nella build. È un runner GitHub Actions: durante l'esecuzione di ogni job, registra ogni dipendenza esterna scaricata dalla build, applica una policy di egress sulla rete della build e produce SBOM, dati di provenance e monitoraggio delle vulnerabilità da quella registrazione. Harness aggiunge step di supply chain a una pipeline; CRACI fa del runner stesso la registrazione di sicurezza.
Un punto pratico viene prima di tutto. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. Le pipeline Harness CI dovrebbero passare a GitHub Actions per girare su CRACI.
In sintesi
| Funzionalità | CRACI | Harness |
|---|---|---|
| Come viene prodotta la SBOM | Registrata da ciò che ogni job ha scaricato, con uno stato di completezza | Syft o cdxgen scansiona un'immagine o un repository in uno step della pipeline |
| Formati SBOM | CycloneDX e SPDX | SPDX e CycloneDX |
| Provenance della build | Dati di provenance tramite l'API; non firmati | SLSA Build da L1 a L3, firmata con cosign |
| Policy di egress di rete per la build | Negazione o autorizzazione predefinita, validata prima del job, fail closed | Dichiara di rilevare chiamate di rete anomale dei runner |
| Policy gate | Bloccano una build per risultati, una CVE specifica o una licenza | Policy OPA su SBOM, provenance e deployment |
| Monitorare ciò che è stato distribuito | Le SBOM monitorate vengono rivalutate di continuo | Segnala pipeline e artefatti esposti a una nuova CVE |
| Controlli di postura su CI/CD e repository | OWASP Top 10 CI/CD Risks e benchmark CIS | |
| Sistemi CI | Oggi GitHub Actions; GitLab CI e Jenkins in roadmap | Harness CI; step SCS anche per GitHub Actions e GitLab CI/CD |
| Piattaforme dei runner ospitati | Linux su x86-64 e ARM64, da 1 a 32 vCPU. Windows e macOS in roadmap. | Linux AMD64 fino a 96 core e ARM64 fino a 64, Windows e macOS su Apple M4. |
| Infrastruttura di build self-hosted | Runner ospitati dal cliente, Enterprise | Kubernetes, VM o bare metal |
| Delivery, feature flag, gestione dei costi | CRACI copre la build | Moduli della stessa piattaforma |
| Prezzo, Linux a 2 vCPU | $0.004 al minuto ($0.002 per vCPU-minuto), misurati al secondo. | $0.005 al minuto per 2 core e 7 GB, arrotondati al minuto più vicino. |
| Piani | Pagamento per minuto di build: $0.004 per minuto a 2 vCPU, misurato al secondo. Nessun canone mensile e nessun costo per SBOM. | Piano gratuito con 2.000 crediti Harness Cloud al mese; piani a pagamento, pacchetti di crediti e Supply Chain Security tramite il reparto vendite (a settembre 2026). |
- Incluso
- In parte
- Non incluso
- In roadmap
Che cosa fa bene Harness
Un'unica piattaforma per la delivery. Harness copre CI, CD, GitOps, feature flag, infrastructure as code, chaos engineering e gestione dei costi cloud, con applicazione di policy basata su OPA su tutti questi ambiti. Funziona con GitHub, GitLab, Bitbucket, Azure Repos e i propri repository Harness Code, e afferma di servire più di 1.000 clienti enterprise e di avere più di 1.200 dipendenti.
Scelta dell'infrastruttura di build. Harness Cloud esegue le build su macchine Linux, Windows e macOS gestite da Harness: Linux AMD64 da 2 a 96 core, ARM64 da 2 a 64 core alla stessa tariffa e macOS su Apple M4. La virtualizzazione annidata è disponibile su Linux AMD64. Può anche eseguire le build sui Suoi cluster Kubernetes, VM o bare metal. Test Intelligence esegue solo i test interessati da una modifica, e Build Intelligence e le funzionalità di cache riutilizzano output e dipendenze invariati.
Funzionalità di supply chain nella pipeline. Lo step SBOM Orchestration del modulo SCS genera una SBOM per un'immagine container o un repository di codice con Syft o cdxgen, in SPDX o CycloneDX, e può acquisire SBOM da altri strumenti. Harness afferma di generare e aggiornare le SBOM a ogni build. Le policy OPA possono bloccare build e deployment in base a componenti, licenze o provenance, e un tracker di remediation segue gli artefatti vulnerabili.
Provenance SLSA. Harness documenta SLSA Build Level 1, 2 e 3 secondo SLSA v1.0, con provenance firmata tramite attestazioni in-toto e cosign. La sua documentazione afferma che il Level 3 richiede un'infrastruttura di build rafforzata o Harness Cloud, che isola i processi di build tra loro.
Controlli di postura e sulla pipeline. SCS verifica repository e pipeline rispetto a OWASP Top 10 CI/CD Security Risks e ai benchmark CIS, e segnala GitHub Actions non fissate, non verificate e con permessi eccessivi. Harness offre inoltre i suoi step SCS come componenti GitHub Actions e GitLab CI/CD, quindi il modulo non è legato a Harness CI; quegli step richiedono un account Harness con una licenza SCS.
In che cosa CRACI è diverso
La SBOM proviene dalla build, non da una scansione del suo output
Syft e cdxgen sono scanner: leggono un'immagine o un repository a posteriori e deducono che cosa contiene da lockfile, manifest e database dei pacchetti. Funziona bene quando quei file raccontano tutta la storia. Le build spesso fanno di più: gli script di installazione scaricano codice, gli script di build Rust scaricano durante la build e le cache ripristinano pacchetti che nessun lockfile menziona.
CRACI vede quel traffico perché è il runner. Un proxy che riconosce i pacchetti registra ciò che ogni job scarica dalle sorgenti dei pacchetti, per npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download, e le evidenze sulle dipendenze viaggiano con le cache CI. Registra le dipendenze nascoste che gli strumenti basati sui lockfile non vedono, e ogni SBOM indica quanto è completa, per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
Una policy sulla rete della build, non un rilevamento a posteriori
Harness afferma che il suo modulo rileva comportamenti anomali dei runner CI, comprese chiamate di rete ed escalation dei privilegi. CRACI segue l'altra strada: una policy di egress sul runner decide quali host può raggiungere un job. Le policy sono a negazione o autorizzazione predefinita, con 24 preset integrati di sorgenti software e sorgenti personalizzate tipizzate, validate prima dell'avvio del job, e operano in modalità fail closed. Poiché una policy di negazione predefinita consente solo ciò di cui la build ha bisogno, invece di cercare host notoriamente malevoli, blocca l'esfiltrazione verso il server di un attaccante anche in caso di un attacco mai visto prima. Le violazioni generano un avviso.
Provenance e monitoraggio dalla stessa registrazione
L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance e non dichiara alcun livello SLSA; Harness firma la propria provenance e documenta i Level da 1 a 3, e se la provenance firmata o un livello SLSA è un requisito di procurement, questo conta a favore di Harness. CRACI aggrega le vulnerabilità tra build e repository, continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory e mostra quali build passate contenevano una dipendenza vulnerabile, così Lei conosce il periodo in cui è stato esposto.
Prezzi comprensibili
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 costo per SBOM. Harness pubblica le tariffe di Harness Cloud, $0.005 al minuto per una macchina Linux a 2 core con 7 GB e $0.080 per 32 core, fatturate al minuto più vicino, mentre i suoi piani a pagamento e il modulo SCS hanno prezzi definiti tramite il reparto vendite. Il prezzo di listino di CRACI è inferiore del 20% al minuto in entrambe le dimensioni ($0.004 contro $0.005, $0.064 contro $0.080); le macchine Harness hanno più memoria per core.
Quale scegliere
- Resti su Harness se vuole CI, CD, feature flag e gestione dei costi da un solo vendor, se il Suo codice è su GitLab, Bitbucket o Azure Repos, se Le servono Windows, macOS o hardware di build proprio, oppure se un SLSA Build Level 3 documentato è un requisito.
- Scelga CRACI se il Suo codice è su GitHub, usa o intende usare GitHub Actions e vuole che SBOM, policy di rete e provenance provengano dal runner che ha eseguito la build, con un prezzo al minuto di build.
Sia consapevole di ciò a cui rinuncia scegliendo CRACI. Non distribuisce software, non gestisce feature flag né i costi cloud, e non verifica repository e pipeline rispetto a benchmark di postura né scansiona il codice sorgente. Oggi esegue solo job Linux, con Windows e macOS in roadmap, e i runner ospitati dal cliente sono in roadmap per Enterprise.
Per i prodotti regolamentati
Framework come il Cyber Resilience Act dell'UE si aspettano che i fabbricanti sappiano che cosa c'è in ogni release e ne gestiscano le vulnerabilità, con obblighi di segnalazione da settembre 2026. Harness fornisce SBOM, provenance e risultati delle policy dai suoi step di pipeline. CRACI produce le evidenze dalla registrazione della build ed esporta le SBOM in CycloneDX o SPDX. Automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui un'azienda ha bisogno per il suo più ampio processo CRA; nessuno dei due strumenti rende conforme un prodotto da solo.
Spostare una pipeline su CRACI
CRACI sostituisce il runner, non GitHub Actions, e le esecuzioni continuano a comparire nell'interfaccia di GitHub. Una volta che una pipeline gira come workflow GitHub Actions, gira su CRACI con una sola riga:
runs-on: craci
Approfondisca la generazione di SBOM in fase di build, confronti le piattaforme CI/CD, veda le alternative a Harness oppure consulti i prezzi.
Esegua una build reale e confronti
Indirizzi un workflow GitHub Actions su CRACI e confronti la sua SBOM con quella prodotta oggi da uno step di scansione.
Prenota una demo