Popolare per essere economico e pronto all'uso, il software open source (OSS) si è guadagnato un posto negli stack tecnologici aziendali, dalle PMI alle più grandi aziende.
Man mano che sempre più aziende aumentano la propria dipendenza dal software open source e gli attori delle minacce mostrano una maggiore attenzione agli attacchi della supply chain, i leader della sicurezza si stanno impegnando per capire meglio quali possono essere i rischi per la sicurezza correlati al loro utilizzo.
Questo articolo di SentinelOne fornisce linee guida su come le organizzazioni che scelgono di utilizzare questi strumenti possono farlo in modo efficace e sicuro.
Perché il Software Open Source è Ovunque
Quando le organizzazioni investono nel proprio stack tecnologico di sicurezza, le soluzioni open source sono una scelta in aumento, in quanto forniscono scalabilità e convenienza su misura per le esigenze uniche dell’azienda.
I risultati dell'edizione 2023 del report “Open Source Security and Risk Analysis” (OSSRA) hanno confermato la capacità di resistenza dell’utilizzo dell'open source nelle industrie di oggi. Degli intervistati, il 96% delle codebase scansionate conteneva open source e il 76% del codice nelle codebase era open source.
Le risorse open source sono anche ampiamente adottate perché altamente personalizzabili, consentendo agli utenti di adattarle alle loro esigenze specifiche.
Tale flessibilità può essere particolarmente utile per le aziende che costruiscono una strategia di sicurezza informatica, in cui le organizzazioni spesso devono adattare i gli strumenti per affrontare le minacce specifiche sulla base del proprio settore, dei requisiti legali e della base clienti.
Oltre ad essere convenienti ed estremamente accessibili, le risorse open source sono diventate popolari anche per la loro capacità di promuovere l'innovazione nei team di sviluppo poiché nuove funzionalità sono aggiunte regolarmente.
I Rischi Dietro l'Uso di Software Open Source (OSS)
Man mano che sempre più organizzazioni si affidano a framework, librerie e strumenti open source nelle loro operazioni quotidiane, possono facilmente diventare pietre miliari nelle comunicazioni aziendali, nelle funzionalità software, nelle interazioni degli utenti e altro ancora.
Poiché l'open source è così accessibile per le aziende di tutte le dimensioni e settori, i ricercatori hanno segnalato un aumento del 633% su base annua degli attacchi informatici diretti ai repository di software open source.
L’evidenza suggerisce che gli attori delle minacce si concentrano sui picchi di open source. L'attacco SolarWinds del 2020, ad esempio, continua a fare da catalizzatore per i rapidi cambiamenti nel modo in cui le organizzazioni moderne costruiscono la propria sicurezza contro le minacce di terze parti.
Appena un anno dopo SolarWinds, Log4j ha scosso la comunità digitale quando gli hacker hanno iniziato a sfruttare una vulnerabilità nel popolare pacchetto di registrazione open source. Alla fine dello scorso anno, gli attori delle minacce hanno bombardato i repository open source NuGet, PyPI e npm con oltre 144.000 pacchetti dannosi.
Di particolare interesse, il report OSSRA ha rilevato che l'89% delle basi di codice scansionate nel sondaggio conteneva codice open source non aggiornato da più di quattro anni.
Prima di distribuire framework, software e strumenti open source, è essenziale che i team DevOps e SecOps considerino i rischi che possono portare all'organizzazione. I rischi per la sicurezza open source includono:
- Vulnerabilità e accesso libero - Fedele al suo nome, il codice open source è accessibile a chiunque. Nelle mani di malintenzionati o aggressori opportunisti, il codice open source può essere manipolato e sfruttato in campagne dannose.
- Mancanza di verifica e codice immaturo - Il software open source non garantisce che sia stato adeguatamente testato da esperti qualificati. Durante il suo sviluppo, potrebbe non aver superato il livello di garanzia della qualità necessario per garantirne l'affidabilità o la sicurezza.
- Poco o nessun supporto dedicato o manutenzione – Alcuni software open source non hanno un team di supporto dedicato, il che significa che le patch di sicurezza e gli aggiornamenti potrebbero essere pochi o del tutto assenti. Senza aggiornamenti regolari, correzioni di bug e documentazione, gli attori delle minacce possono facilmente sfruttare le vulnerabilità esistenti per ottenere l'accesso non autorizzato a un sistema.
- Effetto a valle degli attacchi alla supply chain - Quando esistono vulnerabilità nel codice di terze parti, le organizzazioni corrono improvvisamente il rischio di introdurre rischi nei propri ambienti, che poi si ripercuotono sui loro clienti e così via. Dato quanto sono popolari e ampiamente utilizzati molti repository open source, il governo federale degli Stati Uniti, ad esempio, ha rilasciato una serie di direttive e linee guida su come proteggere le pratiche di sviluppo del software.
Come Implementare un Tool Open Source in Maniera Sicura
Mentre il software open source è una soluzione ottimale per le PMI per costruire il proprio stack di strumenti di sicurezza, coloro che peccano per eccesso di cautela dovrebbero considerare la sicurezza e la sostenibilità degli strumenti open source prima di utilizzarli nelle loro operazioni quotidiane.
I team di sicurezza svolgono un ruolo fondamentale nell'assicurarsi che il software open source sia adatto a un uso a lungo termine seguendo le best practice riportate di seguito.
Comprendere le Dipendenze e i Componenti
Con OSS ormai comune negli stack software aziendali, i team di sicurezza, IT e SecOps sono gravati dalla responsabilità di indagare sul software e assicurarsi che sia sicuro da implementare. Questa indagine inizia con la gestione dei rischi relativi a dipendenze e componenti.
Le aziende che utilizzano librerie open source devono essere consapevoli di tutte le dipendenze associate a tali librerie. Le dipendenze sono librerie che il codice di un'azienda chiama direttamente. Le dipendenze transitive o indirette aggiungono un altro livello: il codice delle aziende chiama una libreria a cui sono collegate le dipendenze, il che significa che esiste una dipendenza di una dipendenza.
Tali dipendenze annidate possono avere diversi livelli in framework grandi o complessi. Le vulnerabilità possono essere esposte a qualsiasi livello e gestirle può diventare complesso. Gli sviluppatori e i team di sicurezza devono comprendere ogni livello di dipendenza e in che modo una vulnerabilità di sicurezza influisce sui progetti di cui fanno parte.
Scanner come lo strumento di controllo delle dipendenze OWASP possono essere utili per esporre l'utilizzo dell'open source da parte di un'azienda.
Predisporre Policy Chiare sull’Utilizzo
Per la sicurezza dall'alto verso il basso, i leader aziendali sono fondamentali nel collaborare con SecOps, i team IT e il team di sicurezza dell'organizzazione per creare policy e regole rigorose quando si tratta di utilizzare le dipendenze.
Gli sviluppatori hanno bisogno di formazione sui rischi associati all'utilizzo di componenti open source e dovrebbero avere una conoscenza approfondita delle politiche della loro azienda sui processi di revisione, test e approvazione.
Testare la sicurezza dei componenti open source è il modo più efficace per proteggere la sicurezza delle applicazioni e delle risorse esistenti. Ciò richiede un programma o un processo prestabilito per il test e l'analisi dei componenti open source, simile alle revisioni del codice proprietario.
Traccia e Aggiorna Tutti i Componenti Utilizzati
Nella sicurezza informatica, si dice spesso che la visibilità è la chiave della difesa. Le risorse open source consentono agli utenti di vedere e modificare il codice sorgente, il che fornisce trasparenza e aiuta a garantire che il software faccia ciò che afferma di fare.
Sebbene, in teoria, ciò possa aiutare a identificare difetti di sicurezza o vulnerabilità nel codice, in pratica gran parte dell'OSS è gestito da volontari non pagati che potrebbero avere poco tempo, esperienza o inclinazione a condurre regolari revisioni della sicurezza. L'onere ricade sull'utente per garantire che il codice utilizzato in un progetto sia verificato come affidabile.
Gli strumenti di analisi della composizione del software (SCA) possono aiutare i team SecOps ad analizzare il software. La creazione di un inventario centrale e organizzato di tutti i componenti open source in uso, idealmente con una distinta base (BOM) dettagliata per ogni pezzo di OSS, consente ai team di sicurezza di monitorare, accedere e proteggere meglio l'ambiente.
Gli inventari devono essere tenuti aggiornati e includere tutti i progetti open source correnti, le dipendenze utilizzate regolarmente, le versioni in uso e le posizioni di download. Gli inventari sono fondamentali per proteggere sia il codice che le risorse.
Per garantire un utilizzo sicuro e sostenibile, è importante selezionare i componenti open source che dispongono di una comunità attiva di sviluppo o supporto. Quando i problemi di sicurezza e i bug interessano i componenti, la comunità degli sviluppatori open source spesso identifica e segnala dettagli preziosi e correzioni che dovrebbero essere applicate immediatamente.
Lasciare i componenti senza patch aumenta notevolmente il rischio di sfruttamento. Allo stesso modo, maggiore è il numero di librerie non supportate o scadute che un'azienda decide di utilizzare, più difficile sarà per i team di sicurezza tenere traccia di tutte le dipendenze, le correzioni in arrivo e le nuove vulnerabilità identificate.
Comprendi i Rischi dei Repository Privati rispetto a Quelli Pubblici
Una volta che una parte di OSS è entrata nello stack software dell'organizzazione come verificata e considerata attendibile dai team SecOps o DevOps, è necessario considerare come quel codice sarà mantenuto e aggiornato.
I repository di gestione dei pacchetti come NPM, PyPi e Crate.io offrono grande comodità ma sono anche obiettivi per attacchi alla supply chain. Per mitigare questo problema, gli sviluppatori possono eseguire il fork delle implementazioni e utilizzare repository privati per aggiornare i componenti software.
Tuttavia, è importante essere consapevoli che anche questi comportano dei rischi: possono verificarsi attacchi di confusione delle dipendenze se i gestori di pacchetti sono configurati per impostazione predefinita su un repository pubblico e gli sviluppatori utilizzano un nome di pacchetto che può essere rivendicato da un utente malintenzionato, come è accaduto nell’attacco PyTorch all'inizio del 2023.
Questo tipo di rischi può essere mitigato seguendo alcune best practice come:
- Assicurarsi che i gestori di pacchetti chiamino repository privati e non siano configurati per impostazione predefinita su un repository pubblico;
- Verificare l'autenticità del pacchetto tramite la firma del codice;
- Controllare e verificare periodicamente il codice di origine esterna.
In Conclusione
La domanda di innovazione aziendale, scalabilità e facilità di utilizzo hanno consentito la varietà e la crescita del software open source. Con sempre più organizzazioni che adottano l'OSS nei loro processi interni e nelle linee di prodotti e servizi, gli attori delle minacce hanno iniziato a puntare sulle vulnerabilità sfruttabili che esistono all'interno del codice e degli strumenti open source.
Per salvaguardare l'uso di queste risorse accessibili e convenienti, le aziende continuano a fare affidamento su piattaforme di sicurezza informatica autonome e basate sull'intelligenza artificiale come SentinelOne per una protezione completa.
Indipendentemente dal fatto che il codice nella tua rete sia open source o proprietario, scopri come Singularity™ XDR di SentinelOne difende la tua azienda da tutte le possibili superfici di attacco.
Invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250. Visita la pagina dedicata sul nostro sito, in alternativa puoi compilare il form sottostante con la tua domanda.
