Dipendenze sicure

  • 5 minuti

Una buona parte del codice presente nelle applicazioni moderne è costituito dalle librerie e dalle dipendenze scelte dallo sviluppatore. È una pratica comune che consente di risparmiare tempo e denaro. Ma c'è un rovescio della medaglia: lo sviluppatore che usa questo codice nel suo progetto ne è infatti interamente responsabile, anche se è stato scritto da altri. Se un ricercatore (o peggio, un pirata informatico) individua una vulnerabilità in una di queste librerie di terze parti, la stessa vulnerabilità sarà probabilmente presente anche nell'app sviluppata con questa libreria.

L'uso di componenti con vulnerabilità note rappresenta un problema enorme nel settore IT. Lo è a tal punto che da diversi anni occupa la nona posizione nella classifica Top 10 OWASP delle peggiori vulnerabilità delle applicazioni Web.

Tenere traccia delle vulnerabilità della sicurezza note

Il nocciolo del problema è sapere quando viene individuata una vulnerabilità. Mantenere aggiornate le librerie e le dipendenze (posizione numero 4 nella Top 10) è sicuramente utile, ma è sempre consigliabile tenere traccia delle vulnerabilità identificate che potrebbero avere un impatto negativo sull'applicazione.

Importante

Quando un sistema ha una vulnerabilità nota, aumentano anche le probabilità che siano disponibili exploit, ossia codice che persone malintenzionate possono usare per attaccare il sistema. Se un exploit viene reso pubblico, è fondamentale che i sistemi interessati vengano aggiornati immediatamente.

Mitre è un'organizzazione no profit che gestisce il Common Vulnerabilities and Exposures (CVE), ossia l'elenco delle vulnerabilità ed esposizioni comuni. Si tratta di un elenco, consultabile pubblicamente, delle vulnerabilità a livello di sicurezza informatica in app, librerie e framework. Se si trova una libreria o un componente nel database CVE, significa che contiene vulnerabilità note.

Quando in un prodotto o un componente viene rilevata una falla nella sicurezza, il problema viene inviato dalla community dedicata alla sicurezza. Ogni problema pubblicato è identificato da un ID e contiene la data dell'individuazione, una descrizione della vulnerabilità e riferimenti a soluzioni alternative pubblicate o istruzioni del fornitore relative al problema.

Come verificare se i componenti di terze parti in uso contengono vulnerabilità

È possibile impostare un'attività giornaliera sul telefono per controllare questo elenco, ma fortunatamente esistono diversi strumenti che consentono di verificare se le dipendenze in uso sono vulnerabili. È possibile eseguire questi strumenti sulla codebase o, meglio ancora, aggiungerli alla pipeline CI/CD per verificare automaticamente la presenza di problemi durante il processo di sviluppo.

È possibile usare allo scopo anche alcuni strumenti sviluppati specificamente per l'analisi di codice statico.

Per altre informazioni sui rischi impliciti nell'uso di componenti vulnerabili, visitare la pagina di OWASP dedicata a questo argomento.

Riepilogo

Quando si usano librerie o altri componenti di terze parti per lo sviluppo della propria applicazione, si accettano anche gli eventuali rischi che possono comportare. Il modo migliore per ridurre questi rischi è assicurarsi di usare solo componenti a cui non siano associate vulnerabilità note.