Cyber Resilience Act: un bug giuridico nella linea del fuoco

Dall'11 settembre 2026 il Cyber Resilience Act è pienamente operativo e l'Art.14 impone ai produttori di notificare entro 24 ore ogni vulnerabilità attivamente sfruttata. Un'analisi pubblicata da Ropes & Gray LLP il giorno stesso dell'entrata in vigore solleva però un quesito che il regolatore non ha risolto: il criterio di reporting si applica alla presenza del difetto nel prodotto o alla sua exploitabilità concreta nell'implementazione specifica? Per le aziende con supply chain software complessa, la risposta determina la differenza tra compliance gestibile e allarmismo strutturale.

La frattura tra "contained" e "capable of"

Il nucleo del problema sta nella diversa architettura linguistica del regolamento. L'Art.14(1) si limita a richiedere la notifica di ogni vulnerabilità attivamente sfruttata "contained in the product with digital elements". Non introduce filtri di severità, materialità o impatto pratico. Allo stesso tempo, l'Art.3(44) definisce "incident having an impact on the security of the product" con la formula "capable of negatively affecting" — linguaggio che l'Art.14(5) riprende per gli "severe incident", ma che l'Art.14(1) non incorpora.

Questa asimmetria apre due letture. La prima, letterale: qualsiasi vulnerabilità attivamente sfruttata in qualsiasi componente di terze parti è reportabile, indipendentemente dalla configurazione del produttore che la incorpora. La seconda, contestualizzata: il reporting si attiva solo se esiste un percorso tecnicamente realistico di exploit nell'implementazione specifica. La struttura del CRA non traccia una linea netta tra le due.

"The question is therefore not simply whether a vulnerability is theoretically capable of causing harm, but whether there is a technically realistic pathway by which it could do so in the product as implemented. Unhelpfully, the CRA does not clearly articulate where that line should be drawn." — Ropes & Gray LLP

Quando il componente vulnerabile è inerme

Un produttore può integrare una libreria che contiene una vulnerabilità attivamente sfruttata altrove, ma renderla tecnicamente irraggiungibile: funzionalità disabilitata, interfaccia non esposta all'esterno, sandboxing che blocca il percorso di attacco, assenza di connettività di rete nel perimetro di esecuzione. La vulnerabilità esiste nel codice. La vulnerabilità non è exploitabile nel prodotto finito.

Secondo l'analisi di Ropes & Gray, né la guidance della Commissione europea né quella di ENISA introducono chiaramente un filtro di materialità che esenti l'Art.14(1) in questi scenari. Il provvedimento citato afferma testualmente che non esiste base chiara per trattare la mancanza di impatto pratico sull'implementazione specifica come esenzione generale.

Il rischio dell'approccio restrittivo delle autorità

Le autorità di sorveglianza di mercato potrebbero adottare un'interpretazione ampia. L'analisi legale cita esplicitamente questa possibilità: un'authority potrebbe concludere che l'Art.14(1) impone deliberatamente un obbligo di reporting esteso, trasformando ogni vulnerabilità attivamente sfruttata in componente di terze parti in un evento notificabile anche senza percorso tecnico realistico nel prodotto finale.

Questa lettura ha conseguenze operative immediate. Un produttore con centinaia di dipendenze dovrebbe monitorare gli exploit attivi in ogni componente upstream, valutare la propria implementazione, e comunque notificare — o assumere il rischio di non farlo. L'overhead non è marginale: la fonte primaria sottolinea che decidere di non segnalare una vulnerabilità considerata inoffensiva significa assumere "an interpretive position for which there is, at present, limited authoritative support".

Perché è importante

Il dossier non specifica misure correttive o workaround normativi che chiudano la frattura interpretativa. Non emerge che ENISA o la Commissione abbiano programmato chiarimenti dedicati al criterio di exploitabilità prodotto-specifica. Non è noto se il Single Reporting Platform permetta di indicare nel report che la vulnerabilità non è exploitabile nell'implementazione specifica, né se esistano casi di enforcement che orientino la prassi.

La fonte non documenta inoltre se il criterio "contained in the product" abbia ricevuto interpretazioni giurisprudenziali in altri contesti regolamentari UE che possano fungere da precedente. L'incertezza resta piena: il produttore non ha strumenti certi per calibrare il proprio programma di vulnerability disclosure e incident response.

Le sanzioni rendono il vuoto normativo costoso. Secondo la fonte citata, le violazioni materiali dell'Art.13 e dell'Art.14 espongono a sanzioni fino a circa €15 milioni o il 2,5% del fatturato globale. Micro-imprese e piccole imprese sono esentate da sanzioni per mancato rispetto della deadline 24 ore, ma l'esenzione non risolve il quesito interpretativo sul merito della notificabilità.

Le tre domande senza risposta

Il CRA distingue tra vulnerabilità exploitabile e vulnerabilità presente? Il testo dell'Art.14(1) non qualifica l'obbligo con riferimento a exploitabilità tecnica nell'implementazione specifica. L'Art.3(44) e l'Art.14(5) usano linguaggio "capable of" che Art.14(1) non replica.

Cosa rischia chi non notifica una vulnerabilità considerata inoffensiva? Assume una posizione interpretativa non supportata da guidance autoritativa, con esposizione a sanzioni fino a circa €15 milioni o il 2,5% del fatturato globale secondo la fonte citata.

Esiste un modo per documentare nel report che il bug non è attaccabile? Il dossier non specifica se il Single Reporting Platform consenta campi o flag che descrivano la non-exploitabilità prodotto-specifica.

Il regolatore ha scritto "contained in the product" pensando probabilmente a un'unità tecnica coerente. Il software moderno è assemblaggio, non monolite. Fino a quando la linea non viene tracciata, la compliance resta navigazione senza bussola — e il costo dell'errore è scritto in euro nella colonna delle sanzioni.

Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.

Fonti

• https://www.ropesgray.com/en/insights/viewpoints/2026/09/102o10i/the-vulnerability-was-real-the-exploit-was-impossible-the-eu-cyber-resilience-a
• https://www.consiliumsafety.com/en/eu-cyber-resilience-act-cra/
• https://cryptoticker.io/en/wallet-makers-reporting-duty-eu/
• https://www.secnews.gr/en/732068/eu-cyber-resilience-act-ypochreoseis-anaphoras/
• https://pssle.co/all-ropesgray-insights/s/102g97p?_gl=1*48tb5p*_gcl_au*MTczNTAyODQ4Mi4xNzM2Mjc3MTQ2
• https://www.cookiebot.com/
• https://www.consiliumsafety.com/en/products/

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti