Ogni dispositivo smart contiene firmware costruito con pacchetti open source, SDK di vendor di chip e strumenti scaricati durante la build. A un attacco alla supply chain ne basta uno solo. CRACI esegue le Sue build firmware, registra ogni componente che vi entra e impedisce alla build di raggiungere ciò di cui non ha bisogno.
Gran parte del codice di un dispositivo connesso è stata scritta da altri: una distribuzione Linux embedded, il board support package del vendor di chip, uno stack di rete, qualche centinaio di librerie open source e i crate Rust sottostanti. Gli stessi componenti sono presenti in prodotti di molti marchi, e i dispositivi restano nelle case per anni, spesso molto dopo che qualcuno ha guardato per l'ultima volta che cosa contengono.
Questo rende un solo componente debole molto prezioso per un attaccante. Un difetto in una libreria o in un SDK condiviso apre ogni prodotto che lo contiene, e una release avvelenata raggiunge ogni build che la scarica. Questi incidenti mostrano lo schema.
Diciannove vulnerabilità, fino a CVSS 10.0, in una piccola libreria TCP/IP che i produttori di dispositivi avevano preso in licenza per anni, spesso con un altro nome. Era presente nei prodotti di molti vendor, e molti di loro hanno dovuto prima capire se la distribuivano o meno.
Non si può correggere un componente che non si sa di distribuire.
I difetti nell'SDK di un vendor di chip hanno raggiunto circa 200 modelli di dispositivi di circa 65 produttori: router, telecamere IP, gateway per l'illuminazione smart, giocattoli connessi. Una botnet Mirai li stava già cercando due giorni dopo la pubblicazione dei dettagli.
Il codice del vendor di chip diventa il Suo codice non appena è nel Suo dispositivo.
Una backdoor è stata inserita proprio nel progetto upstream xz, nelle versioni 5.6.0 e 5.6.1. Le immagini Linux embedded includono normalmente librerie di compressione come xz, di solito senza che nessuno le abbia scelte.
L'open source di fiducia può diventare ostile con una sola release.
Gli attaccanti hanno usato i certificati di firma di ASUS per firmare una versione con backdoor della sua utility di aggiornamento e l'hanno distribuita dai server di aggiornamento ufficiali. Kaspersky ha stimato che potrebbe aver raggiunto più di un milione di utenti.
Una firma valida dimostra solo chi ha firmato, non che cosa c'è dentro.
L'hardening dei dispositivi, come secure boot, assenza di password predefinite e porta di debug chiusa, protegge il dispositivo che Lei distribuisce. I passaggi seguenti proteggono ciò che vi entra.
CRACI copre il lato build di questo elenco: la SBOM di ogni build, le SBOM dei fornitori, il monitoraggio continuo, l'isolamento delle build, il controllo dell'egress e i policy gate. La firma e l'hardening dei dispositivi restano affidati ai Suoi strumenti.
Esegua le Sue build Yocto e di altri sistemi Linux embedded sui runner GitHub Actions di CRACI, fino a 32 vCPU, su x86-64 o ARM64 nativo. Durante la build, CRACI registra ogni pacchetto e file scaricato, compresi pacchetti host, sorgenti Git, GitHub Actions e download che nessuna recipe o lockfile elenca. In una build core-image-sato, la SBOM di CRACI conteneva tutti i componenti della SBOM di Yocto più 88 che questa non rilevava, con un package URL per ciascuna delle 653 versioni di crate Rust, così tutte possono essere monitorate per le vulnerabilità.
Ogni job viene eseguito nella propria macchina virtuale isolata sotto una policy di egress convalidata prima dell'avvio del job e in modalità fail closed. Con una policy default-deny, la build raggiunge le Sue sorgenti di pacchetti e nient'altro. Una dipendenza compromessa che tenta di inviare il Suo materiale di firma o i Suoi token all'host di un attaccante viene bloccata e genera un alert, anche quando l'attacco è nuovo e nessuno ha ancora pubblicato un advisory.
Aggiunga le SBOM dei Suoi vendor di chip e degli altri fornitori, e i componenti acquistati verranno monitorati insieme al software che Lei costruisce. Quando emergerà la prossima vulnerabilità di un SDK, il codice del vendor sarà nello stesso record del Suo.
CRACI continua a rivalutare le SBOM monitorate man mano che vengono pubblicate nuove vulnerabilità. Lo storico delle build mostra quali build contenevano la dipendenza vulnerabile, diretta o transitiva, e la vista inventario mostra quali versioni del software sono distribuite in quali prodotti. I team di sicurezza eseguono il triage di ogni risultato e lo inoltrano al team responsabile della correzione, e un policy gate può tenere una CVE specifica fuori da tutte le build successive.
La marcatura CE ai sensi del Cyber Resilience Act si basa sulla documentazione tecnica e su una valutazione della conformità. CRACI fornisce le evidenze sulla supply chain necessarie a tale documentazione: SBOM in fase di build esportate in CycloneDX o SPDX, registri delle vulnerabilità e storico delle build. CRACI presenta inoltre le notifiche di vulnerabilità CRA per Suo conto. La valutazione della conformità, la dichiarazione di conformità UE e la marcatura CE restano a carico Suo, in quanto fabbricante.
CRACI non firma firmware, SBOM né provenance, e non rileva nuovi pacchetti malevoli in base a comportamento o reputazione: segnala una release malevola quando esiste un advisory con una CVE e fino ad allora si affida alla policy di egress. Non esegue la Sua valutazione della conformità né redige la Sua dichiarazione di conformità. Oggi esegue job GitHub Actions su runner Linux; GitLab CI, Jenkins e i runner Windows e macOS sono in roadmap.
Domande comuni sulla protezione dei dispositivi connessi e della loro software supply chain
È un attacco che raggiunge un dispositivo attraverso qualcosa da cui dipende il suo produttore, anziché attraverso il dispositivo stesso: una libreria open source vulnerabile, l'SDK di un vendor di chip, una release di pacchetto avvelenata, uno strumento di build compromesso o un canale di aggiornamento dirottato. Poiché lo stesso componente è presente in molti prodotti, una sola debolezza può raggiungere contemporaneamente milioni di dispositivi di molti marchi.
Si parte da ciò che si distribuisce: conservare una SBOM per ogni build firmware, tracciare i componenti dei fornitori e continuare a controllare le versioni distribuite man mano che emergono nuove vulnerabilità. Occorre blindare la build stessa, tenere fuori le versioni notoriamente pericolose con i policy gate, proteggere le chiavi di firma e disporre di un processo per triage, correzioni e divulgazione. Anche l'hardening dei dispositivi, come secure boot e disattivazione delle password predefinite, è importante, ma non serve se il firmware contiene già un componente vulnerabile.
Bisogna conoscere ogni componente che entra nell'immagine, compreso ciò che la build scarica al di fuori di recipe e lockfile, e conservare questo record per ogni release. Occorre compilare in un ambiente isolato che raggiunga solo le sorgenti necessarie, così una dipendenza malevola non può inviare i Suoi secret da nessuna parte. I componenti registrati e le SBOM dei fornitori vanno monitorati rispetto alle nuove vulnerabilità per tutto il tempo in cui i dispositivi sono supportati.
Sì. Le build Yocto e BitBake vengono eseguite sui runner CRACI, e CRACI registra la SBOM del job durante la build. L'output SPDX di Yocto contiene comunque metadati delle recipe che CRACI non registra, come le patch applicate e le CVE che una recipe indica come corrette, quindi mantenga attivo create-spdx se ne ha bisogno.
Sì, se dispone di una SBOM per tali SDK. Può aggiungere le SBOM dei vendor a CRACI, e quei componenti verranno monitorati insieme al software che Lei costruisce. Anche tutto ciò che la Sua build scarica da un vendor durante la build viene registrato nella SBOM del job.
Non in base a comportamento o reputazione. Una release malevola nota con una CVE pubblicata, come la backdoor di xz, viene segnalata come qualsiasi altra vulnerabilità, e un policy gate può bloccare le build che la contengono. Contro gli attacchi nuovi, la protezione di CRACI è la policy di egress default-deny, che impedisce alla build di raggiungere host di cui non ha bisogno.
No. CRACI non firma firmware, SBOM né provenance. Continui a usare il Suo processo di firma e un archivio delle chiavi basato su hardware per release e aggiornamenti.
Il Cyber Resilience Act riguarda i prodotti con elementi digitali immessi sul mercato dell'UE, il che include la maggior parte dei dispositivi di consumo connessi. Gli obblighi di segnalazione si applicano dall'11 settembre 2026 e il regolamento si applica integralmente dall'11 dicembre 2027. CRACI automatizza una parte significativa della visibilità sulla supply chain e delle evidenze necessarie al processo CRA; soddisfare il regolamento resta un processo del fabbricante.
CRACI esegue job GitHub Actions su runner Linux, x86-64 e ARM64, da 1 a 32 vCPU. Altri sistemi CI, come GitLab CI e Jenkins, sono in roadmap, così come i runner Windows e macOS.
Prenoti una demo e Le mostreremo ogni componente scaricato dalle build dei Suoi dispositivi, e quali sono vulnerabili
Prenota una demo