Affrontare i rischi per la sicurezza nelle librerie di terze parti

Usare librerie di terzi nel software può essere utile, ma comporta anche dei rischi. Un rischio principale è che queste librerie possono far entrare codice dannoso nelle applicazioni senza che lo sviluppatore ne sia a conoscenza. La maggior parte degli sforzi nel settore si concentra sulle librerie più popolari, ma ci sono poche informazioni su altre librerie. Questo articolo vuole mettere in evidenza la Sicurezza di tutte le librerie, non solo quelle più usate.

#L'uso diffuso delle librerie

Oggi molte applicazioni dipendono pesantemente da librerie di terzi. Ad esempio, l'ecosistema NPM, usato per JavaScript, ha oltre 2,42 milioni di librerie. Queste librerie spesso si connettono e si basano l'una sull'altra. Purtroppo, questa profonda dipendenza può portare a problemi. Ad esempio, una vulnerabilità chiamata Log4Shell ha colpito molti sistemi, comprese grandi aziende.

Negli ultimi anni, il numero di attacchi informatici rivolti alle catene di approvvigionamento del software open-source è aumentato drasticamente, con un incremento del 650% nel 2021. Questi attacchi spesso prendono di mira librerie popolari. Per combattere ciò, piattaforme come GitHub hanno intensificato le loro misure di sicurezza, soprattutto per le librerie che vengono scaricate frequentemente.

#Aggiornamenti di dipendenze non sicuri

Quando gli Sviluppatori aggiornano le dipendenze delle librerie, potrebbero introdurre involontariamente cambiamenti non sicuri. Aggiornamenti di dipendenze non sicuri significano che c'è un rischio durante l'esecuzione, che può portare a problemi di sicurezza. Pratiche non sicure, come determinati comandi di codice, possono causare problemi se non gestite correttamente.

Abbiamo esaminato un ampio campione di pull request (PR) legate a queste librerie per raccogliere prove di aggiornamenti non sicuri. I nostri risultati mostrano che gli aggiornamenti non sicuri sono comuni, non solo nelle librerie più conosciute, ma anche in molte altre.

#L'importanza dei livelli di librerie

Per analizzare meglio gli aggiornamenti non sicuri, le librerie possono essere suddivise in base a quanto spesso vengono utilizzate, o i loro "livelli." Il primo livello comprende le librerie più usate. Il secondo livello include librerie che sono ancora popolari ma non così critiche. L'ultimo livello ha le librerie meno usate.

Nella nostra analisi, abbiamo esaminato un numero significativo di PR attraverso questi livelli. Abbiamo trovato che gli aggiornamenti di dipendenze non sicuri si trovano non solo nel primo livello, ma anche negli altri livelli. Ad esempio, l'81% delle librerie in un livello aveva almeno un aggiornamento non sicuro.

#Frequenza degli aggiornamenti non sicuri

Abbiamo raccolto dati da varie librerie per controllare la frequenza degli aggiornamenti non sicuri. Dopo aver filtrato le PR, abbiamo notato che gli aggiornamenti non sicuri includevano spesso comandi di codice specifici che possono essere rischiosi. Questi aggiornamenti possono essere segnalati sulla base di determinate caratteristiche che abbiamo identificato in precedenza.

I risultati hanno mostrato che gli aggiornamenti non sicuri erano comuni in diversi livelli di librerie. Ad esempio, molte librerie dal primo all'ultimo livello avevano aggiornamenti non sicuri.

#Revisione dei risultati degli aggiornamenti

Una volta che questi aggiornamenti sono stati sottoposti a revisione, abbiamo notato i risultati di queste PR. Le PR possono avere tre possibili esiti: possono essere unite al codice, chiuse senza unione, o ancora in fase di revisione. Curiosamente, la maggior parte degli aggiornamenti non sicuri in tutti i livelli è stata accettata e unita.

Questo solleva una preoccupazione poiché suggerisce che le librerie, anche quelle su cui non si fa molto affidamento, stanno accettando aggiornamenti potenzialmente non sicuri.

#Analisi dei cambiamenti di codice

