Cyber Resilience Act: ciò che il regolamento impone ai software, e da quando

In breve:

• Dall'11 settembre 2026: ogni editore di un prodotto con elementi digitali deve notificare all'ENISA le vulnerabilità attivamente sfruttate e gli incidenti gravi. I termini sono un avviso entro 24 h, una notifica entro 72 h, poi un rapporto finale entro 14 giorni dalla disponibilità di una correzione.
• Dall'11 dicembre 2027: l'immissione sul mercato europeo sarà condizionata ai requisiti del regolamento. Si tratta della sicurezza by design e per impostazione predefinita, dell'assenza di vulnerabilità sfruttabili note, di un inventario dei componenti software (SBOM, Software Bill of Materials), di patch di sicurezza per almeno cinque anni dopo la prima commercializzazione e di una politica di divulgazione coordinata delle vulnerabilità, che consente a terzi di segnalare una falla.

Partner tech e AI di oltre 800 aziende, Galadrim progetta e mantiene numerosi software e applicazioni. Su questi progetti, i nostri ingegneri applicano già le buone pratiche che il Cyber Resilience Act (CRA) rende ora obbligatorie: sicurezza by design, sviluppo sicuro, gestione delle dipendenze, monitoraggio delle vulnerabilità, distribuzione rapida delle correzioni e mantenimento in condizioni di sicurezza. Tuttavia, rimangono poco diffuse, e molte applicazioni dovranno essere messe in conformità. Questa responsabilità incombe all'editore, cioè all'azienda che commercializza il prodotto sotto il proprio nome, che il regolamento chiama il fabbricante.

Un simulatore, più in basso nell'articolo, ti indica se il tuo prodotto è coinvolto.

Ciò che il CRA richiede da un prodotto digitale

Il Cyber Resilience Act è un regolamento europeo, di applicazione diretta come il GDPR. È stato adottato dal Parlamento europeo il 12 marzo 2024. È il primo testo europeo a imporre requisiti di cybersicurezza all'insieme dei «prodotti con elementi digitali».

Solo la segnalazione è in vigore dall'11 settembre 2026; i requisiti di sicurezza si applicheranno l'11 dicembre 2027.

Dall'11 settembre 2026: l'obbligo di segnalazione

L'editore deve segnalare due tipi di eventi:

• una vulnerabilità attivamente sfruttata, cioè di cui elementi affidabili mostrano che un attore malevolo l'ha utilizzata per compromettere un sistema;
• un incidente grave, cioè un evento che minaccia la protezione dei dati e delle funzioni del prodotto, o che vi introduce codice malevolo.

La notifica deve essere fatta sulla piattaforma unica di segnalazione dell'ENISA. A partire dall'identificazione dell'incidente o della vulnerabilità, sei tenuto a rispettare questi termini:

• 24 h: allerta precoce;
• 72 h: notifica dettagliata, con la natura dello sfruttamento, le misure correttive e le misure raccomandate agli utenti;
• rapporto finale: 14 giorni dopo la messa a disposizione di una correzione per una vulnerabilità, o un mese dopo la notifica per un incidente.

L'editore deve anche informare gli utenti interessati della vulnerabilità o dell'incidente, e delle misure da applicare per proteggersene, in un formato strutturato e leggibile da macchina.

Rispettare il termine di 24 h significa sapere in ogni momento quali versioni del prodotto sono implementate e quali componenti ciascuna incorpora, di supervisionare il backend per rilevare uno sfruttamento, e di avere una procedura di segnalazione con un responsabile designato.

Desideri prepararti, o il tuo prodotto è colpito da una falla? I nostri team ti aiutano a organizzarti per segnalare e correggere nei tempi previsti. Parla con i nostri esperti

Dall'11 dicembre 2027: i requisiti di sicurezza

L'editore potrà immettere sul mercato solo un prodotto conforme ai requisiti del regolamento. Dovrà:

• progettare un prodotto sicuro di default: configurazione sicura fin dall'installazione, superficie di attacco ridotta, accessi e dati protetti da autenticazione, crittografia e registrazione;
• fornire un prodotto senza vulnerabilità sfruttabili note, verificabile sull'insieme delle dipendenze incorporate, non solo sul codice sviluppato internamente;
• mantenere una SBOM, l'inventario leggibile da macchina dei componenti del prodotto;
• correggere ogni vulnerabilità appena scoperta, tramite aggiornamenti di sicurezza gratuiti e distinti dagli sviluppi funzionali;
• diffondere questi aggiornamenti in modo sicuro, ad esempio firmati affinché il dispositivo verifichi che provengano effettivamente dall'editore;
• garantire questo monitoraggio per almeno cinque anni dopo la prima commercializzazione;
• pubblicare una politica di divulgazione coordinata delle vulnerabilità: un punto di contatto e una procedura affinché terzi possano segnalargli una falla.

