Scrivere software è un’arte. Su questo non ci sono dubbi. Il software di qualità è come un quadro d’autore¹, può essere bello da vedere, può essere difficile da capire o può essere una guernica, confuso ed a tratti pittoresco.

Quando realizzato in pollai alla dilbert il software perde un po’ del suo fascino e diventa una compilation fuzzy di bit che a volte riescono anche a soddisfare delle specifiche di progetto.

In entrambi i casi, formalizzato o no, inconscio o meno, la creazione di software è il risultato di un processo che parte da un requisito e che attraversa svariate fasi fino ad arrivare ad un prodotto.

Questo processo purtroppo è vittima della non cultura dell’ASAP e come vittima subisce tante deviazioni che rendono impossibile arrivare ad un prodotto di qualità.

Quando la security entra nel processo di sviluppo del software, si parla di SSDLC ovvero di un’evoluzione del ciclo di vita del software in salsa sicura.

Non per deboli di cuore

Anche parlare con gli sviluppatori è un’arte. Lo sviluppatore è orgoglioso e diffidente per definizione e lo specialista di sicurezza applicativa deve toccare i tasti giusti se vuole farsi ascoltare.

Ora immaginatevi per un secondo di voler andare da dei professionisti e cambiare radicalmente il modo in cui loro fanno una cosa, perché voi la ritenente sbagliata.

Esatto, se voi pensate di andare a sconvolgere un processo che in qualche modo funziona, in nome della sicurezza avete completamente sbagliato strada.

La parola d’ordine è: guanti di velluto.

Scusi, permette una domanda?

Innanzitutto, per iniziare a proporre un SSDLC in un’organizzazione semplice o complessa che sia, si deve iniziare dalla comprensione di quello che attualmente c’è già. Appunto perché non possiamo stravolgere il lavoro degli altri senza scatenare una sterile guerra, dobbiamo capire i punti di forza ed i punti deboli del processo in essere.

Può succedere che il team di sviluppo abbia ben chiari in testa i punti deboli, le lacune del proprio lavoro quotidiano. Quindi ben venga qualche ottimizzazione che permetta di essere più produttivi, magari lavorando meno. Perché no?!?

Per capire come funziona una cosa, dovete andare a parlare con gli sviluppatori. Qui armatevi di santa pazienza perché sarete messi alla prova, se quindi non avete idea di come sia un processo di sviluppo fatevi un favore: state in silenzio ed ascoltate. Se invece ne sapete qualcosa, il consiglio che vi do è ancora più prezioso: state zitti, fate qualche domanda ed ascoltate.

In questo primo assessment voi dovete uscire con le seguenti informazioni:

• chi sono gli attori coinvolti, dal committente allo sviluppatore;
• quali sono le fasi che il processo attraversa;
• come arrivano le esigenze e quali formalismi sono utilizzati;
• quali strumenti di sviluppo sono utilizzati (editor, compilatori, interpreti, debugger, strumenti per il test, strumenti per la build, strumenti per la gestione dei ticket e dei bug, ..);
• quali linguaggi sono utilizzati (sì, non esiste solo Java);
• come viene portato in produzione il software.

Il vostro deliverable sarà una serie di appunti fitti fitti. Dovrete, non solo capire la parte lavorativa ma anche la parte emotiva del processo. Dove sono le frustrazioni degli sviluppatori? In che modo un nuovo processo può renderli più produttivi? Come potete aiutarli veramente?

Se li aiutate e se non pretendete di dir loro come scrivere software, allora è probabile che vi stiano ad ascoltare.

E se vi ascoltano, voi siete sulla buona strada.

SSDLCS, interessante… ma pensiamoci un po’ sopra

Ora è il momento di non reinventare la ruota. Lo so che voi vorreste proporre l’ultimo dei plugin di tool di code review commerciali, ma se lo sviluppatore non usa quegli strumenti? Siete in grado poi di istruire quel plugin per soddisfare le linee guida interne di sviluppo sicuro? Come raccogliete poi l’output del plugin? Come indirizzate le remediation? Pensate veramente che lo sviluppatore tra le mille cose che ha da fare si metta ad eseguirlo e correggere tutto?

Due parole:

• imparare dai migliori;
• customizzare ed automatizzare.

La prima cosa che vi suggerisco di fare è andare a cercare sul web quali sono le novità sui temi di sviluppo sicuro e test automatizzato.

Vi suggerisco di guardare questo video. Stephen de Vries è uno specialista di application security ma è anche uno sviluppatore. In questo talk parla di come approcciare i temi di sicurezza in un modello agile di sviluppo.

Quando avete spremuto a fondo google, provate ad individuare in quali punti del processo che avete sentito dagli sviluppatori, voi mettereste i vari controlli di sicurezza e soprattutto quali controlli di sicurezza.

Il vostro scopo è uscire con un nuovo processo che:

• abbia le stesse fasi del processo originale
• permetta agli sviluppatori di usare gli stessi strumenti che usavano prima
• introduca la minor latenza possibile ed il minor overhead di lavoro
• sia centralizzato, ovvero siate voi security a comandare quali controlli debbano essere fatti e contro quali policy e soprattutto abbiate sempre sotto controllo i risultati
• sia automatizzato, ovvero lasciate che sia il computer a lavorare per voi

Ma quindi? Li spendo questi 500K in tool di code review?

Vuoi la mia opinione? NO, risparmiali. Spesso il processo si apre e si chiude in una settimana di lavoro, sempre di più vengono utilizzati processi agili di sviluppo che portano ad andare sul mercato in maniera aggressiva. Un tool di code review produce una serie di findings ed una serie di falsi positivi tali che in una settimana in 2 probabilmente non si è ancora finito di esaminarli, figuriamoci di far fare i fix agli sviluppatori.

I controlli devono essere:

• pochi
• semplici
• mirati

Ed il processo di retroazione sviluppo->check->fix deve essere rapido ed anche in questo caso automatizzato. Il risultato delle vostre scansioni deve far aprire dei ticket sul sistema di bug tracking utilizzato dagli sviluppatori con notifiche via email. Basta con report di 100 e passa pagine scritti in banfa style.

Off by one

Oggi abbiamo visto come la costruzione di un processo sicuro di sviluppo software parta con un assessment di quello che c’è già con lo scopo di introdurre piccolissimi interventi correttivi allo stesso.

Abbiamo visto come forse buttarsi nell’acquisto di quel tool o di quell’altro plugin non è detto sia la scelta migliore. Occorre ponderare con calma quello che serve veramente.

Prossimamente su questo blog, vedremo fase per fase cosa si può fare per aggiungere security al nostro SDLC aziendale.

Qual è la tua opinione? Tu da dove partiresti per costruire un SSDLC? Fai sentire la tua opinione e lascia un commento qui sotto.

L’immagine del Minosse pensante è licenziata CC ed è di Niccolò Caranti