Come scegliere le soluzioni open source per la tua azienda

Secondo il rapporto del 2025 sullo stato dell’open source, il 96% delle aziende intervistate utilizza applicazioni open source. L’ampia selezione, le opzioni di personalizzazione e l’assenza di costi di licenza sono estremamente interessanti. Tuttavia, più della metà delle aziende intervistate deve affrontare sfide significative a causa della manutenzione continua delle app open source. Lo sbalorditivo 63% dei casi fatica a tenere aggiornate le soluzioni e ad applicare le patch. Alle spalle ci sono i problemi di cybersecurity, conformità alle normative e presenza di applicazioni open source EoL (End-of-Life), il che significa che non sono più supportate. Quindi, come è possibile ridurre al minimo la probabilità di questi problemi e cosa bisognerebbe cercare quando si seleziona il software open source (OSS) per l’implementazione?

Aggiornamenti e patch

Dato che l’aggiornamento tempestivo dell’OSS è il problema più diffuso, è opportuno esaminare molto attentamente i potenziali candidati all’adozione di OSS da questo punto di vista. È facile controllare la frequenza e l’ambito degli aggiornamenti, nonché il relativo contenuto, direttamente nell’archivio pubblico dell’applicazione. È opportuno prestare attenzione a quanto sono ben documentati gli aggiornamenti; che tipo di problemi risolvono; quali nuove funzionalità aggiungono; la frequenza con cui vengono rilasciate le correzioni secondarie pochi giorni o settimane dopo una versione principale; e la velocità con cui vengono chiuse le richieste relative ai bug.

Strumenti standard come Git Insights, insieme a servizi supplementari come Is it Managed?, Repology e Libraries.io, possono aiutare a rispondere a queste domande. Libraries.io mostra immediatamente quali dipendenze obsolete usa la versione corrente.

Presta particolare attenzione agli aggiornamenti relativi alla sicurezza. Vengono rilasciati separatamente o sono inclusi negli aggiornamenti delle funzionalità? In genere, gli sviluppatori scelgono quest’ultima via. In tal caso, è necessario comprendere da quanto tempo gli aggiornamenti della protezione potrebbero essere in attesa del rilascio.

Valuta inoltre la complessità del processo di installazione degli aggiornamenti. La documentazione e il supporto ufficiali possono essere un punto di partenza, ma non sono sufficienti. È probabile che un’analisi approfondita del feedback della community di utenti sia più utile in questo caso.

Tutto ciò consente di comprendere lo sforzo necessario per la manutenzione del prodotto. Sarà necessario allocare risorse interne per il supporto. Non è sufficiente assegnare semplicemente la responsabilità; per queste attività e per quelle correlate saranno richieste ore di lavoro dedicate.

Raccomandazioni

Per prevedere con precisione la frequenza con cui si dovranno affrontare problemi di cybersecurity, è meglio valutare fin dall’inizio la cultura tecnica e l’igiene della cybersecurity del prodotto. Sebbene questa operazione possa richiedere molto lavoro, è possibile utilizzare strumenti automatizzati per eseguire un’analisi iniziale di alto livello.

Per prodotti e pacchetti popolari, un buon approccio consiste nel controllare i risultati già esistenti della valutazione euristica da strumenti come OpenSSF Scorecard. Fornisce una vasta gamma di dati sull’igiene della cybersecurity, che vanno dal numero di vulnerabilità senza patch e dalla presenza di criteri di sicurezza all’utilizzo di fuzzing e pinning delle dipendenze.

Esamina inoltre i database delle vulnerabilità pubblici come gli avvisi di NVD e GitHub per comprendere quanti difetti sono stati scoperti nel progetto, la relativa criticità e la velocità con cui sono stati corretti. Un numero elevato di vulnerabilità di per sé può indicare la popolarità del progetto piuttosto che pratiche di sviluppo scadenti. Tuttavia, l’elemento veramente importante sono i tipi di difetti e il modo in cui gli sviluppatori hanno risposto.

Dipendenze e supply chain

Quasi tutti i progetti OSS si basano su componenti open source di terze parti, che spesso non sono documentati. Questi componenti vengono aggiornati secondo le proprie pianificazioni e possono contenere bug, vulnerabilità e persino codice dannoso. La domanda chiave in questo caso è la velocità con cui gli aggiornamenti dei componenti con patch si fanno strada nel progetto in esame.

