Pur essendo stati largamente pubblicizzati i tanti vantaggi dell’open-source, si continua a sottostimare la prevalenza dei componenti (open-source e commerciali) di codice utilizzati nei diversi settori. CA Veracode ha recentemente scoperto che l’83 per cento degli sviluppatori si serve di componenti già pronti per sviluppare applicazioni web, al punto tale che ogni applicazione contiene in media ben 73 componenti.
Se si pensa che la stragrande maggioranza degli sviluppatori si avvale di componenti per costruire le proprie applicazioni, appare straordinariamente basso il numero di developer pienamente consapevoli dei rischi associati a tale pratica. Solamente il 52 per cento delle aziende ha dichiarato di prevedere dei rimedi correttivi quando scopre nuove vulnerabilità nei componenti. Pur essendovi mediamente in ogni applicazione 71 vulnerabilità introdotte dall’utilizzo di componenti di terze parti, solo il 23 per cento ammette di eseguire test di vulnerabilità a ogni release.
Inoltre, solo il 43 per cento degli sviluppatori ha dichiarato di essere a conoscenza delle raccomandazioni OWASP riconosciute dal settore allo scopo di impedire l’utilizzo di componenti affetti da vulnerabilità note.
Di chi è la responsabilità?
Da questa prassi di sviluppo del software emerge chiaramente che la responsabilità della sicurezza del codice parrebbe ricadere su tutti — o su nessuno. Secondo il 44 per cento dei soggetti interpellati, a essere responsabili sarebbero gli sviluppatori della sicurezza dei componenti di codice, mentre, a detta del 31 per cento del campione, la responsabilità di tale compito ricadrebbe sugli addetti alla sicurezza informatica.
Tale mancanza di preparazione e di comunicazione lascia spazio all’infiltrazione di malintenzionati che hanno modo di sfruttare vulnerabilità facilmente risolvibili.
Come fanno allora i diversi team a garantire la sicurezza delle applicazioni costruite tramite componenti? La soluzione si incentra su tre punti chiave:
· Partire sempre dall’(in)formazione: i team di sviluppo software devono disporre degli strumenti e della formazione necessari a garantire la sicurezza del codice sviluppato. Istruire gli sviluppatori sui rischi associati ai componenti open-source e commerciali è un buon punto di partenza, ma la chiave per il successo duraturo sta nell’investire nel training e nell’aggiornamento permanente in materia di sicurezza informatica. Servirsi del team di security per tenere sessioni di training ai colleghi sviluppatori è un ottimo sistema per instaurare una logica di condivisione delle conoscenze fra pari e per abbattere i silos che separano le due funzioni.
· Introdurre processi chiari: per ridurre la confusione e la carenza di comunicazione, le aziende devono implementare processi chiari ai fini dello sviluppo di software sicuro. Sapere com’è composta un’applicazione costituisce il primo passo, dato che i team non possono garantire la sicurezza di ciò che non comprendono. Potrà sembrare ovvio, ma CA Veracode ha scoperto che solamente il 53% delle organizzazioni tiene un inventario aggiornato dei componenti. I componenti di codice andrebbero passati minuziosamente al vaglio prima di essere inseriti in un’applicazione, e poi andrebbero aggiunti a un inventario dinamico. I responsabili dovrebbero controllare che per ciascuna parte del processo di manutenzione sia stato chiaramente definito un referente all’interno del team in modo da avere sempre una visione chiara sulle responsabilità. Altre buone pratiche di security sono il testing e il patching.
· Stimolare l’innovazione con DevSecOps: tutto ciò si ricollega alla necessità di integrare la sicurezza nell’intero ciclo di sviluppo del software (SDLC) e di implementare DevSecOps, perché un team che opera in silos non sarà mai in grado di produrre codice sicuro. I team Dev, Ops e Sec forniscono tutti un contributo cruciale al processo di sviluppo del software: solo unendo le forze si riuscirà a ottenere il miglior prodotto possibile.
Anche se il tempo investito per proteggere le applicazioni dai potenziali pericoli insiti nell’utilizzo di componenti potrebbe rallentare momentaneamente il processo di sviluppo, in un’ottica di lungo periodo varrà molto di più la tutela dell’organizzazione e delle risorse software.
