Era il 2021 quando furono scoperte gravi vulnerabilità nella libreria di log open source basata su Java Log4j. Un colpo duro per il governo statunitense, ma che col tempo sembrava essere stato sepolto sotto un’ampia serie di nuove preoccupazioni, anche e soprattutto legate alle elezioni. Preoccupazioni più “popolari” e impattanti sul consenso, per lo meno rispetto a un problema di cybersecurity, tema su cui sta aumentando la consapevolezza, ma troppo lentamente. Non in tempo per le urne.
Dopo due anni, invece, si scopre che il governo da quel momento aveva iniziato silenziosamente a meditare su una strategia per far sì che un tale danno non si ripetesse. E con coraggio viene annunciata un’apertura alla collaborazione e al dialogo con la community open source.
Threat sharing: diversi ma uniti
Chiamare “apertura” la mossa della CISA è impreciso, la si potrebbe quasi definire una richiesta di aiuto, per gestire la sicurezza dei software open source assieme avviando una serie di iniziative rivolte alla supply chain del software.
Anche gli sviluppatori sono chiamati a dare una mano in prima persona, aderendo a questo programma volontario di condivisione delle informazioni sulle minacce con i federali e gli operatori di software open source (OOS), guidato dalla Cybersecurity and Infrastructure Security Agency (CISA).
A spingere il governo alla collaborazione in tempo reale sugli incidenti di sicurezza, non è stato solo il drammatico impatto creato dalla vulnerabilità di Log4Shell. Questo è stato l’ultimo campanello di allarme che ha fatto fare due conti al governo, permettendogli di accorgersi che molte delle sue infrastrutture critiche si basano proprio su software open source.
L’ampia diffusione degli OOS rende quindi lo sfruttamento delle loro vulnerabilità sempre più impattante, giorno dopo giorno, nel pubblico ma anche nel settore privato. E il modello open porta con sé delle sfide legate alla natura globale di queste community: non è come lavorare con le aziende. Per rafforzare la propria posizione di contrasto alle vulnerabilità, il governo si trova però costretto a domandare la partecipazione e il feedback di chi ha un approccio diverso da quello a cui è abituato, consapevole di doversi adeguare a modalità e mindset variegati e differenti. Questo non comporta per forza il fatto che non arriveranno contributi di valore, anzi, potranno molto probabilmente essere fondamentali.
Le reazioni delle community OOS: ci sono
Oltre alla condivisione delle minacce, nella strategia CISA dedicata al mondo open source c’è anche l’invito rivolto alle varie community a migliorare la sicurezza nei rispettivi progetti. Le prime risposte sembrano essere propositive e collaborative. Fanno pensare che il momento per collaborare costruttivamente fosse arrivato per entrambi.
Una delle realtà più intraprendenti è la Python Software Foundation che ha scelto di allargare il suo “Trusted Publishing” a GitLab, Google Cloud e ActiveState oltre che a GitHub. Si tratta di uno strumento che consente ai manutentori di PyPI di verificare l’identità tramite lo standard OpenID Connect (OIDC), basato su token di breve durata. In parallelo, sta preparando anche un’API per la segnalazione e la mitigazione del malware e una soluzione che permetta di caricare e distribuire attestati firmati digitalmente, conservandone i metadati su un repository di pacchetti Python per verificarli.
Importante anche il mood collaborativo dimostrato dal più grande repository open source per Java e i linguaggi JVM, Maven Central. Nel suo nuovo portale di pubblicazione ha previsto l’autenticazione a più fattori (MFA) per migliorare la sicurezza del repository. Starebbe anche lavorando sulla sicurezza delle chiavi e su un Trusted Publishing analogo a quello della community alleata.
Una risposta concreta e positiva è giunta anche da Packagist e Composer, che hanno previsto la scansione del database delle vulnerabilità per impedire ai criminali di appropriarsi dei pacchetti senza autorizzazione. La Rust Foundation ha invece annunciato lo sviluppo di un’infrastruttura a chiave pubblica per il repository di pacchetti crates.io per il mirroring e la firma binaria.
Nel nuovo modello collaborativo inaugurato dalla CISA, anche i venditori di OOS sono stati coinvolti. L’appello a loro rivolto è quello di supportare ogni potenziamento della sicurezza del software open source, sia con denaro che con sviluppatori dedicati che ottimizzino la protezione del codice open source inserito nei progetti poi commercializzati. C’è un “to do” anche per le aziende che non si devono illudere di poter stare ferme, godendo dei benefici del gioco di squadra appena iniziato. A loro il compito di tenersi aggiornate con il lavoro di patch di sicurezza che la community fornisce. Quando infatti l’età media delle vulnerabilità open source è alta, come oggi accade, la responsabilità più che essere di ha realizzato il codice, è di chi non lo ha sistemato nel tempo, limitandosi a seguire le indicazioni fornite dagli stessi sviluppatori del mondo OOS.
