L’utilizzo di componenti open source e fornite da terze parti, un tempo considerato opzionale, oggi è diventato una best practice, se non addirittura una necessità. Per gli sviluppatori è praticamente impossibile tenere il passo con l’evoluzione del mondo digitale senza incorporare nelle proprie applicazioni frammenti di codice preconfezionato.
In CA Veracode analizziamo ogni anno i dati provenienti dalla nostra piattaforma realizzando il report State of Software Security; anche quest’anno i dati ci portano a lanciare un allarme sulla scarsa sicurezza delle componenti software. Abbiamo scoperto, ad esempio, che nel 2017 l’88% delle applicazioni Java esaminate presentava almeno un componente difettoso.
Cosa ne pensano gli sviluppatori? Qual è il loro atteggiamento rispetto al tema dell’utilizzo di componenti open source e fornite da terze parti? Sono consapevoli dei rischi? Recentemente abbiamo cercato di rispondere a queste domande attraverso un’indagine condotta insieme a Vanson Bourne, che ci ha visto intervistare 400 sviluppatori di applicazioni sulla loro modalità di utilizzo dei componenti.
Gli sviluppatori desiderano utilizzare i componenti open source e di terze parti
Lo studio conferma che l’impiego di questo tipo di componenti è notoriamente diffuso: la stragrande maggioranza degli intervistati (il 93%) si serve di componenti di terze parti e/o open source, e nelle rispettive organizzazioni si utilizzano in media 73 componenti per applicazione.
Il 91% degli sviluppatori intervistati è favorevole all’utilizzo di componenti. Il dato sembrerebbe confermare questa tendenza come una best practice. e la necessità di ricorrere a questo approccio per riuscire a raggiungere la produttività richiesta. I componenti sono, quindi, parte integrante dei processi di sviluppo – una realtà destinata a consolidarsi.
Gli sviluppatori non sono sempre consapevoli dei rischi
Fra gli intervistati che hanno dichiarato di avere una minima dimestichezza con i 10 principali rischi in termini di sicurezza delle applicazioni evidenziati dal OWASP (Open Web Application Security Project), solo il 43% ha affermato di conoscere le raccomandazioni che l’OWASP offre per la prevenzione dell’uso di componenti notoriamente vulnerabili.
Quando giunge il momento di scegliere un nuovo componente open source o di terze parti, i fattori presi più spesso in considerazione sono la funzionalità (62%), le prestazioni (48%) e/o i costi (44%), seguiti dalle vulnerabilità per la sicurezza (42%), a conferma che la sicurezza è sì importante ma non rappresenta la principale priorità.
Il dato non sorprende, sappiamo che gli sviluppatori sono spesso giudicati in base alla velocità di produzione del codice e alla funzionalità del codice prodotto – motivo per cui tendono a considerare meno prioritaria la sicurezza. In effetti, un terzo dei 400 professionisti IT interpellati nel sondaggio dichiara che l’unica metrica per loro veramente rilevante è la funzionalità del codice.
Il tema della sicurezza pare quindi sottovalutato: lo conferma anche uno studio condotto in collaborazione con DevOps.com che ha visto sette sviluppatori su dieci affermare che le loro aziende non offrono una formazione adeguata sul tema della security, e il 76% degli intervistati dichiarare di non aver avuto l’obbligo di frequentare corsi sulla sicurezza durante gli studi.
Se gli sviluppatori non possiedono la formazione necessaria per identificare i problemi di sicurezza e non sono incentivati a farlo, non si può pretendere che producano codice sicuro, né che si interroghino sulla sicurezza dei componenti open source utilizzati. D’altro canto, le perplessità sulla sicurezza sono il motivo principale per cui le organizzazioni non si servono di componenti open source (49%), il che induce a pensare che potrebbe anche esserci un problema di mancanza di conoscenza e di consapevolezza su come rendere più sicuri tali componenti.
Responsabili della sicurezza senza la reale consapevolezza
Una volta implementati i componenti, chi sarà responsabile della loro manutenzione? Secondo il 44% degli intervistati questa responsabilità ricadrà sul team di sviluppo, mentre solo per il 31% sarà compito del team della security.
Il dato sembra indicare una maggiore responsabilizzazione del team addetto allo sviluppo, ma tale tendenza non sembra essere supportata da sistemi, strumenti o competenze tali da poter garantire l’utilizzo sicuro dei componenti. Fra le organizzazioni che utilizzano nelle proprie applicazioni componenti di terze parti, solamente il 52% provvede ad aggiornarli quando viene annunciata una nuova vulnerabilità. A mio avviso, queste percentuali rappresentano un campanello d’allarme: se si affida agli sviluppatori la responsabilità della manutenzione dei componenti, occorre fornire loro tutto quanto è necessario.
Come prima cosa servono loro tecnologie una gestione dinamica dell’inventario dei componenti in uso e delle rispettive collocazioni. Se possibile, tale inventario deve includere informazioni sull’eventuale utilizzo di funzionalità vulnerabili, oltre a istruzioni su come ovviare a eventuali falle nella sicurezza. In tal modo, qualora si diffondesse la notizia di una grave vulnerabilità, gli sviluppatori avrebbero già le informazioni necessarie a risolvere il problema rapidamente. Il processo di sviluppo potrebbe essere ulteriormente velocizzato con la creazione di un repository dei componenti approvati che possono utilizzare, contribuendo in tal modo a eliminare i dubbi sulla sicurezza dei componenti e a ridurre notevolmente il lavoro da eseguire in produzione.
In conclusione, ritengo che gli sviluppatori abbiano bisogno e debbano poter utilizzare componenti predefiniti.
Questa situazione richiede un’opera di informazione più capillare in merito al potenziale rischio rappresentato dall’uso dei componenti open source e di terze parti. E’ al contempo necessario far conoscere agli sviluppatori le opportunità offerte dagli strumenti e dalle tecnologie che permettono di continuare a utilizzarli, ma in modo sicuro, senza che il loro lavoro subisca rallentamenti.
a cura di Chris Wysopal, co-fondatore e CTO di CA Veracode
