Confronto
CRACI vs NetRise
NetRise guarda all'interno del software compilato che gira sui dispositivi, qualunque sia la sua origine. CRACI registra ciò che le Sue build hanno scaricato durante l'esecuzione. Un team di product security di solito ha bisogno di entrambe le risposte, per parti diverse di ciò che distribuisce.
Aggiornato il
La risposta breve
NetRise è un'azienda di analisi dei binari. Il suo prodotto Turbine analizza firmware, immagini container e binari applicativi per produrre una SBOM dal codice compilato e individuarne i rischi, tra cui vulnerabilità, secret esposti, configurazioni errate e crittografia. Il 21 settembre 2026 Dragos ha annunciato di aver acquisito NetRise. CRACI è un runner GitHub Actions che registra ciò che ogni build scarica durante l'esecuzione, produce la SBOM da quel record e la monitora dopo la release. NetRise analizza l'output, compreso il software che Lei non ha compilato; CRACI conserva le evidenze delle build che Lei esegue. Per un PSIRT i due coprono ambiti diversi.
In sintesi
| Funzionalità | CRACI | NetRise |
|---|---|---|
| Esegue le Sue build CI | I job girano sui runner CRACI | Analizza l'artefatto compilato |
| Registra ciò che la build ha scaricato | Osservato dal runner durante ogni job | Lavora sul software distribuito |
| SBOM dal binario o firmware finito | Comprende codice linkato staticamente e incorporato | |
| Funziona su firmware che Lei non ha compilato | La build deve girare su CRACI | Software che Lei compila, acquista ed esegue |
| Risultati oltre le CVE note | Secret, chiavi, certificati, configurazioni errate | |
| Analisi di raggiungibilità | Percorso di esecuzione fino al componente vulnerabile | |
| SBOM in CycloneDX e SPDX | Dalla build, con uno stato di completezza | Importazione, arricchimento ed esportazione di entrambi i formati |
| SBOM dei fornitori | È possibile aggiungere SBOM dei vendor | Caricamento, combinazione e arricchimento |
| Monitoraggio dopo la release | Rivaluta di continuo le SBOM monitorate | Controlla di continuo NVD, CISA KEV e dati sulle minacce |
| Triage delle vulnerabilità e VEX | Triage, instradamento ai team e VEX | Workflow Jira e ServiceNow; VEX non dichiarato |
| Policy di egress durante la build | Verificata prima del job, fail closed | Non dichiarato; Provenance blocca i pacchetti tramite policy |
| Sistemi CI | Oggi GitHub Actions; GitLab CI e Jenkins in roadmap | API GraphQL per CI/CD; GitHub indicato come input |
| Prezzi | Pagamento per minuto di build: $0.004 per minuto a 2 vCPU, misurato al secondo. Nessun canone mensile e nessun costo per SBOM. | Non pubblicati |
- Incluso
- In parte
- Non incluso
Che cosa fa bene NetRise
SBOM dal codice compilato. NetRise Turbine ricava dal software stesso una SBOM completa basata sui binari, comprese le dipendenze linkate staticamente e incorporate. Copre firmware, immagini container e binari applicativi, fino a kernel, RTOS, driver e firmware sotto il livello applicativo. È il modo per vedere all'interno del software di produttori di chip, fornitori di moduli e altri vendor le cui build Lei non vede mai.
Rischi che una scansione delle CVE non mostra. Turbine segnala secret, chiavi pubbliche e private, certificati e configurazioni errate presenti nell'artefatto, oltre a problemi di licenza e a un inventario crittografico per la preparazione al post-quantum. NetRise ZeroLens cerca le debolezze nel software compilato prima che vengano sfruttate.
Prioritizzazione. Turbine verifica se un percorso di esecuzione tracciabile collega un punto di ingresso in esecuzione a un componente vulnerabile e mostra segnali di sfruttabilità come lo stato CISA KEV. NetRise afferma che la piattaforma scansiona di continuo NVD, il catalogo CISA KEV, gruppi di threat actor e botnet per ricavare indicazioni sulla sfruttabilità.
SBOM dei fornitori e integrazioni. NetRise supporta importazione, arricchimento, normalizzazione ed esportazione di SPDX e CycloneDX, così è possibile combinare SBOM provenienti da più fonti. Offre un'API GraphQL per CI/CD ed elenca integrazioni con Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub e Google Cloud.
Provenance dell'open source. NetRise Provenance esamina origine, maintainer e stato di salute dei repository dei componenti open source e blocca i pacchetti malevoli o che violano le policy nel punto in cui gli sviluppatori li scaricano, anche in CI/CD e negli assistenti di coding AI.
Ora parte di Dragos. L'annuncio di Dragos afferma che NetRise aggiunge visibilità sul firmware e sul software in esecuzione sui dispositivi di operational technology e che la leadership di NetRise lo integrerà nella Dragos Platform continuando a servire i clienti esistenti. Non sono state rese note condizioni finanziarie.
In che cosa CRACI è diverso
Un'analisi dei binari lavora a ritroso da ciò che è stato distribuito. CRACI parte dalla build e procede in avanti, perché la build gira su CRACI.
La build è la fonte di verità
Il Suo workflow gira sui runner CRACI con la modifica di una sola riga in runs-on. Durante l'esecuzione di un job, un proxy che riconosce i pacchetti registra ciò che viene scaricato dalle sorgenti dei pacchetti, e i pacchetti ripristinati dalle cache CI vengono riportati nel record. Ogni SBOM dichiara quanto è completa, per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Per Yocto, CRACI esegue BitBake su runner fino a 32 vCPU e 96 GB di RAM. In una build affiancata di core-image-sato, la SBOM di CRACI conteneva ogni componente dell'output SPDX di Yocto, altri 88 come pacchetti host e GitHub Actions, e un package URL per ciascuna delle 653 versioni di crate Rust che Yocto elenca senza indicarlo.
Controllo su ciò che la build può raggiungere
Una policy di egress sul runner decide a quali host un job può connettersi. Viene convalidata prima dell'avvio del job, opera in modalità fail closed e invia un avviso in caso di violazione. Una scansione dell'output non può cambiare ciò che la build ha potuto raggiungere.
Da una CVE ai prodotti colpiti
CRACI aggrega le vulnerabilità tra build e repository e continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory. La cronologia delle build mostra quali build contenevano una dipendenza vulnerabile, diretta o transitiva, così Lei conosce il periodo di esposizione, e la vista inventario mostra esattamente quali versioni del software sono distribuite in quali prodotti. I team di sicurezza esaminano i risultati e assegnano ciascuno al team responsabile della correzione, VEX è supportato e i policy gate possono bloccare una build che contiene una specifica CVE. L'API restituisce SBOM, tracce di rete e provenance.
Conta altrettanto ciò che CRACI non fa. Non analizza i binari, quindi non può vedere all'interno di firmware che Lei non ha compilato o di un blob di un fornitore scaricato dalla Sua build: vede solo che la build lo ha scaricato e da dove. Può aggiungere le SBOM dei vendor per monitorarne i componenti, ma senza una SBOM Le serve uno strumento di analisi dei binari come NetRise. CRACI non offre l'analisi di raggiungibilità e non cerca secret o configurazioni errate nell'output.
Che cosa serve a un PSIRT da ciascuno
Un product security incident response team deve sapere che cosa viene distribuito in ogni prodotto, firmware di terze parti compreso, individuare i prodotti colpiti quando arriva una vulnerabilità, continuare a monitorare dopo la release, esaminare i risultati e dichiarare quali prodotti non sono colpiti, spesso con VEX.
- Firmware e binari di terze parti che riceve. NetRise. L'analisi dei binari è l'unico modo per vedervi all'interno quando il fornitore non invia una SBOM.
- Firmware e software che compila in GitHub Actions. CRACI registra ogni build durante l'esecuzione e conserva la cronologia di quali build contenevano un componente.
- Prioritizzare un lungo elenco di risultati. I segnali di raggiungibilità e sfruttabilità di NetRise. CRACI mostra che un pacchetto vulnerabile era nella build, non se il Suo codice lo chiama.
- Assegnare un risultato al team responsabile della correzione. Il triage e l'instradamento di CRACI lavorano sulle build che registra; NetRise si collega a Jira e ServiceNow.
Veda CRACI per i team PSIRT e gli strumenti PSIRT a confronto.
Quando usare l'uno, l'altro o entrambi
- La maggior parte di ciò che distribuisce proviene dai fornitori. NetRise. Analizza il software che acquista oltre a quello che compila.
- Compila la Sua immagine Linux o le Sue app in GitHub Actions. CRACI esegue la build e ne registra gli input. Analizzare la stessa immagine in NetRise offre una seconda vista indipendente di ciò che è stato distribuito.
- Gestisce parchi di operational technology. NetRise, ora all'interno di Dragos, è rivolto al firmware e al software in esecuzione su quei dispositivi. CRACI è per i team che sviluppano il software.
- Vuole limitare ciò che le build possono scaricare. CRACI. Questo controllo esiste solo dove gira la build.
Per il CRA
Il Cyber Resilience Act chiede ai fabbricanti di documentare i componenti dei loro prodotti, compresa una SBOM, di gestire le vulnerabilità per tutto il periodo di assistenza e, dall'11 settembre 2026, di segnalare le vulnerabilità attivamente sfruttate. NetRise affronta il CRA con SBOM delle build di release ricavate dall'artefatto compilato, gestione delle vulnerabilità e verifica delle patch tra le versioni, e output di reporting per le evidenze di conformità. CRACI produce evidenze per build di ciò che è entrato nel software che Lei compila, le monitora e invia per Suo conto le notifiche previste dal CRA. CRACI automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui i fabbricanti hanno bisogno nel loro più ampio processo di conformità al CRA; da solo non rende conforme un prodotto. Legga che cosa richiede il CRA.
Aggiungere CRACI accanto a NetRise
Non occorre spostare nulla da NetRise. Sposti il job di build su un runner CRACI impostando runs-on: craci: lo stesso workflow continua a girare in GitHub Actions mentre CRACI registra la build. L'esempio Yocto nella documentazione di CRACI mostra un workflow BitBake completo. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. Veda come funziona CRACI per l'IoT industriale.
Sta valutando più di due strumenti? Alternative a NetRise mette a confronto sette opzioni fianco a fianco.
Porti una build di firmware alla demo
Prenoti una demo: eseguiremo su CRACI una delle Sue build GitHub Actions e vedremo insieme che cosa ha scaricato.
Prenota una demo