Il Cyber Resilience Act e la proprietà intellettuale si incontrano in un punto delicato: gli obblighi di trasparenza e sicurezza informatica possono incidere su codice sorgente, segreti commerciali, know-how, licenze open source e brevetti. Per le imprese tecnologiche, la compliance al CRA non è quindi solo una questione tecnica.
Indice degli argomenti
CRA: fino a dove si può essere trasparenti senza smettere di essere protetti?
Il Cyber Resilience Act (Regolamento (UE) 2024/2847, di seguito “CRA”), entrato in vigore il 10 dicembre 2024 e destinato alla piena applicabilità dal prossimo 11 dicembre 2027, è comunemente presentato come uno strumento di sicurezza informatica, al pari delle ulteriori e diverse normative in materia di cybersecurity che sono recentemente entrate in vigore nel panorama normativo europeo e nazionale (Direttiva UE 2022/2555, c.d. NIS2, trasposta in Italia con il D.Lgs. 138/2024, e Regolamento UE 2022/2554, Digital Operational Resilience Act anche conosciuto come DORA).
La presentazione è corretta, ma parziale. Chi si occupa di proteggere il patrimonio immateriale delle imprese tecnologiche (diritto d’autore sul codice sorgente di programmi software, segreti commerciali, know-how) si trova di fronte ad un Regolamento che non cita quasi mai la proprietà intellettuale, ma la tocca continuamente.
Ogni volta che il CRA impone stringenti ed estesi obblighi di trasparenza, ci si pone una domanda che non è stata esplicitamente affrontata dal legislatore: fino a dove si può essere trasparenti senza smettere di essere protetti?
La SBOM tra trasparenza, segreto commerciale e governance degli asset immateriali
La Software Bill of Materials (“SBOM”) è l’inventario strutturato di tutti i componenti software che costituiscono un prodotto: librerie, dipendenze, framework, moduli di terze parti. L’Allegato I, Parte II, punto 1 del CRA impone ai fabbricanti di redigerla e mantenerla aggiornata in formato machine-readable con copertura almeno delle dipendenze di primo livello.
La SBOM rivela l’architettura interna del software: quali componenti sono stati scelti, in quale versione, da quale fornitore, con quali relazioni strutturali tra di loro. Queste informazioni sono tipicamente suscettibili di qualificazione come segreto commerciale ai sensi degli artt. 98-99 del D.Lgs. 30/2005 (Codice della Proprietà Industriale): informazioni segrete, dotate di valore commerciale e tutelate con misure adeguate. Proprio quest’ultimo profilo merita attenzione sul piano della gestione interna. La qualificazione della SBOM come segreto commerciale richiede, infatti, che il titolare adotti misure concrete per preservarne la riservatezza. Un accesso interno non controllato, una condivisione tra reparti senza restrizioni o una diffusione informale all’interno dell’organizzazione possono far venire meno questo presupposto. Pertanto, classificare la SBOM con lo stesso rigore riservato ad altri documenti contenenti segreti commerciali, con controlli di accesso granulari e una policy interna documentata, è la condizione giuridica preliminare per qualsiasi tutela effettiva.
Come specificato dal considerando 77 del CRA, la pubblicazione della SBOM non è imposta ai fabbricanti, ma si prevede che essa sia resa disponibile alle autorità di vigilanza su richiesta motivata (cfr. l’Allegato VII, n. 8). L’art. 63 del CRA stabilisce l’obbligo di riservatezza per autorità di vigilanza, Commissione Europea e organismi notificati, con tutela esplicita dei segreti commerciali e del codice sorgente del software. Su questo fronte, il CRA offre garanzie standard e relativamente solide.
Il problema è altrove. Il citato art. 63 limita il proprio ambito soggettivo alle autorità istituzionali: non copre i rapporti tra soggetti privati. Su questo secondo aspetto, l’Allegato II, punto 9 del CRA prevede che il fabbricante possa mettere a disposizione dell’utilizzatore la SBOM; si tratta di una facoltà, non di un obbligo. Ma nelle filiere B2B la dinamica reale è più complessa: un integratore di sistema, un distributore o un grande cliente enterprise che imponga contrattualmente la condivisione della SBOM come precondizione all’acquisto trasformano nella pratica la facoltà in obbligo di fatto. E quella condivisione avviene in un contesto privo di qualsiasi copertura normativa di riservatezza.
Il CRA non risolve questo problema, ma lo lascia interamente al fabbricante, che deve costruirsi da solo un’idonea protezione contrattuale, attraverso accordi di riservatezza (NDA) e restrizioni contrattuali sull’utilizzo delle informazioni ricevute dalle controparti.
La SBOM, tuttavia, non rappresenta solo un potenziale fattore di esposizione del know-how aziendale: questo stesso strumento può essere al contempo un importante presidio in materia di proprietà intellettuale. La mappatura sistematica dei componenti software utilizzati consente di individuare con maggiore precisione i software di terzi incorporati nel prodotto, verificare il rispetto delle condizioni previste dalle relative licenze e prevenire violazioni derivanti dall’utilizzo di componenti open source o proprietari. In questa prospettiva, la SBOM diventa uno strumento di governo degli asset immateriali dell’impresa.
Ipotizziamo il caso di un fornitore di piattaforme software per enti regolamentati. In tale contesto, la SBOM non si limita a rappresentare un inventario tecnico dei componenti utilizzati, ma diventa uno strumento essenziale per rispondere alle richieste di trasparenza derivanti sia dal CRA sia dai clienti soggetti a obblighi regolamentari in materia di resilienza operativa e gestione del rischio ICT (es. soggetti DORA). Al tempo stesso, detta documentazione può contenere informazioni idonee a rivelare aspetti dell’architettura del prodotto e delle scelte tecnologiche che costituiscono parte del patrimonio di know-how dell’impresa.
Open source e CRA: da scelta tecnica a rischio legale
I componenti software open source rientrano nell’ambito di applicazione del CRA solo se monetizzati dal loro sviluppatore originario. Chi invece integra componenti open source nei propri prodotti con elementi digitali è in ogni caso soggetto al CRA come fabbricante del prodotto finale, indipendentemente dalla natura del componente integrato, con i conseguenti obblighi: aggiornamenti di sicurezza per almeno cinque anni, gestione delle vulnerabilità dei componenti di terze parti integrati nel prodotto, notifica degli incidenti all’ENISA (l’Agenzia dell’Unione Europea per la Cybersicurezza) e al CSIRT (Computer Security Incident Response Team) entro 24 ore. Tali obblighi entrano in evidente collisione con le licenze open source, che tipicamente escludono qualsiasi garanzia con clausole del tipo “provided as is, without warranty of any kind”. Pertanto, il produttore deve assumersi responsabilità che non può trasferire su soggetti terzi e che rimangono integralmente a suo carico.
A ciò si aggiunge una criticità strutturale tipica dell’ecosistema open source. In molti casi, il componente integrato nel prodotto non è sviluppato e mantenuto da un singolo fornitore identificabile, bensì da una comunità di sviluppatori distribuita, spesso priva di una struttura organizzativa o di un soggetto giuridico che assuma obblighi di manutenzione e supporto. Ne deriva che il fabbricante, pur essendo vincolato agli obblighi del CRA, potrebbe non disporre di un interlocutore contrattuale nei cui confronti pretendere l’adempimento di tali obblighi (ad esempio, correzione tempestiva delle vulnerabilità o il rilascio di informazioni tecniche necessarie alla gestione del rischio) e con cui disciplinare aspetti contrattuali di rilievo, come la riservatezza delle informazioni, la titolarità delle modifiche apportate al codice e la gestione delle vulnerabilità. Il risultato è un’ulteriore concentrazione della responsabilità in capo al fabbricante del prodotto finale, che avrà l’onere di monitorare in autonomia l’evoluzione dei componenti open source utilizzati e predisporre misure di mitigazione, anche quando la comunità di sviluppo non interviene come richiesto dagli obblighi regolatori.
C’è un ulteriore effetto collaterale del CRA, che rischia di passare inosservato, ma che riguarda da vicino qualsiasi azienda che costruisce i propri prodotti digitali integrando componenti open source. Il CRA, difatti, impone di segnalare allo sviluppatore del componente open source le vulnerabilità individuate e, qualora il fabbricante abbia sviluppato una modifica del software o dell’hardware per affrontarle, di condividere il codice o la documentazione pertinenti con lo sviluppatore stesso. In quelle righe di codice potrebbero essere incorporate scelte architetturali, algoritmi, ottimizzazioni o integrazioni che rappresentano il valore distintivo dell’azienda. Il risultato è che adempiere correttamente agli obblighi del CRA, senza adeguate tutele contrattuali, può tradursi in una cessione involontaria di proprietà intellettuale (know-how e porzioni del codice sorgente tutelato dal diritto d’autore). Da un punto di vista tecnico, il codice sorgente non è mai modulare in modo perfettamente separabile, per cui è ragionevole ipotizzare che il codice modificato contenga o riveli il contesto in cui opera (ad esempio, le interfacce con cui il componente open source si connette al resto del sistema proprietario).
Per le PMI, che non sempre dispongono di presidi strutturati per la tutela della proprietà intellettuale, il primo passo è affrontare questo rischio prima che arrivi una vulnerabilità da gestire: definire contrattualmente i limiti della condivisione e mappare preventivamente i componenti del proprio software esposti a questo meccanismo. Questo significa, nella pratica, fare una scelta prima ancora di ricevere qualsiasi segnalazione di vulnerabilità.
Quando segnalare una vulnerabilità può esporre il know-how aziendale
Come detto, l’art. 14 del CRA impone la notifica all’ENISA e al CSIRT designato, entro 24 ore dalla scoperta (che spesso non bastano nemmeno a comprendere la portata del problema), di ogni vulnerabilità attivamente sfruttata. Questa notifica, visti i tempi ristretti, potrebbe avvenire prima che sia disponibile una patch e quindi in un momento in cui la vulnerabilità è ancora aperta e il fabbricante sta lavorando alla correzione. La notifica deve contenere informazioni tecniche sulla natura della falla, incluse informazioni che possono rivelare aspetti dell’architettura interna del prodotto, che potrebbe qualificarsi come segreto commerciale. Si tratta di un’esposizione limitata, essendo l’ENISA vincolata alla riservatezza, ma che impone di strutturare con cura il contenuto e il livello di dettaglio di ogni notifica, evitando di condividere più di quanto strettamente necessario ad assolvere l’obbligo regolatorio. Non si tratta di un rischio lontano, in quanto dall’11 settembre 2026 gli obblighi di notifica ex art. 14 del CRA saranno già operativi: chi non ha già strutturato i propri processi e procedure interni a tale fine è già in ritardo.
Il rischio si amplifica, ulteriormente, quando entrano in gioco soggetti privati. Il CRA, infatti, incoraggia esplicitamente i programmi di c.d. “bug bounty” per gestire in modo proattivo le vulnerabilità: si tratta di ricercatori privati, che, dietro compenso, individuano falle nel prodotto e le segnalano al fabbricante prima di renderle pubbliche. A differenza di ENISA e CSIRT, questi soggetti non sono vincolati ad alcun obbligo di riservatezza: è più elevato il rischio che informazioni tecniche sensibili che descrivono la vulnerabilità ed il contesto architetturale in cui si inserisce fuoriescano dal perimetro controllato del fabbricante. Si tratta di un meccanismo potenzialmente virtuoso, ma che funziona solo se governato da accordi contrattuali precisi. L’NDA è il primo strumento per vincolare il ricercatore a non divulgare la vulnerabilità prima che la patch sia disponibile e dovrebbe definire con chiarezza quali informazioni sono coperte, per quanto tempo e con quali conseguenze in caso di violazione.
Gli standard armonizzati come possibile veicolo di dipendenza da tecnologie brevettate
L’art. 27 del CRA introduce una presunzione di conformità ai requisiti essenziali di cybersicurezza per i prodotti realizzati in conformità a standard armonizzati pubblicati nella Gazzetta Ufficiale dell’Unione Europea. Si tratta di un meccanismo facoltativo, ma di fatto centrale nella strategia di compliance, in quanto consente di ridurre l’onere probatorio a carico del fabbricante, nella misura in cui gli standard coprono i requisiti applicabili. Qualora tali standard incorporino tecnologie oggetto di tutela brevettuale, il percorso di conformità potrebbe richiedere l’ottenimento di licenze dai relativi titolari. Ne deriva che una scelta apparentemente tecnica, come l’adozione dello standard armonizzato, può produrre effetti rilevanti anche sul piano della proprietà industriale, incidendo sui costi di implementazione e sulle scelte tecnologiche del fabbricante.
In tale contesto può emergere il rischio di patent hold-up, ossia la possibilità che il titolare di un brevetto essenziale sfrutti il potere negoziale derivante dall’adozione dello standard per ottenere condizioni di licenza più gravose di quelle che sarebbero state negoziabili prima dell’adozione dello standard.
La prassi degli organismi di normazione richiede generalmente ai titolari di brevetti essenziali di impegnarsi a concedere licenze a condizioni FRAND (Fair, Reasonable and Non-Discriminatory). Nella pratica, tuttavia, la definizione di cosa sia “equo, ragionevole e non discriminatorio” è essa stessa oggetto di controversia. Gli standard armonizzati rilevanti per il CRA non sono ancora stati adottati e l’aderenza agli stessi è facoltativa, ma rappresenta la via privilegiata per beneficiare della presunzione di conformità ai requisiti del CRA. Per il momento si tratta di un rischio meramente potenziale; ciononostante, le imprese che stanno pianificando il proprio percorso di conformità dovrebbero monitorarne l’evoluzione e valutare tempestivamente l’eventuale presenza di tecnologie coperte da brevetto la cui implementazione richieda l’ottenimento di licenze.
Il CRA e l’intelligenza artificiale: una sovrapposizione da gestire
Si segnala una sovrapposizione normativa rilevante per quanto riguarda i sistemi di intelligenza artificiale che rientrano nella definizione di “prodotti con elementi digitali”. L’art. 12 del CRA, infatti, a questo proposito stabilisce una presunzione di conformità incrociata: i prodotti con elementi digitali classificati come sistemi di IA ad alto rischio ai sensi dell’art. 6 dell’AI Act, qualora soddisfino i requisiti di cybersicurezza del CRA, si considerano conformi ai corrispondenti requisiti di cybersicurezza previsti dall’art. 15 dell’AI Act, evitando la duplicazione degli obblighi tecnici di sicurezza. Il perimetro di questa presunzione è però delimitato dal testo della norma: copre i soli requisiti di cybersicurezza dell’art. 15 dell’AI Act (resilienza a manomissioni non autorizzate dell’uso, sia a livello di output, sia a livello di prestazioni del sistema; misure tecniche proporzionate al rischio e al contesto) ed esclude espressamente i requisiti di accuratezza e robustezza previsti dal medesimo articolo. Ne consegue che il fabbricante di un sistema AI deve presidiare due binari distinti: la conformità CRA, che è prevalentemente una questione tecnica e di processo sotto la gestione del team IT, e la conformità AI Act, che copre profili diversi, di natura prevalentemente legale e di compliance (accuratezza, robustezza, trasparenza algoritmica, supervisione umana, gestione dei dati di addestramento). È il rischio che le PMI tendono a sottovalutare di più: non per mancanza di competenze, ma perché legale e IT raramente si siedono allo stesso tavolo con la frequenza che questo scenario richiederebbe.
Roadmap applicativa: dalla norma alla pratica
Il quadro che emerge non consente soluzioni universali, ma è possibile delineare un percorso operativo per fasi, che consenta ai team legali e IT di affrontare la compliance in modo coordinato tenendo conto delle scadenze del CRA:
- mappatura e assessment: verificare quali prodotti rientrano nel perimetro del CRA, censire i componenti open source integrati e identificare quelli privi di un responsabile chiaramente individuabile;
- contratti e proprietà intellettuale: classificare la SBOM come segreto commerciale, definire regole di accesso e condivisione e predisporre NDA standard per la sua divulgazione a soggetti terzi;
- notifica vulnerabilità e bug bounty: strutturare un protocollo interno per gestire le notifiche entro i tempi previsti, condividendo solo le informazioni strettamente necessarie, e predisporre NDA specifici per i ricercatori coinvolti nei programmi di bug bounty.
- standard armonizzati e brevetti: monitorare l’adozione degli standard armonizzati e verificare se incorporano tecnologie brevettate che richiedano la negoziazione di licenze FRAND;
- presidio organizzativo e test: istituire un gruppo di lavoro interfunzionale tra legale, IT e compliance, verificando l’integrazione tra obblighi CRA e obblighi AI Act per i sistemi di IA ad alto rischio;
- conformità piena: raggiungere la piena conformità ai requisiti CRA per i nuovi prodotti e attivare il monitoraggio continuo post-conformità.
In conclusione, il CRA non è una norma di proprietà intellettuale. Ma i suoi obblighi (SBOM, trasparenza documentale, aggiornamenti pluriennali, gestione delle vulnerabilità, conformità agli standard) attraversano tutti i principali istituti di proprietà intellettuale che presidiano il patrimonio immateriale delle imprese tecnologiche. L’errore da evitare è trattare la compliance CRA come una questione puramente tecnica, delegandola integralmente ai team IT senza il coinvolgimento delle funzioni legali specializzate in proprietà intellettuale.
Dall’11 settembre 2026 gli obblighi di notifica delle vulnerabilità ex art. 14 del CRA saranno già operativi. La scadenza dell’11 dicembre 2027 è il termine per la piena conformità tecnica, ma è anche la scadenza entro cui strutturare la protezione contrattuale della SBOM nei rapporti di filiera, completare l’audit delle licenze open source, avviare la verifica dei brevetti essenziali e valutare eventuali interazioni con le componenti AI del prodotto. Non si tratta di adempimenti aggiuntivi rispetto alla compliance CRA: si tratta della stessa compliance, letta con gli occhi del professionista IP.
Partecipa alla community