Open source, etichetta diversa: come un cambiamento aziendale può ridefinire il rischio CRA
Un progetto può mantenere lo stesso codice e rientrare comunque in una diversa categoria normativa quando cambia il suo modello di business. Per questo la due diligence è una questione di sicurezza, non soltanto legale.
Introduzione
Dal punto di vista del codice, un progetto open source può sembrare stabile, mentre gli obblighi che lo riguardano cambiano silenziosamente. È questa la lezione scomoda dell’era del Cyber Resilience Act: la qualificazione giuridica non è sempre legata a una modifica del codice. Se cambia il modello commerciale di un progetto, può cambiare anche l’onere di governance, e i team che tengono d’occhio soltanto il repository potrebbero non cogliere il vero confine del rischio.
In breve
- Secondo quanto riportato, ai sensi del CRA un progetto open source può passare da un ruolo normativo a un altro anche se il codice in sé non cambia.
- Secondo quanto riportato, una modifica del modello di business è sufficiente a richiedere una nuova valutazione della qualificazione del progetto.
- Secondo quanto riportato, in questo contesto la due diligence dovrebbe esaminare la monetizzazione, le responsabilità relative al progetto, i requisiti di sicurezza e le scadenze del CRA.
- Non confermato in modo indipendente: il punto centrale non è soltanto la funzionalità del software, ma il ruolo svolto dal progetto sul mercato.
Approfondimento
Il punto centrale è circoscritto, ma importante. Nell’open source, lo stesso repository può essere considerato diversamente quando cambia il contesto aziendale. Ciò significa che un progetto può essere trattato come custode in un contesto e come fabbricante in un altro, senza nuove funzionalità, patch o riscritture architetturali. Il fattore giuridico determinante è organizzativo, non tecnico.
Dal punto di vista della cybersicurezza, questo è importante perché conformità e sicurezza sono ormai interconnesse. Se un progetto assume una posizione più esigente ai sensi del CRA, le domande da porsi nella due diligence non si limitano più alla compatibilità delle licenze o alla reputazione dei responsabili della manutenzione. I team dovrebbero anche chiedersi come viene monetizzato il progetto, chi ne è responsabile, quali requisiti di sicurezza si applicano e quali scadenze stanno per entrare in vigore.
Si tratta di un rischio di governance, non di un’affermazione relativa a una violazione o a uno sfruttamento specifici. Le informazioni pubbliche non dimostrano che qui si siano verificati un attacco, una compromissione o incidenti conseguenti. Le prove disponibili supportano un’analisi del rischio: le decisioni aziendali possono modificare gli obblighi di sicurezza associati al software, anche quando il codice sorgente rimane invariato.
Per chi sviluppa e adotta software, la lezione pratica è semplice. In termini di conformità, l’open source non è automaticamente statico. Se cambiano il modello di business, la struttura di supporto o il ruolo del progetto sul mercato, anche la revisione giuridica e di sicurezza dovrebbe cambiare di conseguenza. Tale revisione deve avvenire prima che le supposizioni si consolidino in decisioni di approvvigionamento o piani di rilascio.
Conclusione
La lezione più ampia è che il rischio legato al software dipende in parte dal suo status, non soltanto dalla sua sostanza. Nel contesto del CRA, il punto cieco più pericoloso potrebbe essere presumere che un codice invariato implichi obblighi invariati. Il parere di Netcrook è netto: se cambia il modello di business, deve cambiare anche la lista di controllo della sicurezza.
WIKICROOK
- Cyber Resilience Act: quadro normativo dell’UE che introduce requisiti di cybersicurezza per i prodotti con elementi digitali.
- Due diligence: valutazione strutturata del rischio, delle responsabilità e della conformità prima di fare affidamento su un progetto o un prodotto.
- Open source: software distribuito con codice sorgente disponibile con una licenza che ne consente l’uso e la modifica.
- Fabbricante: soggetto che può essere tenuto a rispettare obblighi relativi ai prodotti quando il software viene immesso sul mercato in un ruolo regolamentato.
- Cambiamento del modello di business: modifica del modo in cui un progetto è finanziato, supportato o offerto, che può alterarne il profilo di conformità.
