L’entrata in vigore progressiva del Cyber Resilience Act (CRA) ridefinisce gli obblighi dell’ecosistema open source europeo. Dal 11 settembre 2026, i produttori di prodotti digitali devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, secondo l’articolo 14 del regolamento. L’applicazione generale è prevista per l’11 dicembre 2027, e i progetti open source non sono tutti trattati allo stesso modo.
CRA e software libero: obblighi differenziati tra manutentori e volontari
Il CRA introduce una distinzione operativa che aspettavamo dalla pubblicazione del testo. I manutentori professionisti qualificati di steward del software libero, coloro che supportano in modo sostenibile progetti integrati in prodotti commerciali, rientrano nel perimetro normativo. Dovranno documentare i loro processi di gestione delle vulnerabilità e contribuire alla catena di conformità.
I singoli contributori volontari rimangono al di fuori del principale perimetro. Questa linea di demarcazione si basa sul carattere commerciale o meno dell’attività, non sulla licenza utilizzata. Uno sviluppatore che pubblica una correzione nel fine settimana non ha le stesse restrizioni di una fondazione che mantiene una libreria critica distribuita in migliaia di prodotti.
Per le PMI e i progetti open source di dimensioni modeste, è stato pubblicato uno strumento libero di preparazione al CRA nell’ambito del progetto europeo OCCTET, coordinato dalla Eclipse Foundation. Copre l’inventario delle dipendenze, la gestione delle vulnerabilità, la generazione di SBOM (Software Bill of Materials) e la documentazione di conformità. Risorse complementari vengono regolarmente referenziate su mondelibre.org, che aggrega le pubblicazioni francofone su queste evoluzioni normative.
Strategia open source dell’Unione europea: un quadro che copre l’intero ciclo di vita
La nuova strategia open source dell’UE non si limita più all’adozione di software libero nelle amministrazioni. Ora copre l’intero ciclo di vita del software, dalla progettazione alla manutenzione, passando per la governance dei contributi. Osserviamo un cambiamento di postura: il software libero non è più trattato come uno strumento di economia di bilancio, ma come un leva di sovranità tecnologica.
Questo approccio si inserisce in un pacchetto più ampio sulla sovranità tecnologica europea. Articola i requisiti del CRA con le politiche di interoperabilità e sicurezza digitale. Le amministrazioni pubbliche sono incentivate a contribuire attivamente ai progetti che utilizzano, non solo a consumarli.
OSPO e conformità CRA nelle organizzazioni
Le Open Source Program Offices (OSPO) centralizzano la gestione delle dipendenze open source, il monitoraggio delle licenze e il coordinamento dei contributi. Queste strutture interne, ancora rare in Francia, costituiscono un vantaggio per la messa in conformità con il CRA. Un OSPO operativo fornisce un inventario software aggiornato e processi di segnalazione delle vulnerabilità già collaudati.
Le aziende che non hanno una struttura equivalente dovranno costruire questi processi da zero prima di dicembre 2027. Il costo organizzativo supera di gran lunga il costo tecnico.
Acquisizioni strategiche: Nvidia, Hugging Face e la questione dell’apertura
L’acquisizione di Hugging Face da parte di Nvidia per 12,93 miliardi di dollari rappresenta il movimento capitalista più significativo dell’anno nell’ecosistema open source. Nvidia afferma di voler preservare l’apertura della piattaforma ai diversi modelli, cloud e acceleratori.
Questa promessa merita un esame tecnico. Hugging Face ospita modelli addestrati su architetture varie (GPU Nvidia, AMD, acceleratori TPU). La neutralità hardware della piattaforma è il suo principale attivo. Se Nvidia privilegiasse i propri acceleratori nel ranking dei modelli o negli strumenti di inferenza, la comunità migrerebbe rapidamente.
AWS ha anche annunciato l’acquisto di DuckLabs, con un impegno simile di preservazione del modello open source. Queste operazioni seguono uno schema ricorrente: acquisizione di un progetto comunitario ad alta trazione, promessa di apertura, poi monetizzazione progressiva tramite servizi gestiti. La questione non è se l’apertura sarà mantenuta, ma quale perimetro esatto rimarrà sotto licenza libera.
Sicurezza dei progetti open source e catena di approvvigionamento software
La messa in sicurezza della catena di approvvigionamento software open source diventa una questione centrale man mano che i modelli open weight si diffondono senza verifica sistematica. I punti di attenzione per i manutentori sono i seguenti:
- Verificare la provenienza crittografica degli artefatti pubblicati sui registri (npm, PyPI, crates.io) per garantire che un pacchetto non sia stato alterato tra la compilazione e la distribuzione
- Mantenere un SBOM aggiornato per ogni release, includendo le dipendenze transitive spesso ignorate negli audit manuali
- Integrare gli strumenti di scoring di sicurezza (come Scorecard) nei pipeline CI/CD per rilevare le regressioni della postura di sicurezza prima della pubblicazione
La conformità open source diventa un mercato a sé stante, con soluzioni dedicate che emergono per rispondere alle crescenti esigenze dei settori regolamentati.
Governance aperta e sostenibilità dei progetti comunitari
Il modello di governance aperta, in cui le decisioni tecniche sono prese da un comitato eletto dai contributori, rimane l’eccezione piuttosto che la norma. La maggior parte dei progetti open source critici dipende ancora da uno o due manutentori principali senza una struttura di governance formalizzata.
La sostenibilità dei registri di pacchetti pone un problema strutturale. Queste infrastrutture (npm, PyPI, Maven Central) funzionano come servizi pubblici dello sviluppo software, ma il loro finanziamento si basa ampiamente sul supporto volontario delle aziende. Senza un impegno duraturo da parte degli attori industriali, il rischio di degrado di questi registri aumenta man mano che cresce il numero di pacchetti pubblicati.
Il quadro normativo europeo, i movimenti di acquisizione e la strutturazione progressiva della sicurezza convergono verso un’unica constatazione: l’open source entra in una fase in cui la governance, la conformità e il finanziamento contano tanto quanto il codice stesso. Le organizzazioni che non hanno ancora formalizzato la loro politica open source hanno poco più di un anno prima della scadenza del CRA.
