Il software contemporaneo raramente nasce da una pagina bianca. Framework, librerie, container, package manager, componenti crittografici e moduli open source compongono una catena di fornitura che attraversa organizzazioni e giurisdizioni diverse. Le crisi originate da dipendenze molto diffuse hanno mostrato quanto una singola vulnerabilità possa propagarsi in migliaia di prodotti senza che gli utilizzatori, e talvolta gli stessi produttori, sappiano con precisione dove quella componente sia presente.
Il Regolamento (UE) 2024/2847, il Cyber Resilience Act (CRA), affronta questo problema come disciplina di prodotto. La sicurezza deve accompagnare progettazione, sviluppo, immissione sul mercato e periodo di supporto. L’open source entra in questo disegno con una soluzione graduata: il legislatore evita di assimilare il contributore volontario a un produttore commerciale, ma non lascia senza presidi i progetti che costituiscono infrastruttura di fatto per il mercato europeo.
Le linee guida della Commissione del 27 luglio 2026, adottate come comunicazione C(2026) 5252, dedicano ampio spazio al software libero e open source. Il documento è dichiaratamente non vincolante, ma offre una chiave pratica per leggere i criteri del Regolamento. Il punto di partenza resta l’attribuzione di un ruolo preciso rispetto a ciascun prodotto e a ciascuna modalità di distribuzione.
Scadenza chiave. Gli obblighi di segnalazione del CRA si applicano dall’11 settembre 2026; il resto della disciplina diventa pienamente applicabile dall’11 dicembre 2027. La procedura di reporting deve quindi essere operativa prima della conformità complessiva del prodotto.
Indice degli argomenti
Tre ruoli da tenere distinti
Il contributore e il progetto fuori dall’attività commerciale
Il CRA definisce software libero e open source il software il cui codice sorgente è condiviso apertamente e la cui licenza riconosce i diritti di accesso, uso, modifica e redistribuzione. Per gli operatori economici, il Regolamento ragiona sulla fase di fornitura: il software open source messo a disposizione fuori da un’attività commerciale resta fuori dal perimetro degli obblighi del fabbricante. Anche chi contribuisce codice a un progetto che non ricade sotto la propria responsabilità resta escluso.
Il finanziamento del progetto, una donazione, il contributo di imprese o la regolarità delle release non bastano, da soli, a rendere commerciale la fornitura. La qualificazione cambia quando il software è monetizzato direttamente, consente di monetizzare altri servizi, viene legato a un’assistenza a pagamento che supera il mero recupero dei costi o richiede, come condizione d’uso, trattamenti di dati personali estranei a sicurezza, compatibilità o interoperabilità.
Il gestore di software open source
Il gestore di software open source, traduzione ufficiale di open-source software steward, è una persona giuridica diversa dal fabbricante che sostiene sistematicamente e in modo continuativo lo sviluppo di specifici prodotti open source destinati ad attività commerciali e ne assicura la sostenibilità. Fondazioni ed enti non profit possono rientrare in questa figura quando governano il progetto, ospitano e amministrano l’infrastruttura di sviluppo, orientano la roadmap o svolgono un ruolo essenziale per la continuità del prodotto.
La destinazione commerciale riguarda l’ecosistema in cui il componente è destinato a essere utilizzato. Un progetto può essere gratuito e, al tempo stesso, sostenuto stabilmente per l’integrazione in servizi e prodotti monetizzati. Il semplice hosting di un repository o di un pacchetto, privo di quel ruolo di governo e sostegno, non trasforma automaticamente la piattaforma nel gestore del software ospitato.
Il fabbricante del prodotto commercializzato
Chi immette sul mercato un prodotto con elementi digitali sotto il proprio nome o marchio, anche quando il prodotto è distribuito con licenza open source, assume il ruolo di fabbricante. Lo stesso accade, per la parte rilevante o per l’intero prodotto, a chi effettua una modifica sostanziale e lo rende disponibile sul mercato. L’integrazione di componenti open source in un prodotto commerciale non sposta verso la community la responsabilità sul prodotto finale.
La qualificazione deve essere svolta per prodotto e per modello distributivo. La stessa organizzazione può operare come gestore rispetto a un progetto comunitario e come fabbricante rispetto a una propria distribuzione monetizzata. Per questo un’etichetta societaria generale, come software house, fondazione o piattaforma, non sostituisce l’analisi della singola relazione con il prodotto.
Gli obblighi del gestore: una governance verificabile
L’articolo 24 del CRA costruisce per i gestori un regime leggero e su misura. Il primo obbligo consiste nel mettere in atto e documentare in modo verificabile una politica di cybersicurezza che favorisca lo sviluppo sicuro del prodotto e un trattamento efficace delle vulnerabilità da parte degli sviluppatori. La politica deve promuovere la segnalazione volontaria, disciplinare documentazione, gestione e correzione delle vulnerabilità e favorire la condivisione delle informazioni nella comunità open source.
Il requisito della verificabilità impedisce di ridurre la politica a una dichiarazione di intenti. Servono ruoli, canali di contatto, criteri di triage, regole per gli embargo, registri delle decisioni, modalità di coordinamento con i maintainer, processo di rilascio delle patch e prove della loro applicazione. Il modello può essere proporzionato alla struttura del progetto, ma deve consentire a un’autorità di ricostruire come una segnalazione è stata ricevuta, valutata e trattata.
Il gestore deve inoltre cooperare con le autorità di vigilanza del mercato e fornire, su richiesta motivata, la documentazione della propria politica. Se l’autorità rileva una violazione può imporre le azioni correttive appropriate. Il CRA esclude per i gestori le sanzioni amministrative pecuniarie, ma il regime resta cogente: ordini di adeguamento, pressione contrattuale e impatto reputazionale conservano un peso concreto.
Il gestore non appone la marcatura CE sui prodotti di cui sostiene lo sviluppo, perché quella marcatura appartiene al percorso di conformità del fabbricante. La distinzione esprime bene la logica del sistema: allo steward viene chiesto di rendere affidabile il governo della vulnerabilità; al soggetto che porta il prodotto sul mercato viene chiesto di assumerne la conformità.
La SBOM resta in capo al fabbricante
Il CRA definisce la software bill of materials (SBOM) come il registro formale che descrive i componenti inclusi negli elementi software del prodotto e le relative relazioni di catena di fornitura. L’Allegato I, parte II, impone ai fabbricanti di identificare e documentare componenti e vulnerabilità, anche predisponendo una SBOM in un formato comunemente utilizzato e leggibile automaticamente, che copra almeno le dipendenze di primo livello.
Quel riferimento alle dipendenze di primo livello stabilisce una soglia minima. Un prodotto esposto a rischi rilevanti può richiedere la visibilità sulle dipendenze transitive, sugli artefatti incorporati durante la build, sui componenti presenti nelle immagini container e sui moduli caricati a runtime. La profondità adeguata dipende dal rischio e dalla capacità della distinta base di sostenere il vulnerability handling. Una SBOM che si ferma prima del componente vulnerabile può essere formalmente elegante e operativamente inutile.
L’articolo 24 non introduce, per il gestore open source, un autonomo obbligo generale di produrre una SBOM. La sua politica può certamente utilizzare inventari, manifesti e distinte dei componenti, e il mercato tenderà a richiederli per alimentare la due diligence a valle. La completezza della SBOM del prodotto finale, tuttavia, resta responsabilità del fabbricante. Un documento upstream può essere una fonte; non sostituisce la verifica di ciò che è stato realmente compilato, impacchettato e distribuito.
Il fabbricante deve esercitare due diligence anche sui componenti open source non immessi sul mercato nell’ambito di un’attività commerciale. Il considerando 34 indica, in funzione del rischio, controlli sulla conformità del componente, sulla storia degli aggiornamenti, sulle banche dati delle vulnerabilità e test ulteriori. La licenza open source e le eventuali clausole di esclusione di garanzia non attenuano questa responsabilità regolamentare a valle.
Quando una SBOM diventa davvero utilizzabile
Una distinta base efficace nasce nel processo di build, viene associata all’esatto artefatto rilasciato e cambia con esso. Dovrebbe indicare almeno identità e versione dei componenti, fornitore o autore quando disponibile, identificatori univoci, hash, relazioni di dipendenza, data di generazione e strumento che l’ha prodotta. La firma o attestazione del documento e il collegamento con il repository degli artefatti aiutano a dimostrare integrità e provenienza.
SPDX e CycloneDX offrono formati interoperabili e leggibili automaticamente. Il CRA non sceglie nel proprio testo una sintassi unica e attribuisce alla Commissione il potere di specificare con atti di esecuzione formato ed elementi della SBOM, tenendo conto di standard e buone pratiche internazionali. La scelta tecnica deve quindi evitare formati proprietari difficili da migrare e prevedere versionamento, validazione dello schema ed esportazione stabile.
La SBOM fotografa la presenza di un componente; non dimostra automaticamente che il prodotto sia vulnerabile. Il confronto con advisory e database può generare corrispondenze per versione che ignorano configurazione, codice effettivamente raggiungibile, funzioni disabilitate o patch backportate. Un’informazione di tipo VEX consente di esprimere, per una specifica vulnerabilità e uno specifico prodotto, stati come interessato, non interessato, corretto o ancora in valutazione, accompagnandoli con una giustificazione verificabile.
La qualità si misura anche nel tempo. Occorre conservare la distinta per ogni release, rigenerarla quando cambiano dipendenze o processo di build, confrontare le versioni, assegnare un proprietario ai risultati e collegare ogni alert al ticket di analisi, alla decisione di rischio e all’eventuale patch. Senza questi collegamenti, la SBOM diventa un inventario molto preciso del software di ieri.
Dal componente al fix: il vulnerability handling come circuito
Il vulnerability handling richiesto dal CRA è un circuito continuo. L’inventario alimenta il monitoraggio di CVE, EUVD, advisory dei progetti e fonti di threat intelligence; il triage verifica se il componente è presente e se la condizione vulnerabile è raggiungibile; la valutazione combina severità tecnica, sfruttabilità, esposizione e impatto sul prodotto; la remediation seleziona aggiornamento, mitigazione, sostituzione o rimozione; test e distribuzione sicura chiudono il ciclo con un advisory comprensibile agli utenti.
L’Allegato I impone ai fabbricanti di trattare e correggere senza ritardo le vulnerabilità in funzione del rischio, sottoporre il prodotto a test e revisioni regolari, adottare una politica di coordinated vulnerability disclosure, offrire un contatto per le segnalazioni e distribuire gli aggiornamenti di sicurezza in modo tempestivo e sicuro. Dopo la disponibilità dell’aggiornamento devono essere pubblicate informazioni sulle vulnerabilità corrette, salvo il differimento giustificato quando la divulgazione anticipata aumenterebbe il rischio.
Il rapporto con l’open source è bidirezionale. Quando il fabbricante individua una vulnerabilità in un componente integrato deve informare chi lo produce o mantiene e deve intervenire sul proprio prodotto. Se sviluppa una modifica software o hardware per correggere il difetto, condivide, quando appropriato, il codice o la documentazione con il maintainer, anche in formato leggibile automaticamente. Il CRA trasforma così il downstream commerciale da semplice consumatore del progetto a partecipante responsabile della sua sicurezza.
Per il gestore, lo stesso circuito assume una forma proporzionata: canale di ricezione, coordinamento tra maintainer, criteri di priorità, gestione riservata delle informazioni, preparazione e revisione delle patch, rilascio dell’advisory e condivisione con la comunità. La politica verificabile deve mostrare dove il processo passa dalla collaborazione informale a una decisione tracciata.
Dall’11 settembre 2026 parte l’orologio delle notifiche
Il CRA distingue la vulnerabilità, la vulnerabilità sfruttabile e quella attivamente sfruttata. Quest’ultima richiede prove attendibili che un attore malevolo l’abbia utilizzata in un sistema senza autorizzazione. La presenza di un CVE nella SBOM apre quindi l’analisi; non coincide, da sola, con il presupposto della notifica obbligatoria. Anche le vulnerabilità non attivamente sfruttate restano soggette alla valutazione e alla remediation senza ritardo prevista dall’Allegato I e possono essere segnalate volontariamente ai sensi dell’articolo 15.
Per una vulnerabilità attivamente sfruttata, l’articolo 14 prevede un preallarme senza ingiustificato ritardo e comunque entro 24 ore dalla conoscenza, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave che incide sulla sicurezza del prodotto, le prime due finestre restano di 24 e 72 ore, mentre la relazione finale arriva entro un mese dalla notifica dell’incidente.
Le segnalazioni transitano attraverso la Single Reporting Platform gestita da ENISA e raggiungono il CSIRT coordinatore determinato in base allo stabilimento principale. Le FAQ ENISA aggiornate al 31 luglio 2026 indicano che il portale sarà operativo entro l’11 settembre e che, nella fase iniziale, non sarà disponibile un’API, anche se le organizzazioni potranno automatizzare i propri flussi interni. La capacità di produrre rapidamente i dati richiesti deve quindi essere preparata a monte del portale.
Gli obblighi di reporting si applicano anche ai prodotti già immessi sul mercato prima della piena applicazione del CRA. Per i gestori open source, la notifica delle vulnerabilità attivamente sfruttate opera nella misura in cui essi partecipano allo sviluppo del prodotto. La notifica degli incidenti gravi riguarda invece gli eventi che colpiscono i sistemi messi a disposizione dal gestore per lo sviluppo dei prodotti. Questa delimitazione evita di trasformare il gestore in un centro di monitoraggio universale di ogni implementazione downstream.
Un processo credibile assegna in anticipo chi può dichiarare la conoscenza dell’evento, chi valuta il trigger legale, chi invia il preallarme fuori dall’orario lavorativo e chi coordina sicurezza di prodotto, sviluppo, legale e comunicazione. Una simulazione su un componente open source critico permette di verificare se, entro 24 ore, l’organizzazione sa identificare prodotti e versioni interessati, Stati membri rilevanti, misure disponibili e livello di sensibilità delle informazioni.
I contratti non trasferiscono la responsabilità, ma possono far circolare le informazioni
Il fabbricante non può trasferire al progetto open source la propria responsabilità di conformità. Può però costruire accordi che rendano possibile rispettarla: consegna di SBOM o manifesti versionati, identificazione del punto di contatto, preavviso sulle vulnerabilità, support period, disponibilità delle patch, formato degli advisory, gestione degli embargo, condivisione di VEX e collaborazione sui fix. Gli SLA informativi devono lasciare al fabbricante tempo sufficiente per rispettare la finestra europea di 24 ore.
Questa impostazione richiede equilibrio. Trattare una fondazione o un gruppo di maintainer come un fornitore enterprise senza finanziare capacità di sicurezza, test e manutenzione riproduce il problema che il CRA tenta di correggere. Il downstream commerciale può contribuire con risorse, bug bounty, personale, infrastrutture di build e patch upstream. Quando manca un gestore o il progetto non offre un supporto compatibile con il rischio, il fabbricante deve scegliere consapevolmente se mantenere una fork, sostituire la dipendenza, introdurre controlli compensativi o cessarne l’uso.
La due diligence acquista così un contenuto concreto: conoscere la componente, comprenderne il modello di governo, valutarne la capacità di ricevere e correggere vulnerabilità, pianificare l’uscita e documentare la decisione. La sola presenza di un repository attivo o di molti download non dimostra la sostenibilità del componente per l’intero periodo di supporto del prodotto.
La conformità si gioca nella relazione tra distinta e processo
Il CRA attribuisce all’open source un ruolo strutturale nella sicurezza dei prodotti europei. Il contributore volontario resta protetto, il gestore rende verificabile la cura del progetto e il fabbricante che trae il prodotto verso il mercato assume la responsabilità per ciò che integra. Questa architettura funziona quando le informazioni passano tra i livelli con sufficiente qualità e velocità.
La SBOM offre la mappa, il vulnerability handling decide dove intervenire, la coordinated disclosure governa tempi e destinatari, il reporting collega il prodotto all’ecosistema europeo di risposta. Preparare uno solo di questi elementi lascia scoperti gli altri. Per le organizzazioni che attendono l’11 dicembre 2027, il calendario contiene una data più vicina: dall’11 settembre 2026 il processo deve già riconoscere un evento notificabile e trasformarlo, entro 24 ore, in una comunicazione fondata su prodotti, versioni e dipendenze realmente conosciuti.
Fonti essenziali
Regolamento (UE) 2024/2847 – Cyber Resilience Act, testo ufficiale italiano
Commissione europea, C(2026) 5252 e linee guida sull’applicazione del CRA, 27 luglio 2026
Commissione europea, Cyber Resilience Act – Open source, aggiornamento 31 luglio 2026
Commissione europea, Cyber Resilience Act – Reporting obligations, aggiornamento 31 luglio 2026
ENISA, Single Reporting Platform e FAQ operative, aggiornamento 31 luglio 2026
SPDX, specifiche per la rappresentazione machine-readable delle SBOM
OWASP CycloneDX, panoramica della specifica
CISA, risorse su SBOM e Vulnerability Exploitability eXchange (VEX)
Partecipa alla community