Le librerie di terze parti sono essenziali per accelerare il ciclo di vita dello sviluppo del software. Invece di codificare da zero, gli sviluppatori spesso integrano librerie open-source per vari scopi, sia per motivi di economicità, sia per mancanza di risorse o per una maggiore flessibilità. Repository come Maven Central e PyPI, insieme a strumenti di gestione delle dipendenze, semplificano questo processo e aumentano la produttività. Tuttavia, questo affidamento comporta anche potenziali rischi per la sicurezza.
La gestione delle dipendenze open source di un progetto può porre delle sfide, tra cui le dipendenze annidate (una o più dipendenze all'interno di una dipendenza) e le competenze limitate nella gestione delle dipendenze. L'integrazione di librerie esterne amplia la superficie di attacco e aumenta i rischi per la sicurezza. La scoperta di una vulnerabilità in una libreria può compromettere tutto il software che dipende da quel componente. Pertanto, è essenziale utilizzare strumenti di scansione delle dipendenze per identificare e risolvere le vulnerabilità note provenienti da dipendenze di terze parti.
Riutilizzo Software e adozione della dipendenza
Man mano che gli ecosistemi di distribuzione diventano più accessibili, gli sviluppatori scelgono di riutilizzare il software esistente per accelerare lo sviluppo di software complessi. Tuttavia, questa convenienza può introdurre problemi di sicurezza inaspettati se non viene gestita con attenzione. Questi programmi software esistenti sono distribuiti principalmente via Internet sotto forma di pacchetti, ovvero archivi contenenti versioni di release note come librerie, insieme a metadati che specificano versione, autore, licenza, riferimenti e altre informazioni rilevanti. Il software di packaging semplifica i processi di distribuzione e di controllo delle versioni.
Gli sviluppatori spesso condividono pubblicamente il loro codice sotto licenze open-source, consentendo la revisione del codice, la collaborazione della comunità e una facile integrazione. Ogni sviluppatore può riutilizzare, modificare o contribuire alla base di codice. I progetti variano molto in termini di qualità, manutenzione e supporto. Gli autori rilasciano questi pacchetti per renderli più facilmente accessibili, ma il supporto e la responsabilità dipendono dalla licenza.
Una volta che un pacchetto è referenziato in un altro progetto, diventa una dipendenza del progetto, che rappresenta un riferimento esterno al pacchetto. Le dipendenze creano relazioni unidirezionali tra pacchetti software, in cui uno si basa su un altro per il corretto funzionamento. Gli sviluppatori includono le dipendenze nelle loro applicazioni, risolvendole in fase di compilazione e recuperando quelle necessarie.
La catena di fornitura si riferisce a tutti i fornitori esterni coinvolti nel processo, in particolare a quelli che forniscono le dipendenze del software. Negli ultimi anni la gestione della catena di fornitura ha acquisito importanza nello sviluppo del software e le aziende hanno stabilito politiche che comprendono i requisiti dei fornitori, i documenti legali e i contratti per garantire la conformità prima di accettare un fornitore.
Gestione delle dipendenze
La gestione delle dipendenze può diventare rapidamente opprimente, portando al cosiddetto "inferno delle dipendenze". Le applicazioni moderne possono avere centinaia o addirittura migliaia di dipendenze dirette, rendendo difficile il monitoraggio delle vulnerabilità. Ecco alcuni scenari in cui la gestione di grandi volumi di dipendenze diventa un problema.
- Mancanza di revisione del codice: Nonostante la trasparenza dell'open-source, a volte i team saltano la revisione del codice, generando un falso senso di sicurezza.
- Fiducia implicita: Gli sviluppatori spesso includono le dipendenze senza verificare a fondo gli autori, affidandosi esclusivamente all'inclusione nel repository.
- Uso estensivo delle dipendenze: Gli sviluppatori fanno spesso molto affidamento sui pacchetti, anche se è necessaria solo una frazione delle loro funzionalità, con il risultato di gonfiare le dipendenze.
- Modifiche di rottura: L'aggiornamento dei pacchetti può essere complesso e può introdurre modifiche di rottura, con conseguenti esitazioni e pacchetti obsoleti.
- Problemi di responsabilità: Gli standard di manutenzione e supporto dell'open-source non sono all'altezza di quelli richiesti per il software commerciale, il che porta a controversie e ad aspettative irrealistiche da parte degli sviluppatori del progetto, con il potenziale risultato di pacchetti insicuri.
L'aumento degli attacchi che prendono di mira le dipendenze di terze parti ha sollevato preoccupazioni sulla sicurezza del software. Episodi di alto profilo come la vulnerabilità Log4Shell nel 2021 o la backdoor XZ Utils nel marzo 2024, che ha colpito migliaia di pacchetti Maven, hanno sottolineato l'impatto diffuso di tali vulnerabilità. Nello stesso anno, la scoperta di malware in un popolare pacchetto NPM ua-parser-jswas ha evidenziato i rischi associati all'uso di librerie di terze parti negli stack di applicazioni.
Un altro attacco degno di nota nel gennaio 2024 è MavenGate, un nuovo metodo di attacco alla catena di fornitura del software, che dirotta le dipendenze tramite librerie abbandonate. Uno sfruttamento riuscito di queste carenze potrebbe consentire ad attori malintenzionati di trovare artefatti vulnerabili nelle dipendenze e iniettare codice dannoso nell'applicazione e, peggio ancora, compromettere il processo di compilazione attraverso un plugin dannoso.
Con l'aumento dell'uso di librerie open-source, la comprensione e la mitigazione di questi rischi diventa fondamentale. Questo spinge a indagare ulteriormente sulla prevalenza, sui tipi e sulla persistenza delle vulnerabilità nelle librerie open-source, nonché sulla loro relazione con gli attributi e i commit del progetto.
Protezione delle dipendenze con OPSWAT SBOM
In risposta agli attacchi alla catena di fornitura, gli Stati Uniti d'America hanno approvato nel maggio 2021 l'"Executive Order on Improving the Nation's Cybersecurity", che definisce i passi per migliorare le politiche della catena di fornitura. Uno dei requisiti principali è quello di fornire un SBOM per ogni prodotto.
OPSWAT Software Bill of Materials (SBOM) è in continua evoluzione per soddisfare le crescenti esigenze di sviluppo del software in un ambiente sicuro. Una delle caratteristiche principali di OPSWAT SBOM è la scansione delle dipendenze. Questa funzione è stata progettata per migliorare la visibilità della vostra base di codice, identificando le vulnerabilità nelle dipendenze su cui si basano i vostri progetti.
Scansione delle dipendenze dei pacchetti
OPSWAT SBOM rileva automaticamente le vulnerabilità di sicurezza nelle dipendenze del software durante lo sviluppo e il test. Ad esempio, SBOM consente ai team di sapere se l'applicazione utilizza una libreria open-source nota per essere vulnerabile. I team possono quindi intervenire per proteggere l'applicazione.
Controllare le dipendenze con Python
Container Scansione di immagini
OPSWAT SBOM esamina tutti i livelli dell'immagine di un container per identificare vulnerabilità o minacce, compresi i pacchetti del sistema operativo (OS) e le librerie software dipendenti utilizzate dall'applicazione. Questo approccio proattivo consente di rilevare e risolvere potenziali problemi prima che si trasformino in problemi gravi.
Controllare la dipendenza da Alpine
Gli sviluppatori e i team di sicurezza traggono vantaggio dalla comprensione dei tipi comuni, della prevalenza e della persistenza delle vulnerabilità di dipendenza, consentendo loro di valutare la gravità e di esplorare le strategie di rimedio.
SBOM analizza le dipendenze del progetto alla ricerca di vulnerabilità note. Al rilevamento, SBOM fornisce informazioni dettagliate, tra cui i livelli di gravità, le descrizioni delle vulnerabilità e le correzioni disponibili.
È possibile esportare un rapporto dettagliato per consentire ai team di tenerne traccia:
- Numero totale di dipendenze analizzate
- Numero totale di vulnerabilità trovate in tutte le dipendenze
- Una gamma di versioni scansionate
- CVE note
- Numero totale di vulnerabilità di gravità critica, alta, media e bassa
OPSWAT SBOM raccomanda ai team di sicurezza di aggiornare tutti i pacchetti vulnerabili alle versioni più recenti con le correzioni delle vulnerabilità. Ciò consente ai team di affrontare la vulnerabilità dei manutentori dei pacchetti o di rimuovere i pacchetti dall'albero delle dipendenze. Questo approccio proattivo consente ai team di affrontare i potenziali rischi per la sicurezza prima che diventino un problema, migliorando in modo significativo la sicurezza e l'integrità dei progetti software. Inoltre, OPSWAT SBOM aiuta le organizzazioni a mantenere la conformità e la sicurezza nella catena di fornitura del software. Si raccomanda vivamente ai team di:
Mappare le dipendenze
Sfruttare gli strumenti per identificare le dipendenze presenti nell'ambiente e le loro relazioni.
Eliminare le dipendenze non necessarie
Eliminare le dipendenze non necessarie o non indispensabili per ridurre la superficie di attacco.
Usare repository consolidati
Assicurarsi che le dipendenze siano ottenute da fonti affidabili.
Eseguire una scansione di tutte le dipendenze
Prima di utilizzare le dipendenze in qualsiasi software, eseguite una scansione per individuare eventuali problemi di sicurezza o di qualità.
Pensieri conclusivi
Utilizzando strumenti di scansione delle dipendenze come OPSWAT SBOM, è possibile identificare e risolvere in modo proattivo le vulnerabilità nelle dipendenze del progetto, riducendo i potenziali rischi per la sicurezza prima che possano essere sfruttati. Sfruttate la potenza della scansione delle dipendenze e degli SBOM per creare applicazioni software sicure, conformi e resistenti.
