Nel futuro digitale anche il software avrà i suoi “ingredienti”.
Quando mio figlio sarà abbastanza grande da scegliere da solo uno snack, potrà girare la confezione e leggere che cosa contiene. Zucchero, cacao, conservanti, frutta secca. Magari non comprenderà ogni termine, ma quella lista esiste. Qualcuno ha dovuto dichiarare gli ingredienti prima di vendere il prodotto.
Quando scaricherà un’applicazione, comprerà un giocattolo connesso o installerà un programma, le cose saranno meno intuitive. Vedrà un’icona, qualche schermata e un pulsante con scritto “Accetta”. Difficilmente saprà quanti componenti software lavorano sotto la superficie, da dove provengono e quale di essi potrebbe diventare vulnerabile.
Il Cyber Resilience Act prova a cambiare proprio questo rapporto.
Mi piace chiamarlo “approccio snack”: il software, come una merendina, deve avere i suoi ingredienti.
La lista degli ingredienti del software
Un programma non è quasi mai scritto interamente da chi lo vende. Contiene librerie open source, framework, moduli crittografici, componenti prodotti da terzi e, in molti casi, servizi remoti necessari al suo funzionamento.
Questi sono gli ingredienti del software.
Il loro inventario prende il nome di Software Bill of Materials, normalmente abbreviato in SBOM. Il Cyber Resilience Act impone ai fabbricanti di identificare e documentare le vulnerabilità e i componenti presenti nei prodotti con elementi digitali. A questo scopo devono predisporre una SBOM in un formato comune e leggibile dalle macchine, che copra almeno le dipendenze di primo livello.
L’analogia con lo snack va però maneggiata con attenzione.
Il Regolamento non impone di stampare l’intera SBOM sulla confezione del router o nella pagina dalla quale scarichiamo un’app. La lista appartiene innanzitutto alla documentazione tecnica e al processo con cui il fabbricante sorveglia le vulnerabilità. Può inoltre essere richiesta dalle autorità di vigilanza nei casi previsti.
La vera novità è un’altra: chi immette il prodotto sul mercato europeo deve sapere che cosa vi ha inserito. Deve tenere quell’inventario aggiornato e utilizzarlo quando uno degli ingredienti si rivela pericoloso.
Un ingrediente sicuro oggi può diventare vulnerabile domani
Una libreria open source può essere affidabile al momento della pubblicazione del prodotto e presentare una vulnerabilità sei mesi dopo. Lo stesso può accadere a un modulo di autenticazione, a un componente del sistema operativo o al software che gestisce l’accesso remoto.
Senza una lista degli ingredienti, il fabbricante rischia di non sapere neppure quali prodotti contengano il componente vulnerabile.
La SBOM serve a rispondere rapidamente a domande molto concrete: dove abbiamo usato quel componente? In quali versioni? La vulnerabilità è sfruttabile nel nostro prodotto? Quali utenti dobbiamo avvertire? Come distribuiamo la correzione?
Non è quindi un documento da conservare in un cassetto per mostrare formalmente la conformità. Deve essere collegato alle singole release, alle fonti che segnalano nuove vulnerabilità e al processo con cui si sviluppano, verificano e distribuiscono gli aggiornamenti.
La lista, da sola, non protegge nessuno. Diventa utile quando permette di trovare il problema prima che il problema trovi noi.
Il CRA non promette software senza difetti
Nessuna norma può garantire che un prodotto digitale non avrà mai vulnerabilità. Il CRA impone qualcosa di più realistico: che qualcuno se ne assuma la responsabilità.
Il fabbricante deve valutare i rischi durante la progettazione, lo sviluppo e la manutenzione. Il prodotto deve essere immesso sul mercato senza vulnerabilità sfruttabili già note, quando il requisito risulta applicabile. Le configurazioni devono essere sicure per impostazione predefinita. Le vulnerabilità emerse successivamente devono essere gestite senza ritardo e gli aggiornamenti di sicurezza devono essere distribuiti gratuitamente, salvo le limitate eccezioni previste per prodotti aziendali realizzati su misura.
Dove appropriato, gli aggiornamenti automatici dovranno essere abilitati come impostazione predefinita, lasciando all’utente una modalità semplice per disattivarli.
Il cittadino dovrà inoltre sapere fino a quando il fabbricante si impegna a gestire le vulnerabilità e a fornire gli aggiornamenti. La data di fine del periodo di supporto, almeno con mese e anno, dovrà essere comunicata chiaramente al momento dell’acquisto.
Questa informazione è forse ancora più utile della lista degli ingredienti. Un dispositivo connesso non smette di funzionare quando termina il supporto. Continua ad accendersi, ma nessuno garantisce più che le nuove falle vengano corrette.
Dall’11 settembre comincia la parte più visibile
Il Regolamento è entrato in vigore il 10 dicembre 2024. La maggior parte degli obblighi si applicherà dall’11 dicembre 2027, ma il primo appuntamento è molto più vicino.
Dall’11 settembre 2026 i fabbricanti dovranno notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. Il primo avviso dovrà partire entro ventiquattro ore; la notifica completa, in linea generale, entro settantadue. La Commissione europea ha riepilogato termini e meccanismo nella pagina dedicata agli obblighi di segnalazione del CRA.
L’inventario degli ingredienti diventa decisivo anche qui. Non si può notificare correttamente una vulnerabilità se non si sa quali componenti la contengano e quali prodotti possano esserne colpiti.
Il cittadino digitale che vorrei diventasse mio figlio
Mio figlio crescerà in un mondo nel quale quasi ogni oggetto avrà una parte software. Per lui la distinzione tra vita digitale e vita reale sarà probabilmente meno comprensibile di quanto lo sia già oggi per noi.
Vorrei che considerasse normale chiedere fino a quando un prodotto sarà aggiornato. Vorrei che imparasse a diffidare degli oggetti connessi abbandonati dal produttore, anche quando continuano apparentemente a funzionare. E vorrei che il mercato gli consentisse di scegliere sulla base di informazioni comprensibili.
Il CRA non consegnerà ai consumatori una perfetta etichetta nutrizionale del software. Costringerà però chi produce e vende tecnologia a conoscere gli ingredienti, a controllarli nel tempo e a intervenire quando uno di essi diventa vulnerabile.
Spiegato a mio figlio, il Cyber Resilience Act è questo: se metti del software nella vita delle persone, devi sapere che cosa contiene. E non puoi scomparire appena hai finito di venderlo.