Cyber Resilience Act, chi pagherà il costo della sicurezza obbligatoria? - Agenda Digitale

Per anni la cybersecurity è stata considerata una caratteristica desiderabile. Oggi sta diventando un requisito di mercato. Con l’entrata in vigore del Regolamento (UE) 2024/2847, meglio noto come Cyber Resilience Act (CRA), l’Unione Europea compie una scelta destinata a incidere profondamente sul settore ICT: la sicurezza informatica non è più soltanto una buona pratica o un elemento competitivo, ma una condizione giuridica per l’immissione sul mercato di prodotti con elementi digitali.Il passaggio è meno simbolico di quanto possa apparire. Per la prima volta il software viene ricondotto, sotto molti aspetti, alla logica della sicurezza di prodotto già nota nel settore manifatturiero. Non basta più sviluppare funzionalità. Occorre dimostrare che il prodotto sia stato progettato, realizzato, mantenuto e aggiornato secondo requisiti di cybersecurity verificabili e documentabili. In altre parole, la sicurezza digitale, sia IT e sia OT, diventa parte integrante della marcatura CE.La domanda che emerge è tuttavia più complessa di quella affrontata nel dibattito pubblico: chi sosterrà realmente il costo di questa trasformazione?Indice degli argomenti

Dalla compliance documentale alla sicurezza industrialeLa supply chain nascosta del softwareCyber Resilience Act e processi di sicurezza verificabiliIl costo della sicurezza e il rischio di una nuova asimmetriaPrepararsi al 2026 e al 2027: una checklist minimaUna norma che parla di mercato più che di tecnologiaDalla compliance documentale alla sicurezza industrialeLa narrazione dominante tende a descrivere il CRA come un problema dei grandi produttori tecnologici. In realtà il regolamento adotta una logica molto più estesa. Provider software, produttori hardware, system integrator, importatori, distributori, operatori white label e, indirettamente, gran parte della filiera digitale europea saranno coinvolti da obblighi che incidono sul ciclo di vita del prodotto.L’elemento innovativo non consiste soltanto nell’introduzione di requisiti tecnici minimi. Il vero cambiamento riguarda il passaggio da una cybersecurity “reattiva” a una cybersecurity “industrializzata”. Security by design, vulnerability management, gestione coordinata delle vulnerabilità, monitoraggio post-market, aggiornamenti di sicurezza e documentazione tecnica diventano processi strutturali soggetti a verifica.Chi sviluppa software dovrà essere in grado di dimostrare non solo cosa il prodotto faccia, ma anche come sia stato progettato per resistere agli attacchi informatici.È un cambio di paradigma che richiama quanto già avvenuto con il GDPR nel trattamento dei dati personali. La differenza è che il CRA non disciplina un trattamento, bensì un prodotto. E i prodotti hanno una supply chain.La supply chain nascosta del softwareUno degli aspetti più sottovalutati riguarda la Software Bill of Materials (SBOM). Per anni gran parte dell’industria ha costruito prodotti utilizzando librerie open source, componenti di terze parti, framework pubblici e dipendenze esterne senza una reale tracciabilità del rischio.Il CRA spinge nella direzione opposta. Per gestire vulnerabilità e aggiornamenti è necessario sapere quali componenti siano presenti all’interno del prodotto e quali relazioni esistano lungo la catena di fornitura.La questione non è teorica. Secondo OpenSSF e Linux Foundation Europe, oltre il 90% del software moderno contiene componenti open source. Molte organizzazioni non dispongono però di una mappatura completa delle dipendenze utilizzate nei propri prodotti. Questo significa che una vulnerabilità critica individuata in una libreria di terze parti può propagarsi lungo l’intera filiera senza che il produttore finale ne abbia immediata consapevolezza.L’incidente SolarWinds ha mostrato come la supply chain software possa diventare un vettore di attacco sistemico. Il CRA traduce questa lezione in obblighi giuridici.La sicurezza non viene più valutata esclusivamente sul prodotto finale. Viene osservata lungo tutto il percorso che porta alla sua realizzazione.Cyber Resilience Act e processi di sicurezza verificabiliNelle attività di audit e assessment emerge spesso un elemento ricorrente. Le organizzazioni tendono a considerare la cybersecurity come una questione prevalentemente tecnica. Firewall, antivirus, sistemi EDR e monitoraggio rappresentano la parte visibile del problema. Il CRA interviene invece sulla parte invisibile.Molte software house di piccole e medie dimensioni non possiedono un processo formalizzato di gestione delle vulnerabilità. Non dispongono di procedure di disclosure coordinata. Non hanno definito tempi di patching. Non mantengono evidenze strutturate del secure development lifecycle. In alcuni casi manca persino un inventario aggiornato delle componenti software utilizzate.Da questo punto di vista il regolamento assomiglia più a una norma di governance industriale che a una disciplina puramente cyber. La vera sfida non sarà acquistare nuove tecnologie. Sarà costruire processi ripetibili, verificabili e auditabili.Il costo della sicurezza e il rischio di una nuova asimmetriaI sostenitori del CRA evidenziano correttamente come il costo della non sicurezza sia ormai insostenibile. ENISA continua a segnalare un aumento degli attacchi contro supply chain, infrastrutture digitali e servizi essenziali. Il danno economico derivante da vulnerabilità note ma non corrette supera spesso di gran lunga il costo della prevenzione.Esiste però anche una lettura critica. Alcuni studi accademici pubblicati su SSRN hanno evidenziato il rischio che l’aumento degli obblighi di compliance produca effetti sproporzionati sulle PMI innovative e sulle realtà open source. Se la sicurezza diventa una funzione industriale complessa, il rischio è che i costi di accesso al mercato aumentino significativamente.Si tratta di una tensione regolatoria reale. Da un lato l’Europa cerca di elevare il livello medio di sicurezza. Dall’altro deve evitare che gli oneri documentali e organizzativi riducano la capacità competitiva di startup e piccoli sviluppatori.L’immagine più efficace è quella di un ponte sospeso. Troppa regolazione può rallentare l’innovazione. Troppa libertà può compromettere la fiducia nel mercato. Il CRA prova a costruire un equilibrio tra queste due forze contrapposte.Prepararsi al 2026 e al 2027: una checklist minimaIn vista degli obblighi di reporting delle vulnerabilità che inizieranno ad applicarsi dal settembre 2026 e della piena applicazione del regolamento dal dicembre 2027, le organizzazioni dovrebbero avviare fin da subito almeno cinque iniziative prioritarie:Identificare quali prodotti digitali rientrino nel perimetro del CRA e quali ruoli l’organizzazione ricopra nella filiera;Costruire e mantenere una SBOM aggiornata per i prodotti sviluppati o distribuiti;Formalizzare un processo di vulnerability management con responsabilità, tempi di risposta e criteri di escalation;Integrare pratiche di secure by design e secure development lifecycle nei processi di sviluppo;Predisporre meccanismi di raccolta delle evidenze documentali utili a dimostrare la conformità in sede di audit o vigilanza.Una norma che parla di mercato più che di tecnologiaRidurre il Cyber Resilience Act a una normativa di cybersecurity sarebbe un errore interpretativo. Il regolamento non ridefinisce soltanto il modo in cui si protegge un software. Ridefinisce il modo in cui un prodotto digitale può essere commercializzato nel mercato europeo. La vera innovazione non è l’obbligo di essere sicuri. È l’obbligo di poter dimostrare di esserlo.Ed è proprio qui che si gioca la partita più importante: nel prossimo mercato digitale europeo non vinceranno necessariamente i prodotti con più funzionalità, ma quelli capaci di trasformare la sicurezza da costo invisibile a requisito dimostrabile di fiducia.Perché la cybersecurity sta cessando di essere una caratteristica tecnica. Sta diventando una proprietà giuridica del prodotto.