Quando è esploso il caso Apache Log4j, da più parti si sono criticati gli sviluppatori che manutenevano il progetto perché non erano stati capaci di evitare, o comunque di rilevare, un bug che ha reso improvvisamente vulnerabili migliaia di siti. D'improvviso l'open source ha mostrato - di nuovo - un problema quasi "strutturale" di sicurezza e affidabilità. Che è giusto considerare, certo, ma senza banalizzarlo. E quindi anche senza accusare gli sviluppatori indipendenti a causa di - come ha evidenziato uno dei manutentori del progetto Log4j, Volkan Yazici - "un lavoro per il quale non siamo pagati e una funzione che non ci piace ma che abbiamo dovuto mantenere per questioni di compatibilità all'indietro". Compatibilità tra l'altro richiesta dalle aziende che usavano le librerie, non dagli sviluppatori.

Il mondo dell'open source è fatto di grandi software house ma soprattutto di migliaia di sviluppatori di talento e buona volontà che danno costantemente risultati sorprendenti, e sono questi risultati che hanno dato forza negli anni al modello dell'open source. Traghettandolo dall'essere una strana curiosità da "macinacodice" a rappresentare il cuore della moderna IT. Ma queste migliaia di sviluppatori non sono tutti impiegati a tempo pieno per sviluppare e manutenere codice "free". Alcuni sì, ma sono una quota minoritaria.

Molti sviluppatori portano avanti i loro progetti nel tempo libero, per passione, per senso della community, per favorire un gruppo magari ristretto di utenti. E non è strano che a un certo punto questi stessi sviluppatori possano chiedersi se ne valga davvero la pena. È l'annosa questione della sostenibilità dell'open source, che però oggi - proprio perché il software libero è onnipresente - viene considerata quasi solo per le sue conseguenze lato cyber security.

Troppo semplice prendersela con gli sviluppatori per i bug di un progetto: non tutti sono grandi aziende. Semmai il contrario.

Di recente è stato Kent Walker, President Global Affairs & Chief Legal Officer di Google e Alphabet, a sintetizzare la base del problema. "Per troppo tempo - scrive Walker - la comunità software si è adagiata nell'idea che il software open source è genericamente sicuro grazie alla sua trasparenza e al presupposto che 'molti occhi' lo esaminino per rilevare e risolvere problemi. Ma in effetti, sebbene alcuni progetti abbiano effettivamente molti occhi addosso, altri ne hanno pochi o non ne hanno nessuno".

L'open source che si fa critico

La soluzione al problema? Per Google è spingere le aziende private e il settore pubblico a identificare i progetti open source più importanti e considerarli alla stregua delle infrastrutture critiche nazionali. Quindi, dedicare le risorse necessarie a garantire la loro sicurezza e la loro affidabilità. Inoltre, aumentare il livello di controllo sulla sicurezza dei componenti open source che possono porre "un rischio sistemico" perché entrano a far parte di molti altri progetti più critici.

È un complesso di idee non proprio nuovo, rimanda a diverse iniziative lanciate negli anni passati per garantire un maggiore livello medio di sicurezza del software libero. Come ad esempio quelle della Open Source Security Foundation (OpenSSF). Una visione che comunque Google e molti altri grandi nomi del sofware e del cloud hanno "venduto" alla Casa Bianca, trasformando la sicurezza dell'open source in un problema nazionale. Cambierà qualcosa a breve o medio termine? Crediamo poco. Certo è facile identificare qualche decina di progetti chiave e garantire (ragionevolmente) la loro sicurezza. Ma per tutti gli altri, niente? Eppure "Il 99% del software al mondo ha almeno un po' di codice open source nel suo DNA", scrive Mike Hanley, Chief Security Officer di GitHub.Proprio Hanley sottolinea un altro modo di affrontare il problema, in un certo senso direttamente alla radice. Tutto il mercato del software dovrebbe "collaborare per supportare gli sviluppatori che progettano, realizzano e manutengono i progetti open source su cui facciamo affidamento". Servono strumenti software, formazione (uno sviluppatore non è per forza anche un esperto di sicurezza) e soprattutto fondi. Che per ora sono lasciati alla buona volontà dei singoli e soprattutto delle aziende che l'open source lo usano. Con risultati - è opinione diffusa tra gli sviluppatori open source - marginali.

Il modello di business dell'open source

Che c'entra la sicurezza? C'entra eccome. Chi avvia un progetto open source e non ne ha ritorni economici non ha nemmeno le risorse per garantire davvero la sicurezza del suo codice. Specie se si tratta di codice rilasciato magari anni prima, per un progetto che non si ha più modo di seguire, dovendosi dedicare a progetti più nuovi e, si spera, più remunerativi. Così, partendo dalla sicurezza Mike Hanley in effetti lancia un tema più ampio che sembrerebbe superato nell'era dell'open source al centro dell'IT: quanto si guadagna davvero con il software libero? E chi riesce a farlo? Solo su GitHub ci sono 73 milioni di sviluppatori: quanti sono in perenne difficoltà, a detrimento dei loro progetti?

