{"id":29774,"date":"2025-06-25T19:20:17","date_gmt":"2025-06-25T17:20:17","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=29774"},"modified":"2025-06-25T19:20:17","modified_gmt":"2025-06-25T17:20:17","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/can-you-support-open-source-preliminary-assessment\/29774\/","title":{"rendered":"Come scegliere le soluzioni open source per la tua azienda"},"content":{"rendered":"

Secondo il rapporto del 2025 sullo stato dell\u2019open source<\/a>, il 96% delle aziende intervistate utilizza applicazioni open source. L\u2019ampia selezione, le opzioni di personalizzazione e l\u2019assenza di costi di licenza sono estremamente interessanti. Tuttavia, pi\u00f9 della met\u00e0 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\u00e0 alle normative e presenza di applicazioni open source EoL (End-of-Life), il che significa che non sono pi\u00f9 supportate. Quindi, come \u00e8 possibile ridurre al minimo la probabilit\u00e0 di questi problemi e cosa bisognerebbe cercare quando si seleziona il software open source (OSS) per l\u2019implementazione?<\/p>\n

Aggiornamenti e patch<\/h2>\n

Dato che l\u2019aggiornamento tempestivo dell\u2019OSS \u00e8 il problema pi\u00f9 diffuso, \u00e8 opportuno esaminare molto attentamente i potenziali candidati all\u2019adozione di OSS da questo punto di vista. \u00c8 facile controllare la frequenza e l\u2019ambito degli aggiornamenti, nonch\u00e9 il relativo contenuto, direttamente nell\u2019archivio pubblico dell\u2019applicazione. \u00c8 opportuno prestare attenzione a quanto sono ben documentati gli aggiornamenti; che tipo di problemi risolvono; quali nuove funzionalit\u00e0 aggiungono; la frequenza con cui vengono rilasciate le correzioni secondarie pochi giorni o settimane dopo una versione principale; e la velocit\u00e0 con cui vengono chiuse le richieste relative ai bug.<\/p>\n

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

Presta particolare attenzione agli aggiornamenti relativi alla sicurezza. Vengono rilasciati separatamente o sono inclusi negli aggiornamenti delle funzionalit\u00e0? In genere, gli sviluppatori scelgono quest\u2019ultima via. In tal caso, \u00e8 necessario comprendere da quanto tempo gli aggiornamenti della protezione potrebbero essere in attesa del rilascio.<\/p>\n

Valuta inoltre la complessit\u00e0 del processo di installazione degli aggiornamenti. La documentazione e il supporto ufficiali possono essere un punto di partenza, ma non sono sufficienti. \u00c8 probabile che un\u2019analisi approfondita del feedback della community di utenti sia pi\u00f9 utile in questo caso.<\/p>\n

Tutto ci\u00f2 consente di comprendere lo sforzo necessario per la manutenzione del prodotto. Sar\u00e0 necessario allocare risorse interne per il supporto. Non \u00e8 sufficiente assegnare semplicemente la responsabilit\u00e0; per queste attivit\u00e0 e per quelle correlate saranno richieste ore di lavoro dedicate.<\/p>\n

Raccomandazioni<\/h2>\n

Per prevedere con precisione la frequenza con cui si dovranno affrontare problemi di cybersecurity, \u00e8 meglio valutare fin dall\u2019inizio la cultura tecnica e l\u2019igiene della cybersecurity del prodotto. Sebbene questa operazione possa richiedere molto lavoro, \u00e8 possibile utilizzare strumenti automatizzati per eseguire un\u2019analisi iniziale di alto livello.<\/p>\n

Per prodotti e pacchetti popolari, un buon approccio consiste nel controllare i risultati gi\u00e0 esistenti della valutazione euristica da strumenti come OpenSSF Scorecard<\/a>. Fornisce una vasta gamma di dati sull\u2019igiene della cybersecurity, che vanno dal numero di vulnerabilit\u00e0 senza patch e dalla presenza di criteri di sicurezza all\u2019utilizzo di fuzzing e pinning delle dipendenze.<\/p>\n

Esamina inoltre i database delle vulnerabilit\u00e0 pubblici come gli avvisi di NVD<\/a> e GitHub<\/a> per comprendere quanti difetti sono stati scoperti nel progetto, la relativa criticit\u00e0 e la velocit\u00e0 con cui sono stati corretti. Un numero elevato di vulnerabilit\u00e0 di per s\u00e9 pu\u00f2 indicare la popolarit\u00e0 del progetto piuttosto che pratiche di sviluppo scadenti. Tuttavia, l\u2019elemento veramente importante sono i tipi di difetti e il modo in cui gli sviluppatori hanno risposto.<\/p>\n

Dipendenze e supply chain<\/h2>\n

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\u00e0 e persino codice dannoso. La domanda chiave in questo caso \u00e8 la velocit\u00e0 con cui gli aggiornamenti dei componenti con patch si fanno strada nel progetto in esame.<\/p>\n

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<\/a> o Syft<\/a> possono creare la struttura delle dipendenze di un progetto, ma in genere sono progettate per progetti gi\u00e0 in esecuzione, distribuiti nei propri archivi o nelle immagini contenitore. Pertanto, \u00e8 consigliabile eseguire un approfondimento dell\u2019analisi delle dipendenze su un prodotto che ha gi\u00e0 superato la valutazione preliminare ed \u00e8 un serio contendente per un posto nell\u2019infrastruttura.<\/p>\n

Esamina l\u2019elenco 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\u2019eventuale compromissione.<\/p>\n

Sebbene in teoria sia possibile verificare manualmente la presenza di vulnerabilit\u00e0 nelle dipendenze, se un progetto OSS \u00e8 gi\u00e0 distribuito in un ambiente di test, \u00e8 molto pi\u00f9 semplice utilizzare strumenti come Grype<\/a>.<\/p>\n

Un\u2019enorme sfida nascosta \u00e8 il monitoraggio degli aggiornamenti. In teoria, ogni aggiornamento delle dipendenze per un progetto deve essere ricontrollato. In pratica, ci\u00f2 \u00e8 possibile solo con scanner automatici; altri approcci sono semplicemente troppo costosi.<\/p>\n

Se un progetto utilizza dipendenze obsolete e in genere non \u00e8 l\u2019ideale dal punto di vista della cybersecurity, \u00e8 ovviamente meglio cercare un\u2019alternativa. Ma cosa succede se l\u2019azienda insiste per una soluzione specifica a causa delle sue funzionalit\u00e0 principali? La risposta \u00e8 sempre la stessa: condurre un\u2019analisi dei rischi pi\u00f9 approfondita, sviluppare controlli compensativi e, soprattutto, allocare risorse significative per la manutenzione continua. Le risorse interne spesso sono insufficienti, quindi \u00e8 consigliabile valutare fin dall\u2019inizio le opzioni per un supporto tecnico professionale per un prodotto specifico.<\/p>\n

Conformit\u00e0 ai requisiti interni e normativi<\/h2>\n

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

Quasi tutti i software in ogni settore richiederanno un controllo di conformit\u00e0 delle licenze. Alcuni componenti e applicazioni open source sono distribuiti con licenze restrittive, come AGPL<\/a>, che limitano il modo in cui \u00e8 possibile distribuire e utilizzare il software. Grazie all\u2019analisi SBOM\/SCA \u00e8 possibile eseguire l\u2019inventario di tutte le licenze per il software e le relative dipendenze, quindi verifica che il caso d\u2019uso non violi nessuna di esse. Questi processi possono essere in gran parte automatizzati con strumenti specializzati come OSS Review Toolkit<\/a>, ma l\u2019automazione richieder\u00e0 criteri chiari e l\u2019impegno del team di sviluppo.<\/p>\n

Costi di supporto<\/h2>\n

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\u00e0 necessario allocare ore di specialisti pertinenti. Se il team non dispone delle competenze necessarie, bisogner\u00e0 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.<\/p>\n

Se le risorse del team interno sono insufficienti per l\u2019assistenza (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).<\/p>\n

Al di l\u00e0 di tempo e competenze, il costo e la complessit\u00e0 del supporto tecnico sono influenzati anche dalla disponibilit\u00e0 generale dell\u2019organizzazione a un\u2019adozione diffusa dell\u2019open source:<\/p>\n