Per comprendere meglio gli aggiornamenti non sicuri, abbiamo esaminato i cambiamenti apportati nelle PR. Abbiamo guardato sia i cambiamenti di testo che i tipi di file interessati. Questa analisi ci ha aiutato a vedere quali tipi di cambiamenti venivano effettuati.

I nostri risultati indicano che le PR che segnalavano pratiche non sicure non erano sempre maliziose. Invece, alcuni aggiornamenti erano semplicemente cambiamenti di routine che non sembravano dannosi a prima vista.

#Domande di ricerca per una futura sicurezza

Data la diffusione degli aggiornamenti non sicuri, è cruciale per la comunità di sviluppo software adottare pratiche più sicure. Per promuovere ciò, proponiamo sei domande di ricerca centrali volte a proteggere contro queste pratiche rischiose.

Una preoccupazione è capire quali alternative più sicure esistono e perché gli sviluppatori potrebbero ancora scegliere metodi non sicuri. Anche se migliori pratiche di codifica possono aiutare, comprendere le ragioni dietro le scelte degli sviluppatori è altrettanto importante.

#Esplorare alternative più sicure

Sebbene esistano opzioni più sicure, gli sviluppatori potrebbero non sempre preferirle a causa di varie limitazioni. Ad esempio, una pratica comune è usare la funzione require(), che può introdurre rischi. Un'alternativa più sicura è utilizzare la funzione import(), ma ha delle restrizioni, limitando quando può essere usata.

Gli sviluppatori devono essere consapevoli dei rischi associati a funzioni come eval(), che possono eseguire codice dannoso. Anche se esistono alternative, come JSON.parse(), non tutti gli sviluppatori potrebbero essere convinti di usarle.

#Aggiungere strati di sicurezza

Un altro modo per migliorare la sicurezza è utilizzare misure di sicurezza, come gli header di sicurezza HTTP. Queste misure possono aiutare a prevenire minacce comuni. Inoltre, gli sviluppatori possono limitare l'accesso a specifici file e directory, assicurando che solo determinati componenti possano essere letti o modificati.

La nostra ricerca mira a comprendere meglio come pratiche più sicure possono essere attuate in tutti i livelli di librerie per promuovere un ambiente software sicuro.

#Comprendere la fiducia degli sviluppatori

Un altro focus principale è capire perché gli sviluppatori si fidano di determinati aggiornamenti, anche quando possono essere non sicuri. Esplorare il ragionamento degli sviluppatori può fare luce su come queste pratiche non sicure siano ancora accettate nella comunità.

Questa analisi può rivelare differenze nelle abitudini di codifica tra i vari livelli di librerie e aiutare a stabilire cosa costituisce un aggiornamento affidabile. Una comprensione più profonda di queste pratiche è essenziale per migliorare le misure di sicurezza.

#Il ruolo dell'automazione

Automatizzare alcuni processi può aiutare a creare codice più sicuro. L'accettazione di aggiornamenti non sicuri suggerisce che gli sviluppatori potrebbero non essere pienamente consapevoli dei loro rischi. Strumenti che suggeriscono automaticamente pratiche di codifica più sicure potrebbero svolgere un ruolo significativo nel ridurre gli aggiornamenti non sicuri.

Introdurre automazione consente agli sviluppatori di risparmiare tempo mentre garantiscono un ambiente di codifica più sicuro.

#L'importanza degli sforzi comunitari

Gli sforzi collaborativi all'interno della comunità software possono portare a misure di sicurezza migliorate. Mirare a pratiche non sicure in modo globale, piuttosto che concentrarsi solo sulle librerie popolari, può risultare in un ecosistema complessivamente più sicuro.

Allineando le pratiche tra tutti i livelli, gli sviluppatori possono lavorare insieme per proteggere efficacemente la catena di approvvigionamento del software.

#Conclusione

I risultati evidenziano che le pratiche non sicure non sono confinate solo alle librerie popolari ma sono presenti nell'intero ecosistema software. Pertanto, dovrebbe essere posta maggiore attenzione per garantire che tutte le librerie mantengano pratiche di codifica sicure.

Comprendendo le problematiche relative agli aggiornamenti di dipendenze non sicuri e promuovendo una cultura di sicurezza, gli sviluppatori possono lavorare per un ambiente software open-source più robusto e sicuro.