Queste buone pratiche sono quelle che applichiamo sui software che sviluppiamo e manteniamo.

Perché la conformità è innanzitutto un lavoro tecnico

Le dipendenze. Un'applicazione incorpora centinaia di componenti open source, dal linguaggio alle librerie. Ciascuno può introdurre una vulnerabilità, per errore o volontariamente durante un attacco alla catena di approvvigionamento (supply chain attack). Una volta nota, la vulnerabilità può essere sfruttata automaticamente su tutte le versioni non aggiornate: le vulnerabilità PHP2Shell, pubblicate il 21 ottobre 2026, sono state sfruttate non appena divulgate. Su un progetto datato, correggere spesso impone di aggiornare la versione di un framework che non è più mantenuto.

Il monitoraggio continuo. Durante tutto il periodo di supporto, occorre monitorare le vulnerabilità pubblicate (CVE, avvisi del CERT-FR) su ogni componente.

Con l'ascesa dell'AI nello sviluppo, il volume di codice prodotto aumenta, e gli strumenti di analisi assistiti dall'AI rilevano le vulnerabilità sempre più velocemente. Il collo di bottiglia diventa la correzione: tria, corregge, testa e implementa su tutte le versioni in circolazione prima dello sfruttamento.

Possiamo implementare queste pratiche sul tuo prodotto o accompagnare i tuoi team. Parla con i nostri esperti

Il tuo prodotto è coinvolto?

Il CRA si applica ai prodotti con elementi digitali venduti o distribuiti nell'Unione Europea nell'ambito di un'attività commerciale. Un prodotto è coinvolto se l'utente installa un software sul proprio dispositivo. È il caso di un'applicazione mobile, di un'applicazione desktop, di un'estensione del browser, di un software distribuito sui server del cliente o del software embedded di un oggetto connesso. Anche i server indispensabili al funzionamento di questo software sono coinvolti, ad esempio il backend di un'applicazione mobile o il suo modulo di pagamento. Sono esclusi:

• le applicazioni web utilizzate solo nel browser, senza nulla da installare, a meno che non siano indispensabili al funzionamento di un software coinvolto;
• i software sviluppati e utilizzati esclusivamente internamente;
• i prodotti soggetti a regolamentazione settoriale: dispositivi medici, veicoli, aeronautica certificata, attrezzature marine e difesa.

L'azienda che commercializza il prodotto è responsabile della sua conformità, ma il fornitore incaricato del suo sviluppo ha anche degli obblighi: fornire la SBOM, correggere le vulnerabilità nei tempi previsti e garantire il supporto per la durata stabilita.

Per un prodotto già commercializzato, la segnalazione si applica già da oggi. I requisiti del 2027 si applicheranno solo in caso di modifica sostanziale dopo l'11 dicembre 2027, vale a dire un'evoluzione che modifica l'uso previsto del prodotto o ne compromette la conformità. Le patch di sicurezza non ne fanno parte.

Le inadempienze espongono a una multa fino a 15 M€ o al 2,5% del fatturato mondiale, e al ritiro del prodotto dal mercato.

Simulatore: il tuo prodotto è coinvolto?

Rispondi a quattro domande per sapere se il CRA si applica al tuo prodotto.

Oltre a questa diagnosi, accompagniamo le aziende in tutta la loro messa in conformità, dall'audit alla correzione delle vulnerabilità. Parla con i nostri esperti

Lessico

• Falla : vulnerabilità di un sistema informatico che permette a un attaccante di compromettere il suo funzionamento normale, o la confidenzialità o l'integrità dei dati che contiene (ANSSI).
• Vulnérabilité : debolezza o difetto di un prodotto che può essere sfruttato da una minaccia.
• Vulnérabilité attivamente sfruttata : vulnerabilità di cui elementi affidabili mostrano che un attore malevolo l'ha utilizzata senza l'autorizzazione del proprietario del sistema.
• Incidente grave : evento che compromette, o può compromettere, la disponibilità, l'integrità o la confidenzialità dei dati o delle funzioni di un prodotto, o che vi introduce codice malevolo.
• SBOM (Software Bill of Materials) : inventario formale dei componenti di un software, delle loro versioni e delle loro dipendenze.
• CVE (Common Vulnerabilities and Exposures) : identificativo pubblico standardizzato attribuito a una vulnerabilità nota.
• ENISA : Agenzia dell'Unione Europea per la cybersicurezza, che opera la piattaforma di segnalazione del CRA.
• CSIRT : centro di risposta agli incidenti di sicurezza informatica. In Francia, il CERT-FR, operato dall'ANSSI, è il CSIRT nazionale (ANSSI).
• CI/CD (integrazione e implementazione continui) : catena automatizzata che testa e poi mette in produzione ogni modifica del codice.

Sull'autore

Harold Stern è Expert Cybersicurezza e Conformità presso Galadrim. Sviluppa questa offerta, a fianco del team di sicurezza applicativa.