Il Cyber Resilience Act (CRA) dell'Unione Europea (UE) rappresenta una normativa che definisce una nuova fase per tutti i prodotti con elementi digitali. Con la piena applicazione normativa prevista per l'11 dicembre 2027, oltre ad altri requisiti obbligatori che arriveranno in anticipo, è essenziale che i team di engineering e i product manager comprendano la normativa. Dopotutto, i produttori hanno la responsabilità primaria di garantire che tutti i dispositivi siano conformi prima dell'immissione sul mercato.
Oltre alla piena responsabilità in caso di incidenti di cybersecurity, le sanzioni per la non conformità sono severe:
- Multe fino a 15 milioni di euro o il 2,5% del fatturato annuo globale, con prodotti non conformi vietati, ritirati o richiamati dai mercati UE.
- Perdita della marcatura CE, il che significa che i prodotti non possono più essere venduti legalmente nell'UE.
- Possibile esclusione automatica da gare d'appalto e partnership, poiché molte richieste di offerta (RFP) richiedono soluzioni conformi al CRA.
Inoltre, i produttori che risultano allineati rischiano di perdere credibilità e fiducia sul mercato poiché i clienti dei settori critici (come quelli governativi, finanziari e industriali) evitano prodotti privi di garanzie di sicurezza complete.
Alla luce di questi rischi, i system designer devono ora considerare le implicazioni di sicurezza delle principali scelte hardware e software fin dall'inizio del processo di progettazione, poiché entrambi influenzeranno la compliance di lungo periodo e quindi l'accesso al mercato. Questo articolo definisce i principali obblighi di sicurezza dei produttori ai sensi del CRA prima di evidenziare gli aggiornamenti over-the-air (OTA) come una strategia efficace per mantenere la conformità a lungo termine. Successivamente, delinea un solido framework software per distribuire questi aggiornamenti in modo sicuro e fornisce un esempio di una soluzione commercial-off-the-shelf (COTS) allineata a questi principi.
Obblighi di sicurezza ai sensi del CRA
Dai dispositivi di consumo ai componenti di infrastruttura distribuita, i moderni sistemi edge sono esposti a un numero crescente di vulnerabilità di sicurezza. Firmware obsoleti e protocolli di comunicazione non sicuri possono causare violazioni dei dati e accessi non autorizzati che compromettono l'integrità dei dispositivi. Di conseguenza, il CRA impone diverse misure per ridurre al minimo la superficie di attacco:
In primo luogo, i produttori devono proteggere i dispositivi da manomissioni non autorizzate e garantire l'integrità del software fin dal primo avvio. Sebbene il CRA non definisca un framework specifico per raggiungere questo obiettivo, il secure boot, in combinazione con una root-of-trust (RoT), rappresenta una base fondamentale per soddisfare questo requisito.
Il secure boot utilizza la crittografia per garantire che venga eseguito solo software autentico e verificato sul dispositivo. Questa RoT costituisce il primo anello in una catena di fiducia che autentica ogni fase del processo di avvio per garantire l'integrità del dispositivo, come mostrato in Figura 1. Se, ad esempio, un hash di un componente software è crittografato con una chiave privata che non corrisponde alle chiavi pubbliche nella RoT—a causa di manomissioni o corruzione—il processo di avvio viene interrotto o limita le capacità del sistema superiore (come l'accesso alla rete) per prevenire la potenziale diffusione di malware o botnet.
I produttori devono garantire l'integrità tramite una gestione continua delle vulnerabilità e aggiornamenti di sicurezza tempestivi lungo l'intero ciclo di vita del prodotto. Il CRA definisce un periodo di supporto obbligatorio di almeno 5 anni, o pari alla vita utile del prodotto, se inferiore, e richiede che i produttori forniscano una data specifica di fine supporto al momento del rilascio sul mercato.
Quando viene scoperta una vulnerabilità attivamente sfruttata, i produttori devono segnalarla al loro Computer Security Incident Response Team (CSIRT) nazionale e all'Agenzia dell'Unione europea per la cybersicurezza (ENISA), l'agenzia dell'UE per la sicurezza informatica. Questo obbligo di segnalazione entra in vigore l'11 settembre 2026, con le seguenti tempistiche:
- 24 ore: i rapporti di allerta precoce devono essere inviati a ENISA e al CSIRT nazionale.
- 72 ore: deve essere generata una notifica formale di vulnerabilità che dettagli l'exploit e il suo impatto sul sistema.
- 14 giorni: deve essere presentato un rapporto finale una volta disponibile una patch di sicurezza.
Naturalmente, la gestione continua delle vulnerabilità richiede un certo livello di monitoraggio delle minacce in tempo reale. Framework pubblici come il sistema Common Vulnerabilities and Exposures (CVE) possono aiutare i produttori a individuare e correggere nuove minacce nei componenti software di terze parti ancora prima che vengano attivamente sfruttate all’interno dei propri dispositivi.
A supporto di questi requisiti, il CRA impone inoltre ai produttori di conservare la documentazione tecnica per ogni aggiornamento. In particolare, deve essere fornita una Software Bill of Materials (SBOM) in un formato leggibile da macchina, come CycloneDX o SPDX, che copra almeno tutte le dipendenze di primo livello. Questo formato consente agli strumenti automatizzati di confrontare ogni build software con i database CVE per identificare nuove vulnerabilità non appena vengono segnalate. I team DevSecOps possono quindi distribuire patch che correggono criticità interne senza introdurre software di terze parti.
Oltre alla SBOM, la conformità al CRA richiede un’ampia documentazione che includa una valutazione di alto livello dei rischi di sicurezza, diagrammi dell’architettura di sistema con una descrizione del processo di sviluppo e del processo di gestione delle vulnerabilità (vedi Figura 2). Questi elementi vengono utilizzati per verificare che il sistema sia secure-by-design secondo le linee guida del CRA. La documentazione registrata deve essere conservata per tutto il ciclo di vita del dispositivo e resa disponibile ad auditor, autorità di sorveglianza e organismi notificati per 10 anni dopo l’immissione sul mercato, oppure per la durata di un periodo di supporto più lungo.
Infine, una dichiarazione formale di conformità (DoC) consente ai produttori di utilizzare la marcatura CE per l’accesso al mercato dell’UE. Il documento DoC contiene informazioni quali il nome e l’indirizzo del produttore, un identificativo univoco del prodotto e riferimenti agli standard e alle specifiche tecniche utilizzati per dimostrare la conformità. Per determinati prodotti digitali che rientrano nelle categorie CRA “Important Class I”, “Important Class II” e “Critical”, devono essere inclusi anche i dettagli di un auditor di terza parte incaricato di verificare la conformità. Tra questi dispositivi rientrano sistemi di controllo industriale, gateway IoT e software per accessi privilegiati, dove eventuali violazioni potrebbero causare danni più ampi alle infrastrutture.
Firmando una DoC, i produttori si assumono la piena responsabilità della conformità al CRA. Considerata la portata di questi obblighi, gli aggiornamenti OTA rappresentano il modo più efficace per distribuire rapidamente le patch e mantenere l’integrità dei dispositivi connessi. Tuttavia, gli aggiornamenti OTA continui richiedono un’architettura software sofisticata, progettata unicamente per supportare aggiornamenti conformi al CRA.
Progettare un’infrastruttura software per patch di sicurezza OTA periodiche
Ai sensi del CRA, i team DevSecOps operano sotto una forte pressione temporale quando devono individuare, caratterizzare e risolvere problemi di sicurezza una volta rilevati. Per semplificare la gestione della sicurezza, i dispositivi embedded beneficiano dei seguenti adeguamenti architetturali:
- Integrated telemetry reporting: raccogliendo dati sullo stato operativo dei dispositivi e inviandoli a una piattaforma cloud, i produttori possono individuare rapidamente bug o exploit nei dispositivi connessi. Il telemetry reporting consente inoltre ai team di verificare l’efficacia delle nuove patch in test reali limitati prima del rollout sull’intera flotta.
- Architettura software altamente modulare e containerizzata: l’isolamento delle minacce contribuisce a ridurre la superficie di attacco se un dispositivo viene compromesso. Ad esempio, la containerizzazione impedisce che un attacco all’interfaccia utente possa accedere al codice core del sistema operativo (OS). Consente inoltre ai singoli componenti software di continuare a funzionare mentre altri vengono aggiornati, riducendo il downtime operativo. Allo stesso modo, il software modulare accelera l’individuazione delle vulnerabilità e riduce il volume di dati richiesto dagli aggiornamenti OTA — e quindi i costi — rispetto agli aggiornamenti di codice monolitici.
- Meccanismi di rollback: interruzioni e anomalie durante gli aggiornamenti OTA possono impedire la corretta installazione delle patch, causando potenzialmente il bricking del dispositivo. I meccanismi di rollback assicurano che un dispositivo possa sempre tornare a uno stato operativo se un aggiornamento non va a buon fine, consentendo ai produttori di rispettare gli obblighi previsti dal CRA e mantenere l’integrità del dispositivo.
Naturalmente, aggiornamenti OTA sicuri richiedono tunnel end-to-end cifrati per garantire che le patch non vengano compromesse durante la trasmissione e che solo firmware firmati e verificati possano essere eseguiti su un dispositivo. Per soddisfare i requisiti di documentazione relativi a ogni patch rilasciata, i produttori beneficiano di framework di sviluppo software che forniscono generazione automatizzata di SBOM e logging.
Tuttavia, implementare framework allineati al CRA può rappresentare un onere significativo per gli sviluppatori che sviluppano software da zero, soprattutto con scadenze normative in rapido avvicinamento. Fortunatamente, le soluzioni COTS possono aiutare i team a soddisfare i requisiti di compliance nei tempi previsti.
Sfruttare i framework software COTS per l’allineamento al CRA
I framework software COTS offrono diversi vantaggi particolarmente rilevanti per il CRA. Il primo riguarda l’accelerazione dello sviluppo per ridurre il time-to-market. Inoltre, sebbene la responsabilità legale della compliance resti in capo ai produttori, soluzioni di terze parti collaudate possono anche ridurre il rischio di incorrere in punti ciechi normativi. In aggiunta, collaborando con partner commerciali, i produttori possono ottenere ulteriore supporto di lungo periodo per la propria infrastruttura software, alleggerendo ulteriormente l'onere sugli sviluppatori.
Un esempio di questo tipo di soluzione è Clea OS di SECO, un’architettura software personalizzabile progettata per sistemi sicuri di livello industriale e dotata di molte funzionalità che semplificano la compliance al CRA. Basato sul progetto open-source Yocto, Clea OS offre riproducibilità e tracciabilità per gli audit CRA, con funzionalità di generazione automatizzata di SBOM a supporto degli obblighi documentali.
A differenza di molti sistemi operativi chiusi, Clea OS è concepito come una foundation Linux OS snella e controllata, che minimizza i componenti non necessari per ridurre la superficie di attacco e migliorare sicurezza e resilienza complessive. La containerizzazione è abilitata tramite Docker per isolare le minacce e consentire l’operatività 24/7 durante le attività di patching. Questo è ulteriormente supportato dal partizionamento A/B, che assicura la presenza costante di un’immagine firmware funzionante sul dispositivo e consente il rollback del firmware attivo in caso di mancata riuscita di un aggiornamento.
Inoltre, Clea OS supporta secure boot, aggiornamenti OTA firmati digitalmente, monitoraggio continuo dei dispositivi in tempo reale insieme al più ampio ecosistema Clea di SECO (come illustrato nella Figura 3) e un Cyber Security Package. Ciò consente ai produttori di massimizzare le opportunità di rilevamento delle minacce e patching, facilitando il rispetto dei requisiti CRA relativi ai lunghi periodi di supporto e rispondendo direttamente a requisiti chiave come meccanismi di aggiornamento sicuri, gestione continua delle vulnerabilità e integrità del sistema.
L’esistenza di soluzioni COTS, tra cui Clea OS di SECO, dimostra che la compliance al CRA non deve necessariamente essere complessa come potrebbe apparire inizialmente. Incoraggiando i team di sviluppo a utilizzare framework software pronti all’uso che consentono elevati livelli di personalizzazione, i produttori possono semplificare la transizione verso un nuovo scenario della cybersecurity, portando al contempo sul mercato prodotti differenziati.