In molte organizzazioni si avverte una tensione costante fra sviluppatori e team di security. Da un lato, gli sviluppatori sono sottoposti a pressioni crescenti per creare applicazioni ricche e piene di funzionalità, con l’imposizione di tabelle di marcia pressoché irrealizzabili per tenere il passo con la concorrenza. Dall’altro, i team addetti alla sicurezza sono a loro volta oggetto di pressioni sempre più forti causate dalla presenza di cyber minacce sempre più pericolose e dalla crescente richiesta degli utenti consumer di un’adeguata salvaguardia dei loro dati.
Senza una corretta pianificazione, queste due istanze rischiano di entrare in collisione, dato che ogni gruppo è intento a realizzare i propri obiettivi. I team di sviluppo ritengono che i colleghi della sicurezza vadano a rallentare l’uscita di ogni nuova release. Dall’altra parte, i team di security mal tollerano il lavoro extra (e non pianificato) che sono costretti a svolgere per ovviare alle vulnerabilità create dagli sviluppatori, i quali non badano troppo alla sicurezza del codice perché vogliono rispettare a tutti i costi le proprie scadenze.
Eppure, con una piccola opera di preparazione, le organizzazioni potrebbero far sì che questi due gruppi lavorino assieme e si aiutino a vicenda. Prima si individua una vulnerabilità nel processo di sviluppo, più facile, più veloce e meno costosa essa sarà da correggere. Per questo motivo, le organizzazioni devono trovare il modo di porre l’attenzione sulla sicurezza già nelle fasi iniziali del processo di sviluppo: in altre parole, devono lavorare insieme agli sviluppatori per accertarsi che la sicurezza non sia una considerazione secondaria.
La prima cosa da fare è aiutare l’organizzazione a riconoscere il ruolo che la sicurezza deve svolgere nel processo di sviluppo. In questo modo, i responsabili di prodotto e d’impresa confermeranno che la sicurezza è una parte importante delle applicazioni sviluppate e che tutti i soggetti coinvolti nel processo devono tenerne conto. I responsabili di queste funzioni dovranno inoltre sottolineare che la sicurezza deriva direttamente dalla qualità, esattamente come la resilienza, la scalabilità, la facilità di manutenzione, la disponibilità operativa e così via. Il punto è che la maggior parte degli sviluppatori considera la sicurezza un territorio inesplorato che fino a ora non rientrava nelle loro mansioni, né era oggetto di formazione.
Uno dei modi più semplici e più efficaci per trasmettere il messaggio che la sicurezza è una priorità per l’organizzazione consiste nell’iniziare a offrire dei corsi sullo sviluppo di codice sicuro. Una volta istruiti sulle tecniche di base, gli sviluppatori saranno più responsabilizzati. Nessuno sviluppatore vuole scrivere codice poco sicuro: deve semplicemente capire come e perché nascano dei problemi di sicurezza e avere la possibilità di fruire di strumenti e risorse utili a produrre codice che soddisfi gli standard di codifica sicura.
Il passo successivo — e anche quello con gli effetti più massicci e incisivi — consiste nel far entrare in stretto contatto i team di security e sviluppo. Questo avvicinamento potrebbe già essere una realtà a seguito dell’introduzione di metodologie DevOps o DevSecOps. Ogni team ha bisogno non soltanto di operare a stretto contatto, ma anche di avere una comprensione più approfondita sulle difficoltà, sui processi e sulle priorità reciproche.
Uno dei sistemi più efficaci consiste nel designare un referente per la sicurezza (il cosiddetto Security Champion) all’interno del team di sviluppo.
Il Security Champion è un membro della squadra di sviluppatori che conosce bene le best practice della sicurezza applicativa e può consigliare i colleghi. Tale figura può essere preparata dal team di security per aiutare gli sviluppatori a isolare e correggere il prima possibile eventuali vulnerabilità nel processo di sviluppo, riducendo in pratica la responsabilità a carico del team della sicurezza. Questa collaborazione aiuterà non soltanto gli sviluppatori a scrivere codice più sicuro, ma ridurrà anche la mole di lavoro imprevisto causato da vulnerabilità rilevate in fasi successive del processo. Un flusso costante di interazioni fra i due team contribuirà inoltre a creare un clima di fiducia e a promuovere rapporti di collaborazione.
Alla luce dell’apparente incompatibilità dei loro ruoli non stupisce che i team di security e di sviluppo si trovino spesso in conflitto. Invece, con una considerazione attenta e una comunicazione più trasparente, le organizzazioni potranno riconciliare queste due squadre e aiutarle a capire meglio le esigenze dell’altra. In questo modo, anziché combattersi, le due funzioni potranno aiutarsi reciprocamente a produrre software di migliore qualità.
A proposito dell’autore
Chris Eng è Vice President of Research presso CA Veracode. Ha oltre 15 anni di esperienza nella sicurezza applicativa ed è a capo del team responsabile di integrare il know-how della sicurezza informatica nella tecnologia di CA Veracode. Durante tutta la sua carriera ha diretto progetti finalizzati a violare, sviluppare e proteggere applicazioni web e software commerciale per alcune delle più grandi aziende mondiali. Chris viene spesso invitato a parlare nelle principali conferenze del settore, quali quelle organizzate da BlackHat, RSA, OWASP e CanSecWest, dove ha tenuto presentazioni su una varietà di argomenti attinenti alla sicurezza delle applicazioni, fra cui attacchi criptografici, sicurezza agile, sicurezza delle applicazioni mobile e metriche di security.