La situazione la spiega bene, nel suo ambito specifico, Christofer Dutz, il creatore delle librerie Apache PLC4X, molto diffuse in ambito IoT. Frutto di anni di sviluppo "volontario", le librerie, secondo lo sviluppatore, hanno portato grandi risparmi agli utenti ma pochissimi ritorni a chi le ha sviluppate e manutenute. Se, spiega Dutz, un progetto open source che permette ad esempio a un'azienda utente di risparmiare 20 milioni di euro in costi di licenza per un analogo prodotto commerciale, poi non si traduce in un business sostenibile per lo sviluppatore, allora vuol dire che davvero c'è un grosso problema di sostenibilità. Tanto che di recente Dutz ha deciso di interrompere lo sviluppo gratuito delle sue librerie.

La realtà è che le software house capaci di costruire un modello di business vincente sull'open source sono pochissime. E se consideriamo il modello di business storico dell'open source - ossia sviluppare codice libero intorno al quale vendere servizi e supporto di classe enterprise - alla fine si gira sempre intorno a un solo nome: Red Hat. Che resta sempre l'azienda-simbolo del boom open source, ma un simbolo che vale sino a un certo punto. Tanto che è rimasta famosa l'affermazione di Peter Levine, oggi partner di a16z: "non ci sarà mai più un'altra Red Hat". Infatti, le aziende che oggi fanno business sostenibile con l'open source perlopiù adottano o il modello cosidetto Open Core (un "nucleo" di codice open source rivestito di componenti proprietari a valore aggiunto), oppure l'approccio SaaS, offrendo piattaforme open source in modalità as-a-Service e puntando su un valore aggiunto operativo. Ma per fare questo ci vuole una buona forza di mercato.

in generale, è un dato di fatto che applicazioni e servizi anche chiave per una impresa possono basarsi su moduli e librerie open source di singoli sviluppatori indipendenti. Altro che Red Hat. Esiste un rischio non trascurabile che tutta l'architettura IT evoluta di una impresa si basi - per citare una notissima vignetta di xkcd - su un componente open source di "un progetto che qualcuno in Nebraska sta gestendo dal 2003 senza che nessuno lo ringrazi". Così, sarà anche indubbiamente vero che l'open source è stato definitivamente sdoganato a livello enterprise. Ma questo non risolve tutti i problemi possibili. E comunque il mondo open resta decisamente variegato.

Chi controlla il codice

Lato sicurezza le grandi software house, i provider e gli hyperscaler hanno le risorse per controllare l'affidabilità del codice open source che usano e che sviluppano, garantendone la sicurezza. Le altre aziende, anche grandi, avrebbero ugualmente la necessità e l'interesse di verificare l'affidabilità del codice o dei binari open source che si usano all'interno dei loro progetti. Ma di fatto non lo fa quasi nessuno. Perché non è semplice, ma soprattutto perché si fa prima a fidarsi implicitamente dell'affidabilità dei componenti che ricavano da repository come GitHub. E appare naturale farlo.

In parte questo ha senso, per i progetti open source di maggiore successo. Che si suppone siano i più controllati e che spesso nascono all'interno dei grandi nomi dell'IT e del cloud. Una specie di garanzia aggiuntiva di affidabilità. Ma migliaia di progetti "altri" hanno meno risorse a disposizione, anche se sono magari alla base di milioni di applicazioni. È qui che c'è molto spazio per lavorare, da un lato abilitando sistemi che garantiscano l'affidabilità di quello che viene dai repository open source, dall'altro con tecnologie che almeno aiutino le imprese a tenere costantemente traccia del software che usano.

Il primo campo è quello della protezione della supply chain del software. Che quando viene "bucata" porta a casi eclatanti come, di recente, quello di SolarWinds. Ci sono diverse possibili strade per tutelare chi adotta componenti open source, tutte genericamente richiedono un maggiore controllo sul processo di sviluppo e di "build" dei componenti stessi. La Linux Foundation, ad esempio, di recente sta puntando sul concetto delle "reproducible build": da uno stesso codice sorgente devono derivare artefatti software identici, a garanzia che non siano state introdotte modifiche arbitrarie - e malevole - o backdoor.

Il secondo campo è quello delle Software Bills of Materials (SBOM), le "bolle" che indicano esattamente quali componenti software, proprietari come anche open source, fanno parte di un determinato progetto. Una SBOM elenca i moduli software usati per creare una applicazione o un servizio, chi li ha sviluppati, le loro versioni, le dipendenze fra loro, le licenze che adottano e altre informazioni che permettono di identificarli con precisione. In questo modo, se un componente presenta problemi di sicurezza è facile identificare i progetti in cui è presente e intervenire si di essi.

Le SBOM oggi sono in prima linea soprattutto perché il Governo USA le ha rese obbligatorie, sulla scia del caso Solarwinds, per tutte le realtà che intendono vendere software e servizi alle agenzie federali statunitensi. Sono però ancora un campo in via di evoluzione. Servono più strumenti per generare e aggiornare automaticamente le BOM (è il campo della SCA o Software Composition Analysis), i "linguaggi" in cui scriverle sono in via di standardizzazione, occorre una maggiore integrazione tra i tool SCA e tutto il ciclo di sviluppo, integrazione, implementazione delle applicazioni. Sino a quando questo settore non si sarà stabilizzato, il compito di controllare la supply chain software sarà ancora tutto sulle spalle dei team di sviluppo.