Per valutare questo, sono necessari gli strumenti SBOM (Software Bill of Materials) o SCA (Software Composition Analysis). Le soluzioni open source disponibili come OWASP Dependency-Check o Syft possono creare la struttura delle dipendenze di un progetto, ma in genere sono progettate per progetti già in esecuzione, distribuiti nei propri archivi o nelle immagini contenitore. Pertanto, è consigliabile eseguire un approfondimento dell’analisi delle dipendenze su un prodotto che ha già superato la valutazione preliminare ed è un serio contendente per un posto nell’infrastruttura.

Esamina l’elenco delle dipendenze in modo approfondito per determinare se provengono da archivi attendibili e controllati, se sono popolari e se dispongono di firme digitali. In sostanza, state valutando i rischi di un’eventuale compromissione.

Sebbene in teoria sia possibile verificare manualmente la presenza di vulnerabilità nelle dipendenze, se un progetto OSS è già distribuito in un ambiente di test, è molto più semplice utilizzare strumenti come Grype.

Un’enorme sfida nascosta è il monitoraggio degli aggiornamenti. In teoria, ogni aggiornamento delle dipendenze per un progetto deve essere ricontrollato. In pratica, ciò è possibile solo con scanner automatici; altri approcci sono semplicemente troppo costosi.

Se un progetto utilizza dipendenze obsolete e in genere non è l’ideale dal punto di vista della cybersecurity, è ovviamente meglio cercare un’alternativa. Ma cosa succede se l’azienda insiste per una soluzione specifica a causa delle sue funzionalità principali? La risposta è sempre la stessa: condurre un’analisi dei rischi più approfondita, sviluppare controlli compensativi e, soprattutto, allocare risorse significative per la manutenzione continua. Le risorse interne spesso sono insufficienti, quindi è consigliabile valutare fin dall’inizio le opzioni per un supporto tecnico professionale per un prodotto specifico.

Conformità ai requisiti interni e normativi

Se i criteri normativi applicabili all’azienda riguardano il software scelto e i dati in esso contenuti, sviluppa immediatamente un piano per i controlli di conformità. Le applicazioni open source di livello aziendale di grandi dimensioni a volte vengono fornite con documentazione di supporto che può semplificare determinati tipi di controlli. In caso contrario, sarà necessario sviluppare tutto da soli, il che significa ancora una volta allocare molto tempo e risorse.

Quasi tutti i software in ogni settore richiederanno un controllo di conformità delle licenze. Alcuni componenti e applicazioni open source sono distribuiti con licenze restrittive, come AGPL, che limitano il modo in cui è possibile distribuire e utilizzare il software. Grazie all’analisi SBOM/SCA è possibile eseguire l’inventario di tutte le licenze per il software e le relative dipendenze, quindi verifica che il caso d’uso non violi nessuna di esse. Questi processi possono essere in gran parte automatizzati con strumenti specializzati come OSS Review Toolkit, ma l’automazione richiederà criteri chiari e l’impegno del team di sviluppo.

Costi di supporto

Dopo aver analizzato tutti questi aspetti, si dovrebbe avere un quadro chiaro che consente di confrontare diversi approcci al supporto per le applicazioni. Per il supporto da parte di un team interno, sarà necessario allocare ore di specialisti pertinenti. Se il team non dispone delle competenze necessarie, bisognerà assumere qualcuno. I responsabili principali del supporto e della sicurezza OSS avranno inoltre bisogno di tempo e un budget per uno sviluppo professionale continuo e costante.

Se le risorse del team interno sono insufficienti per l’assistenza (a causa della carenza di personale o competenze), esistono almeno due tipi di assistenza tecnica professionale in outsourcing: aziende come Red Hat, specializzate in operazioni sulle applicazioni, e provider di hosting gestito, per applicazioni specifiche (Kube Clusters, MongoDB Atlas e simili).

Al di là di tempo e competenze, il costo e la complessità del supporto tecnico sono influenzati anche dalla disponibilità generale dell’organizzazione a un’adozione diffusa dell’open source:

• Il team addetto alla cybersecurity dispone di scanner delle vulnerabilità e strumenti di gestione dei rischi adatti all’OSS?
• Gli strumenti di monitoraggio e tracciamento delle risorse IT supportano progetti e componenti OSS?
• Per i team di sviluppo interni, i processi di scansione di immagini, archivi e altre sorgenti di codice sono inclusi nella pipeline CI/CD? Soluzioni di protezione specializzate, ad esempio Kaspersky Hybrid Cloud Security, può automatizzare questo aspetto.
• L’azienda ha sviluppato un criterio che regola l’utilizzo degli OSS e c’è una chiara comprensione di chi prende le decisioni e chi è responsabile delle questioni operative?

È inoltre fondamentale considerare l’ampio spettro di rischi open source, inclusa l’interruzione improvvisa del progetto, la proliferazione di dipendenze minori e altri rischi della supply chain.