Dall'11 settembre 2026, un fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata in un prodotto che ha immesso sul mercato dell’UE deve inviare una notifica di preallarme entro 24 ore. Eppure il Cyber Resilience Act, il regolamento (UE) 2024/2847, non menziona mai i wallet crypto.
L’orologio dell’articolo 14 parte quando il fabbricante ne viene a conoscenza. Dall'11 dicembre 2027 i fabbricanti devono anche effettuare prove e riesami efficaci e periodici della sicurezza del proprio prodotto (allegato I, parte II, punto 3); per un prodotto immesso sul mercato prima di quella data, l’obbligo si applica solo se il prodotto subisce una modifica sostanziale a decorrere da quella data (articolo 69, paragrafo 2). Nella nostra lettura, quell’obbligo incide sul fatto che la conoscenza arrivi dalle vostre stesse prove o dall’exploit di qualcun altro. Si veda Le macchine stanno leggendo il codice.
Questa nota si rivolge a chi produce wallet hardware, wallet software, software di custodia e dispositivi di pagamento. Spiega il criterio che definisce l’ambito di applicazione, cosa presuppongono le 24 ore, cosa aggiunge dicembre 2027 e dove si colloca una revisione adversariale indipendente. Non è consulenza legale e non stabilisce se il vostro prodotto rientri nell’ambito di applicazione.
Un wallet rientra nell’ambito di applicazione?
Il punto di partenza è la definizione di prodotto con elementi digitali data dal regolamento: «qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati da remoto, compresi i componenti software o hardware immesso sul mercato separatamente» (articolo 3, punto 1).
La domanda successiva è se quel prodotto sia messo a disposizione sul mercato. La definizione è «la fornitura, a titolo oneroso o gratuito, di un prodotto con elementi digitali perché sia distribuito o usato sul mercato dell’Unione nel corso di un’attività commerciale» (articolo 3, punto 22). L’articolo 2, paragrafo 1, aggiunge una condizione: il regolamento si applica a tali prodotti «la cui finalità prevista o il cui utilizzo ragionevolmente prevedibile include una connessione dati logica o fisica diretta o indiretta a un dispositivo o a una rete». Nella nostra lettura, un wallet hardware che si collega a un telefono o a un computer, e un wallet software che raggiunge una rete, di solito la soddisferanno. Un dispositivo air-gapped che scambia dati solo tramite codice QR o scheda di memoria può comunque soddisfarla: l’articolo 3, punto 9, definisce la connessione fisica come quella realizzata con mezzi fisici, «anche attraverso interfacce elettriche, ottiche o meccaniche», e l’articolo 3, punto 10, contempla una connessione indiretta che avviene «nell’ambito di un sistema più ampio che è direttamente collegabile a tale dispositivo o rete». Se un determinato dispositivo la soddisfi è una questione da sottoporre a un legale.
Per chi produce wallet, queste definizioni sollevano diverse domande. L’analisi che segue espone la nostra lettura; applicarla a un determinato prodotto richiede il parere di un legale.
Wallet hardware
Un wallet hardware venduto nell’UE corrisponderà spesso alla descrizione di un prodotto hardware contenente software, fornito nel corso di un’attività commerciale. Resta comunque da stabilire se il vostro dispositivo soddisfi il criterio giuridico.
Il suo firmware fa di solito parte del prodotto. Un’app complementare solleva un’ulteriore domanda: fa parte dello stesso prodotto, o è un prodotto a sé stante?
Wallet software e attività commerciale
Per i wallet software, la questione dipende dal fatto che siano messi a disposizione nel corso di un’attività commerciale (articolo 3, punto 22). Il considerando 18 afferma che la fornitura di prodotti con elementi digitali che si qualificano come software liberi e open source non monetizzati dai loro fabbricanti non dovrebbe essere considerata un’attività commerciale.
Individuare il fabbricante è un passaggio distinto. L’articolo 3, punto 13, indica la persona che sviluppa o fabbrica il prodotto, o fa svolgere questo lavoro da altri, e lo commercializza con il proprio nome o marchio, «a titolo oneroso, di monetizzazione o gratuito».
Il considerando 15 afferma che la fornitura nel corso di un’attività commerciale può essere caratterizzata non solo dall’applicazione di un prezzo per il prodotto stesso, ma anche:
- dall’applicazione di un prezzo per servizi di assistenza tecnica, quando ciò non serve soltanto a recuperare i costi effettivi;
- «dall’intenzione di monetizzare, ad esempio dalla fornitura di una piattaforma software attraverso la quale il fabbricante monetizza altri servizi»;
- dal subordinare l’uso del prodotto al trattamento di dati personali per motivi diversi dal solo miglioramento della sicurezza, della compatibilità o dell’interoperabilità del software;
- dall’accettazione di donazioni che superano i costi di progettazione, sviluppo e fornitura del prodotto.
Afferma anche: «L’atto di accettare donazioni senza fini di lucro non dovrebbe essere considerato costitutivo di un’attività commerciale.»
Nella nostra lettura, un wallet che guadagna da commissioni, swap o un livello a pagamento si colloca vicino a questi esempi e può rientrare tra i prodotti «monetizzati» ai sensi del considerando 18. Il regolamento non definisce questo termine, e non ne determiniamo l’applicazione a un determinato prodotto.
Wallet liberi e open source
Il considerando 18 descrive un’esclusione: «la fornitura di prodotti con elementi digitali che si qualificano come software liberi e open source che non sono monetizzati dai loro fabbricanti non dovrebbe essere considerata un’attività commerciale». Un’azienda che monetizza il proprio wallet open source non ottiene quell’esclusione per il solo fatto di pubblicarne il sorgente.
Il considerando si occupa anche delle organizzazioni senza scopo di lucro. Lo sviluppo, da parte loro, di prodotti con elementi digitali che si qualificano come software liberi e open source non dovrebbe essere considerato un’attività commerciale, a condizione che l’organizzazione sia costituita in modo tale da garantire che tutti gli utili al netto dei costi siano utilizzati per conseguire obiettivi senza scopo di lucro.
Afferma inoltre che il regolamento non si applica alle persone fisiche o giuridiche che contribuiscono con codice sorgente a prodotti liberi e open source che non sono sotto la loro responsabilità.
Back end di custodia
Un back end di custodia può ricadere in categorie diverse. Se il back end è esso stesso fornito sul mercato dell’Unione come prodotto, può essere un prodotto con elementi digitali a sé stante (articolo 3, punto 1).
Se elabora dati da remoto per un altro prodotto, l’articolo 3, punto 2, lo considera elaborazione dati da remoto solo se ricorrono entrambe le condizioni: il software è progettato e sviluppato dal fabbricante di quel prodotto o sotto la sua responsabilità, e il prodotto non potrebbe svolgere una delle sue funzioni senza di esso.
Il considerando 12 afferma che la direttiva (UE) 2022/2555 si applica ai servizi di cloud computing e ai modelli di servizi cloud. Quale descrizione si attagli a un determinato sistema di custodia è una questione da sottoporre a un legale.
Prodotti importanti e critici
Il regolamento distingue inoltre i prodotti critici e quelli importanti. Queste classificazioni incidono sulla valutazione della conformità, quindi la distinzione conta indipendentemente dalla questione dell’ambito di applicazione.
L’allegato IV elenca tre categorie di prodotti critici: «Dispositivi hardware con cassette di sicurezza»; i gateway per contatori intelligenti «e altri dispositivi a fini di sicurezza avanzati, compreso il trattamento crittografico sicuro»; e «carte intelligenti o dispositivi analoghi, compresi gli elementi sicuri». L’inclusione nell’elenco incide su quali procedure di valutazione della conformità un prodotto possa utilizzare (articoli 8 e 32).
L’allegato III elenca i prodotti importanti in due classi, con diciannove voci nella classe I e quattro nella classe II. La classe I comprende «sistemi di gestione delle password», «microprocessori con funzionalità legate alla sicurezza» e «microcontrollori con funzionalità legate alla sicurezza». La classe II comprende «microprocessori a prova di manomissione» e «microcontrollori a prova di manomissione».
Un prodotto che ha la funzionalità principale di una categoria dell’allegato III è un prodotto importante. Le relative procedure di valutazione della conformità sono all’articolo 32, paragrafo 2, per la classe I e all’articolo 32, paragrafo 3, per la classe II. L’integrazione di un tale prodotto in un altro non assoggetta, di per sé, il prodotto che lo contiene a quelle procedure (articolo 7, paragrafo 1).
L’articolo 32, paragrafo 5, prevede una via per i prodotti che si qualificano come software liberi e open source e rientrano in una categoria dell’allegato III. I loro fabbricanti sono in grado di dimostrare la conformità mediante una delle procedure di cui all’articolo 32, paragrafo 1, a condizione che la documentazione tecnica di cui all’articolo 31 sia resa pubblica al momento dell’immissione del prodotto sul mercato.
Se una voce dell’allegato III o dell’allegato IV descriva un determinato dispositivo o una determinata app richiede una classificazione giuridica. Non effettuiamo tale determinazione.
Cosa presuppongono le 24 ore
L’articolo 14 stabilisce tre passaggi di segnalazione per una vulnerabilità attivamente sfruttata. Ogni segnalazione va al CSIRT designato come coordinatore e all’ENISA tramite la piattaforma unica di segnalazione:
- Notifica di preallarme: «senza indebito ritardo e in ogni caso entro 24 ore dal momento in cui il fabbricante ne è venuto a conoscenza».
- Notifica delle vulnerabilità: senza indebito ritardo e in ogni caso entro 72 ore dal momento in cui il fabbricante è venuto a conoscenza della vulnerabilità attivamente sfruttata.
- Relazione finale: «entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione».
Il CSIRT competente dipende dallo stabilimento principale del fabbricante nell’Unione. In mancanza di esso, l’articolo 14, paragrafo 7, stabilisce l’ordine dei criteri per individuarlo.
Esiste anche un obbligo separato di informare gli utilizzatori. Dopo esserne venuto a conoscenza, il fabbricante deve informare gli utilizzatori interessati (e, se del caso, tutti gli utilizzatori) della vulnerabilità o dell’incidente. Se necessario, deve anche indicare loro quali misure possono adottare (articolo 14, paragrafo 8). Questo obbligo è distinto dalla notifica di preallarme a 24 ore.
L’orologio parte quando il fabbricante viene a conoscenza. Nella nostra lettura, per la maggior parte dei prodotti la conoscenza arriva da una segnalazione di un utilizzatore o di un ricercatore; per un wallet, il primo segno di un difetto sfruttato è spesso l’exploit stesso: fondi che si muovono senza che il titolare li abbia mossi.
Cosa contiene ciascuna segnalazione
Il passaggio delle 24 ore è un preallarme e non una descrizione del difetto. L’articolo 14, paragrafo 2, lettera a), precisa che, se del caso, esso deve indicare gli Stati membri sul cui territorio il fabbricante è al corrente del fatto che il prodotto è stato messo a disposizione.
La notifica a 72 ore deve fornire informazioni generali, se disponibili. Queste comprendono la natura generale dello sfruttamento e della vulnerabilità, le eventuali misure correttive o di attenuazione adottate e le misure correttive o di attenuazione che gli utilizzatori possono adottare.
La relazione finale deve descrivere la vulnerabilità, compresi la sua gravità e il suo impatto. Deve inoltre fornire informazioni dettagliate sull’aggiornamento di sicurezza o sulle altre misure correttive messe a disposizione per porvi rimedio. Se disponibili, deve includere informazioni su qualsiasi soggetto malintenzionato che abbia sfruttato o stia sfruttando la vulnerabilità.
Nella nostra lettura, gli altri obblighi del regolamento incidono sul tempo che precede la partenza di questo orologio di segnalazione.
Gli incidenti gravi hanno un binario separato
Gli incidenti gravi seguono un binario di segnalazione parallelo, con le stesse prime due scadenze. Ai sensi dell’articolo 14, paragrafo 5, un incidente è grave se incide negativamente, o è in grado di incidere negativamente, sulla capacità del prodotto di proteggere la disponibilità, l’autenticità, l’integrità o la riservatezza di dati o funzioni sensibili o importanti. Un incidente è considerato grave anche se ha portato, o è in grado di portare, all’introduzione o all’esecuzione di codice maligno.
La relazione finale su un incidente grave è dovuta entro un mese dalla notifica dell’incidente (articolo 14, paragrafo 4, lettera c)). La scadenza di 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione appartiene al binario delle vulnerabilità. La nostra nota sulla gestione delle vulnerabilità spiega entrambi i binari di segnalazione.
Cosa aggiunge dicembre 2027
Il regolamento si applica integralmente dall'11 dicembre 2027, quando diventano applicabili i requisiti essenziali di cibersicurezza dell’allegato I. I wallet immessi sul mercato prima di tale data sono soggetti ai requisiti del regolamento «solo se, a decorrere da tale data, tali prodotti sono soggetti a una modifica sostanziale» (articolo 69, paragrafo 2); gli obblighi di segnalazione dell’articolo 14 si applicano loro indipendentemente da tale modifica, purché rientrino nell’ambito di applicazione del regolamento (articolo 69, paragrafo 3). La nostra nota Le norme possono slittare. La data di notifica no. spiega il calendario.
Tre obblighi incidono direttamente sul fatto che un caso da articolo 14 sia raro o di routine. Due vengono dall’allegato I e uno dall’articolo 13.
Rilasciare senza difetti sfruttabili noti. Sulla base della valutazione dei rischi e ove applicabile, i prodotti con elementi digitali «sono messi a disposizione sul mercato senza vulnerabilità sfruttabili note» (allegato I, parte I, punto 2, lettera a)).
Sottoporre a prove e riesami la sicurezza del prodotto. I fabbricanti «effettuano prove e riesami efficaci e periodici della sicurezza del prodotto con elementi digitali» (allegato I, parte II, punto 3). La documentazione tecnica deve contenere «le relazioni delle prove effettuate per verificare la conformità del prodotto con elementi digitali di cibersicurezza e dei processi di gestione delle vulnerabilità ai requisiti essenziali applicabili» (allegato VII, punto 6). Si veda relazione di prova CRA.
Esercitare la dovuta diligenza su ciò che non avete scritto. I fabbricanti «esercitano la dovuta diligenza quando integrano componenti provenienti da terzi affinché tali componenti non compromettano la cibersicurezza del prodotto con elementi digitali» (articolo 13, paragrafo 5). Ciò comprende i componenti open source. Per un wallet, si tratta delle librerie crittografiche, del codice di derivazione e del costruttore di transazioni da cui dipende.
Questi obblighi sono solo una parte dei requisiti. L’allegato I riguarda anche, tra l’altro, la riservatezza e l’integrità di dati e comandi, l’identificazione delle vulnerabilità e dei componenti, compresa una distinta base del software (SBOM), una politica di divulgazione coordinata delle vulnerabilità e aggiornamenti di sicurezza tempestivi.
La non conformità ai requisiti essenziali di cibersicurezza dell’allegato I e agli obblighi di cui agli articoli 13 e 14 è soggetta a sanzioni amministrative pecuniarie fino a 15 000 000 EUR. Se l’autore della violazione è un’impresa, il massimo è pari a tale importo o al 2,5 % del suo fatturato mondiale totale annuo dell’esercizio precedente, se superiore (articolo 64, paragrafo 2).
Nessuno di questi obblighi dipende dal fatto che il codice l’abbia scritto una persona o un modello. Se un modello ha scritto parte del vostro percorso di firma, l’obbligo di averlo sottoposto a prove e riesami resta vostro. Si veda Il vibe coding è sicuro? Cosa ha trovato un banco di prova di 186 compiti reali. La nostra spiegazione della revisione del codice adversariale discute perché un secondo modello non sia automaticamente un secondo testimone.
Dove si rompe il codice dei wallet
Una revisione deve cominciare da qualche parte. Nel codice dei wallet, i punti in cui un difetto può costare denaro sono ben noti. Cominciamo da:
- la generazione delle chiavi e l’entropia su cui si basa;
- il backup e il ripristino del seed, e la derivazione di chiavi e indirizzi;
- la firma, compreso il modo in cui sono prodotti i nonce e se qualcuno possa ripetersi;
- la costruzione delle transazioni, compreso se ciò che il dispositivo mostra sia ciò che firma;
- il percorso di aggiornamento di firmware e app: il regolamento chiede «meccanismi per distribuire in modo sicuro gli aggiornamenti» (allegato I, parte II, punto 7);
- i componenti di terzi da cui dipendono tutti questi elementi (articolo 13, paragrafo 5).
Queste sono fonti di guasti dei wallet in generale. Elencarle non equivale ad affermare che un determinato prodotto contenga un difetto.
Cosa offriamo a un produttore di wallet
Un primo incarico copre un solo componente: quello in cui un difetto costerebbe di più ai vostri utenti. Di solito si tratta della firma, della derivazione delle chiavi o del percorso di aggiornamento. Esaminiamo in modo adversariale una versione specificata e fissata del codice e consegniamo un fascicolo di rilievi firmato.
Ogni rilievo confermato è etichettato secondo il modo in cui è stato accertato: riprodotto mediante un test eseguito sul codice non modificato, oppure letto da quel codice senza eseguirlo. Il fascicolo non presenta mai un rilievo per più di quanto le sue evidenze sostengano. Indica anche ogni superficie esaminata senza rilievi e il metodo usato per esaminarla.
I revisori sono indipendenti dall’autore del vostro codice, e una persona con nome e cognome risponde del fascicolo. Un rilievo si chiude quando il revisore che lo ha sollevato lo ritira o quando è dimostrato contro il codice. Si veda Un rilievo non è un verdetto e What settles a finding.
Il fascicolo documenta la prova e il riesame del componente esaminato. Fornisce evidenze a sostegno delle prove e dei riesami efficaci e periodici richiesti dall’allegato I, parte II, punto 3. Quell’obbligo copre l’intero prodotto e richiede un lavoro ricorrente, quindi un solo incarico non può assolverlo. Né il fascicolo costituisce, di per sé, le relazioni delle prove che, secondo l’allegato VII, punto 6, la documentazione tecnica deve contenere. Lo stesso metodo di revisione può poi essere applicato al resto del prodotto.
Una revisione di un componente non rende conforme il vostro prodotto né stabilisce se rientri nell’ambito di applicazione o sia importante o critico. Non predispone la vostra segnalazione ai sensi dell’articolo 14 né sostituisce un organismo notificato dove ne sia richiesto uno.
I nostri cinque no pongono ulteriori limiti a ciò che affermiamo. Tra questi: l’accordo tra modelli di IA non è una prova, e una revisione che non trova nulla non stabilisce che non ci sia nulla.
Le disposizioni del CRA citate rinviano al regolamento (UE) 2024/2847 e sono state verificate rispetto alla versione linguistica italiana ufficiale; le citazioni tra virgolette ne riproducono il testo alla lettera. Questa pagina è una traduzione dell’originale inglese; in caso di divergenza prevale l’originale. Se qualcosa qui è errato, lo correggeremo per iscritto su questa pagina.