Il Cyber Resilience Act scarica la responsabilità della SBOM e della gestione delle vulnerabilità sul fabbricante che immette il prodotto sul mercato, non sul progetto open source in sé. Chi assiste aziende che integrano componenti open source in prodotti digitali deve verificare subito contratti di fornitura, processi interni di vulnerability handling e la capacità di notifica a ENISA entro l’11 settembre 2026. I gestori di repository open source non commerciali rimangono fuori dall’obbligo diretto, ma possono subire pressioni contrattuali dai fabbricanti a valle.
Punti chiave
- Punto 1 — La SBOM è obbligo del fabbricante che immette il prodotto sul mercato, non del contributore open source.
- Punto 2 — Vulnerability handling e notifiche ENISA devono essere operativi dall’11 settembre 2026.
- Punto 3 — I gestori open source non commerciali non sono fabbricanti, ma rischiano pressioni contrattuali dai clienti.
Chi segue clienti che sviluppano o distribuiscono prodotti con elementi digitali — software embedded, app, dispositivi IoT — deve mettere in agenda una revisione dei contratti di sviluppo e fornitura entro il 2025. Il Cyber Resilience Act (Regolamento UE 2024/2847) fissa all’11 settembre 2026 la data operativa per vulnerability handling e notifiche obbligatorie ad ENISA: da quella data i processi devono già girare, non essere in fase di avvio.
Il dibattito su chi risponde per i componenti open source integrati nei prodotti commerciali ha ora una risposta normativa chiara. Secondo l’analisi pubblicata da Agenda Digitale, il CRA distingue tre figure — contributori individuali, gestori di progetti open source e fabbricanti — e concentra gli obblighi più gravosi sull’ultimo anello della catena.
Il contesto normativo
Il Regolamento UE 2024/2847 (Cyber Resilience Act) è entrato in vigore il 10 dicembre 2024. L’art. 3, n. 14 definisce il «fabbricante» come qualsiasi persona fisica o giuridica che sviluppa o fabbrica prodotti con elementi digitali e li immette sul mercato sotto il proprio nome o marchio. L’art. 13 elenca gli obblighi del fabbricante, tra cui la redazione della Software Bill of Materials (SBOM), la gestione attiva delle vulnerabilità e la notifica agli organismi nazionali di coordinamento — in Italia, ACN — e ad ENISA entro 24 ore dalla scoperta di una vulnerabilità attivamente sfruttata.
L’art. 17 introduce invece una categoria separata per i «gestori di software open source», cioè le persone giuridiche che gestiscono repository in modo sistematico: su di loro gravano obblighi attenuati rispetto al fabbricante, ma non azzerati. Il considerando 18 del Regolamento chiarisce che il mero atto di rendere disponibile codice senza attività commerciale non costituisce «immissione sul mercato».
Cosa cambia per lo studio
- Revisione dei contratti di sviluppo software. I contratti con sviluppatori e system integrator devono prevedere clausole che obblighino il fornitore a consegnare una SBOM aggiornata e a notificare tempestivamente ogni vulnerabilità scoperta nei componenti open source integrati. Senza questa clausola, il fabbricante-cliente rischia di non poter rispettare i tempi di notifica ENISA (24 ore per le vulnerabilità attivamente sfruttate).
- Mappatura della supply chain digitale. Prima di settembre 2026 il cliente deve sapere esattamente quali componenti open source usa, in quale versione e con quale storico di vulnerabilità note. Lo studio può assistere nella predisposizione di una policy interna di software inventory che soddisfi i requisiti dell’art. 13 CRA.
- Procedure di incident e vulnerability handling. Il CRA impone processi documentati, non solo buone intenzioni. Chi assiste PMI manifatturiere con prodotti IoT deve verificare se esiste un processo formale di patch management: in assenza, il cliente è esposto a sanzioni amministrative che il Regolamento rimette agli Stati membri.
- Attenzione ai gestori open source come parti contrattuali. Un’azienda che gestisce un fork interno di un progetto open source a scopo commerciale può essere qualificata come «gestore» ai sensi dell’art. 17 o persino come «fabbricante» se distribuisce il prodotto. La distinzione è sottile e va valutata caso per caso prima di strutturare i rapporti societari.
- Coordinamento con il D.Lgs. 138/2024 (recepimento NIS2). Gli obblighi di notifica del CRA si sovrappongono parzialmente a quelli NIS2 per i soggetti essenziali e importanti. Lo studio deve verificare che il cliente non sia soggetto a un doppio binario di notifica con scadenze diverse.
Attenzione a
Non confondere il gestore open source con il semplice contributore. Un avvocato che assiste una fondazione o un’associazione che gestisce un repository usato da prodotti commerciali deve capire se l’ente rientra nell’art. 17 CRA. Se sì, scattano obblighi di trasparenza sulle vulnerabilità e di cooperazione con le autorità, anche senza vendita diretta di prodotti. Trattare l’ente come soggetto completamente esente è un errore che espone a responsabilità amministrativa.
La data dell’11 settembre 2026 non è un termine di adeguamento, ma di operatività. Vulnerability handling e notifiche ENISA devono funzionare da quel giorno, non essere avviati. Chi inizia a costruire i processi a luglio 2026 arriverà tardi. Gli studi che assistono produttori di software o hardware connesso devono pianificare la due diligence interna almeno 12 mesi prima.
Domande frequenti
Chi è responsabile della SBOM se il prodotto usa componenti open source di terzi?
La SBOM è obbligo del fabbricante che immette il prodotto sul mercato, ai sensi dell’art. 13 del Regolamento UE 2024/2847. Il fatto che i componenti provengano da progetti open source di terzi non trasferisce la responsabilità: il fabbricante deve mappare tutti i componenti, aggiornare la SBOM a ogni nuova versione e metterla a disposizione delle autorità su richiesta.
Un’associazione che gestisce un repository open source usato da aziende commerciali è soggetta al CRA?
Potenzialmente sì, se rientra nella definizione di «gestore di software open source» dell’art. 17 CRA: soggetto giuridico che gestisce e sviluppa sistematicamente un prodotto open source. In quel caso scattano obblighi attenuati rispetto al fabbricante — tra cui trasparenza sulle vulnerabilità e cooperazione con le autorità — anche senza vendita diretta.
Entro quando un’azienda deve notificare ENISA per una vulnerabilità attivamente sfruttata nei propri prodotti?
Il Cyber Resilience Act fissa un termine di 24 ore dalla scoperta della vulnerabilità attivamente sfruttata per la notifica iniziale ad ENISA e all’autorità nazionale competente (in Italia, ACN). Questo obbligo diventa operativo dall’11 settembre 2026, ma i processi interni devono essere strutturati prima di quella data.
Fonte di riferimento: AgendaDigitale