Organizzazioni di ogni forma, dimensione e settore hanno adottato il software open source (OSS). Anche le industrie finanziarie, mediche e manifatturiere ora utilizzano questi software come base per le loro applicazioni e attività più critiche. Tuttavia, questa adozione diffusa comporta delle insidie, tra cui un aumento di quasi l’800% degli attacchi alla supply chain del software secondo quanto riportato dal report State of the Software Supply Chain di Sonatype.

Con la rapida crescita dell’adozione di OSS, le organizzazioni hanno iniziato a creare degli Open Source Program Offices (OSPO) per aiutare a codificare le strategie sull’uso e il contributo dei software open source e per promuovere la collaborazione con la più ampia comunità OSS. Questi OSPO hanno spesso responsabilità chiave tra cui coltivare una strategia OSS, guidarne l’esecuzione e facilitare l’uso di prodotti e servizi OSS in un’azienda.

L’OSPO come elemento chiave della sicurezza strategica

La posizione unica dell’OSPO nel guidare la gestione e la strategia di software open source lo rende un attore chiave nell’approccio di un’organizzazione alla sicurezza e alla governance dell’OSS, un ruolo ormai sempre più critico. L’OSS richiede un’attenta gestione, anche perché diversi studi dimostrano che le applicazioni moderne includono più di 500 componenti OSS. Con un uso così diffuso, è importante riconoscere alcune statistiche allarmanti riguardanti i componenti OSS. Secondo un sondaggio Synopsis del 2022, l’81% include almeno una vulnerabilità, l’88% non ha avuto nuovi sviluppi negli ultimi due anni e l’88% di quelli utilizzati non erano l’ultima versione. Tutte queste metriche culminano in una realtà allarmante: le organizzazioni stanno facendo ampio uso di componenti obsoleti e insicuri. Ciò significa che abbiamo una superficie di attacco massiccia in ambienti aziendali moderni mal governati e ricchi di possibilità per attori malintenzionati.

Molti hanno familiarità con l’ordine esecutivo (EO) della sicurezza informatica degli Stati Uniti, inclusa la Sezione 4 (Miglioramento della sicurezza della catena di fornitura del software). Come risultato dell’EO, il National Institute of Standards and Technology (NIST) ha prodotto una guida completa alla supply chain del software, compresi i controlli software open source e il modo in cui gli OSPO possono sostenere la loro implementazione.

Il NIST definisce la sua suite di controlli OSS in tre livelli di maturità: funzionalità di base, di supporto e di miglioramento. Tra questi controlli ci sono elementi come la garanzia che i componenti OSS siano acquisiti tramite canali sicuri da fonti affidabili. La realtà del moderno ambiente aziendale è che la maggior parte delle organizzazioni non ha piena visibilità e governance dell’uso di software open source al loro interno, per non parlare del monitoraggio continuo delle vulnerabilità ad esso associate.

L’OSPO come evangelista per un uso efficace e sicuro dell’OSS

Questo è un perfetto esempio dell’importanza di un OSPO come evangelista per l’uso efficace dei prodotti e dei servizi OSS commerciali, con lo scopo sia di sostenere la vigilanza per le vulnerabilità associate all’OSS, sia di assicurare che queste pratiche di sicurezza siano codificate in politiche e processi organizzativi.

ospo

I controlli di sicurezza OSS consigliati dal NIST includono anche la creazione di repository interni di componenti OSS noti e controllati che gli sviluppatori possono utilizzare per ridurre i rischi organizzativi. Piuttosto che consentire un ambiente in cui gli sviluppatori sono liberi di estrarre e utilizzare tutti i componenti OSS senza informazioni sulle loro vulnerabilità e rischi, i repository interni creano una libreria di componenti OSS che consentono di ridurre i rischi organizzativi dovuti all’utilizzo dei componenti OSS vulnerabili.

Un’altra raccomandazione chiave del NIST è quella di implementare toolchain di supporto, specificando anche quali strumenti devono essere inclusi nelle pipeline CI/CD per mitigare i rischi. Gli esempi potrebbero includere l’integrazione di elementi come l’analisi della composizione software (SCA) e gli strumenti SBOM (Software Bill of Materials) nelle moderne toolchain CI/CD, con lo scopo di garantire che l’azienda ottenga la piena visibilità dei componenti OSS vulnerabili che si spostano attraverso le toolchain e negli ambienti di produzione.

Ciò assicura anche che le scansioni di sicurezza si verifichino prima nel ciclo di vita dello sviluppo del software e che le vulnerabilità vengano identificate e corrette prima di introdurle in produzione dove possono essere sfruttate da attori malintenzionati. Le politiche e i processi che gli OSPO possono evangelizzare e codificare in quest’area includono non solo la scansione delle vulnerabilità e SBOM, ma anche l’abilitazione di funzionalità di firma che aiutano a creare record e registri immutabili per supportare sia l’integrità, sia la verificabilità delle attività di sviluppo software.

Il passaggio al livello più maturo stabilito dal NIST (migliorare le capacità) include la priorità dell’uso di linguaggi di programmazione sicuri e, infine, l’automazione della raccolta, dell’archiviazione e della scansione dei componenti OSS nei repository interni rafforzati di cui abbiamo parlato poco sopra. Questo è forse il passo più critico per aiutare a ridurre il rischio senza ostacolare la velocità dei team di sviluppo.

Ruoli OSPO: relazioni con gli sviluppatori, sostegno ed evangelizzazione

Tra i ruoli comunemente ricoperti in un OSPO ci sono le relazioni con gli sviluppatori, il sostegno e l’evangelizzazione. Mentre questi gruppi spesso creano entusiasmo e interesse tra i team di sviluppo dell’azienda, spesso si occupano anche di forgiare relazioni critiche. Queste relazioni possono essere sfruttate per incoraggiare l’adesione alle best practice di sicurezza OSS emergenti, che molte organizzazioni semplicemente non hanno ancora implementato nonostante l’ampio utilizzo di OSS nelle loro applicazioni, software e prodotti. Ciò crea molteplici vantaggi, ad esempio garantendo che l’organizzazione riduca al minimo l’uso di dipendenze non sicure e produca applicazioni più sicure per scopi interni ed esterni.

Una ricerca suggerisce anche che i fornitori di software sono i principali beneficiari dell’OSS e sono quindi nella posizione migliore per aiutare ad affrontare il rischio della supply chain di software open source. Ciò pone i fornitori di software in un’ottima posizione per essere più coinvolti nelle comunità OSS, scansionare le vulnerabilità e contribuire ai progetti OSS per mitigarle. Un cambiamento notevole rispetto al modello attuale in cui la comunità OSS si fa carico in gran parte di questo onere, con una mancanza di partecipazione paritaria e di contributi significativi da parte della comunità dei fornitori di software. Ciò pone gli OSPO in una posizione ideale per guidare un cambiamento di paradigma e, in ultima analisi, per rafforzare la sicurezza della più ampia supply chain del software open source.