Eclipse Foundation e OWASP Foundation hanno firmato un Memorandum of Understanding per rafforzare la sicurezza dell’open source e preparare fondazioni, manutentori, steward e produttori all’applicazione del Cyber Resilience Act europeo.
L’accordo annunciato dalle due organizzazioni mette in comune l’esperienza di Eclipse nella governance dei progetti e nella preparazione normativa con gli standard, gli strumenti e le attività formative sviluppati dalla comunità OWASP. La collaborazione produrrà indicazioni pratiche e risorse per chi sviluppa, mantiene o incorpora componenti open source nei propri prodotti.
Il calendario europeo imprime urgenza al lavoro. Dall’11 settembre 2026 diventeranno applicabili gli obblighi del CRA relativi alla segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi. La maggior parte delle altre disposizioni entrerà in applicazione l’11 dicembre 2027.
La portata dell’accordo si misura anche nella diffusione del codice interessato. Secondo l’OpenLogic 2026 State of Open Source Report, citato nel comunicato, oltre il 96% delle codebase commerciali contiene software open source. Librerie, framework e runtime sviluppati dalle comunità sono ormai componenti ordinari dei prodotti digitali venduti dalle imprese.
Cinque aree di collaborazione
Il Memorandum individua cinque direttrici: preparazione dell’ecosistema open source al CRA, allineamento e interoperabilità fra pratiche e framework di sicurezza, formazione congiunta, sostegno a steward e manutentori, informazione sulle politiche e sulla regolamentazione.
Le prime iniziative comprenderanno guide pratiche per gli open source software steward, webinar dedicati al CRA, risorse per l’adozione delle Software Bill of Materials (SBOM) e la protezione della software supply chain, oltre a workshop, incontri con la comunità e tavole rotonde rivolte ai manutentori.
Eclipse e OWASP precisano di non voler creare un nuovo framework in concorrenza con quelli esistenti. Il lavoro sarà rivolto piuttosto ad allineare le iniziative già disponibili, ampliarne la diffusione e facilitarne l’integrazione nei processi di sviluppo e gestione del software.
La scelta riflette le competenze delle due fondazioni. Eclipse ospita oltre 450 progetti open source e coordina attività di collaborazione fra comunità, imprese e istituzioni. OWASP sviluppa progetti, standard e materiale formativo dedicati alla sicurezza del software, fra cui CycloneDX, standard aperto per rappresentare componenti, servizi e dipendenze all’interno di una SBOM.
”L’open source è un’infrastruttura digitale critica, ma la responsabilità della sua sicurezza è distribuita in un ecosistema globale complesso”, osserva Mike Milinkovich, Executive Director di Eclipse Foundation. L’accelerazione dello sviluppo assistito dall’intelligenza artificiale e della scoperta delle vulnerabilità rende, secondo Milinkovich, sempre più urgente un intervento coordinato.
Andrew van der Stock, Executive Director di OWASP Foundation, richiama invece la necessità di tradurre le indicazioni in attività concrete: ”Le linee guida sulla sicurezza fanno la differenza soltanto quando sviluppatori, manutentori e organizzazioni riescono a tradurle in pratica”.
Perché il CRA coinvolge l’open source
Il Regolamento (UE) 2024/2847, noto come Cyber Resilience Act, è la normativa con cui l’Unione europea rende la cybersicurezza un requisito legale per immettere sul mercato prodotti con elementi digitali. In termini concreti, obbliga i produttori a progettare hardware e software tenendo conto della sicurezza, correggerne le vulnerabilità, distribuire aggiornamenti durante il periodo di supporto e documentarne la conformità. I prodotti soggetti al regolamento dovranno inoltre seguire la procedura di valutazione prevista e riportare la marcatura CE.
Il CRA interessa dispositivi connessi, applicazioni, sistemi operativi, software enterprise installabile, componenti commercializzati separatamente e soluzioni di elaborazione remota necessarie al funzionamento di un prodotto distribuito nell’Unione europea.
Il CRA stabilisce anche principi di secure by design e secure by default. La sicurezza deve essere considerata durante progettazione e sviluppo, non aggiunta alla fine, e il prodotto deve arrivare all’utente con una configurazione iniziale sicura. La protezione continua dopo la vendita attraverso la gestione delle vulnerabilità e gli aggiornamenti per il periodo di supporto dichiarato.
La responsabilità della conformità rimane in capo al produttore, cioè al soggetto che sviluppa o fa sviluppare un prodotto e lo commercializza con il proprio nome o marchio. L’impiego di una dipendenza open source non trasferisce questa responsabilità al progetto che l’ha realizzata. Il produttore deve conoscere i componenti presenti, valutarne i rischi, gestire le vulnerabilità e assicurare gli aggiornamenti durante il periodo di supporto.
La regola vale indipendentemente dal Paese in cui il prodotto viene sviluppato. Un’impresa statunitense, cinese o indiana che commercializza hardware o software nell’Unione deve rispettare gli stessi requisiti di un produttore europeo. Per questo una normativa europea finisce per influenzare processi di sviluppo e catene di fornitura distribuiti in tutto il mondo.
Il regolamento riconosce però anche la figura dell’open source software steward: una persona giuridica, diversa dal produttore, che sostiene in modo sistematico e continuativo lo sviluppo di software libero e open source destinato ad attività commerciali e ne assicura la sostenibilità.
Agli steward è riservato un regime distinto da quello dei produttori. Devono adottare e documentare una politica di cybersicurezza, favorire la segnalazione e la gestione delle vulnerabilità, cooperare con le autorità di vigilanza e rendere disponibile la documentazione pertinente. Non sono invece equiparati al produttore del prodotto finale nel quale il codice viene integrato.
I singoli contributori e manutentori che pubblicano codice al di fuori di un’attività commerciale non diventano automaticamente soggetti agli obblighi del CRA. Le risorse previste dall’accordo serviranno anche a chiarire questa ripartizione delle responsabilità ed evitare che le richieste di conformità vengano trasferite indistintamente sulle comunità.
SBOM e gestione delle vulnerabilità fra le priorità
La Software Bill of Materials è uno dei principali punti di contatto fra i progetti open source e le aziende che ne utilizzano il codice. Il CRA richiede ai produttori di identificare e documentare i componenti presenti nel prodotto, anche attraverso una distinta in un formato comunemente usato e leggibile da una macchina, comprendente almeno le dipendenze di primo livello.
Una SBOM non certifica da sola la sicurezza del prodotto, ma permette di verificare rapidamente se una vulnerabilità interessa una versione distribuita. Per essere efficace deve collegarsi al monitoraggio delle dipendenze, alle procedure di coordinated vulnerability disclosure e ai processi di aggiornamento.
La prima scadenza del regolamento rende particolarmente urgente quest’ultimo aspetto. Dall’11 settembre 2026 i produttori dovranno notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi. La procedura prevede una prima segnalazione entro 24 ore dal momento in cui il produttore viene a conoscenza dell’evento e una notifica più completa entro 72 ore.
Rispettare tempi così brevi richiede canali già operativi fra produttori, team di sicurezza, fornitori e progetti upstream. Le attività congiunte di Eclipse e OWASP potranno fornire modelli e pratiche comuni per raccogliere le informazioni, coordinare le correzioni e documentare le decisioni senza moltiplicare procedure incompatibili.
Il lavoro già avviato nell’ORC Working Group
Le due fondazioni collaborano già nell’Open Regulatory Compliance Working Group, ospitato da Eclipse. Il gruppo riunisce fondazioni open source, imprese e altri attori dell’industria per elaborare specifiche, buone pratiche e strumenti dedicati all’applicazione delle nuove norme sul software.
Il Memorandum estende questo lavoro attraverso i progetti, gli standard e la rete formativa di OWASP. La combinazione può accelerare il passaggio dall’interpretazione del regolamento a risorse utilizzabili nei processi quotidiani: policy di sicurezza, formati per le SBOM, procedure di gestione delle vulnerabilità e percorsi di formazione per steward e manutentori.
L’accordo assume quindi valore soprattutto operativo. A ridosso delle prime scadenze, Eclipse Foundation e OWASP provano a ridurre la distanza fra i requisiti del CRA e le pratiche con cui l’open source viene effettivamente sviluppato, governato e integrato nei prodotti commerciali.
