I tool di code review: croce o delizia?

Esiste un teorema fondamentale nell’informatica teorica che dice che una funzione polinomiale non può stabilire la correttezza di un’altra funzione polinomiale. Lo so, l’enunciazione è poco accademica e molto ortodossa, il concetto però è fondamentale e smonta i claim sensazionalistici dei vendor di tool di code review, dawnscanner compreso.

Un programma non è in grado di dire se un altro programma è formalmente corretto, quindi i tool di code review non daranno mai la soluzione certa alla domanda “il mio programma è scritto in maniera sicura?”.

Quindi quando qualcuno vi dice che il tool di code review X ti da dei risultati senza falsi positivi, sta facendo solo marketing. Un po’ come la crema di toro che promette faville sotto le lenzuola se applicata con perizia o il beverone che ti fa avere addominali da urlo senza bisogno di allenarsi.

Ma servono o no?

Diciamo subito una cosa. Analizzare del codice reale, anche fosse solo di 5 mila linee di codice, quindi una cosa abbastanza piccola, tutto a mano… è da pazzi. Io non lo farei mai, voglio troppo bene al mio unico neurone.

I tool di analisi statica hanno una grande utilità nel disegnare i flussi delle varie chiamate per fare (o provare a fare) taint propagation e fare un lavoro grep++ like sul codice. La taint propagation è quella tecnica per la quale, dato il flusso delle variabili all’interno del programma, si cerca di capire se venga attraversata una routine di sanitizzazione dell’input o se invece il dato controllato dall’utente viene usato direttamente, da qui cross site scripting, injection varie e tanto bla bla bla.

Quindi, come tutti gli strumenti, sì servono ma devono essere usati bene e con solide basi di analisi. Ecco perché, a mio avviso, non si può demandare agli sviluppatori l’onere di fare security code review con il plugin figoso pere il loro IDE a fumetti ed aspettarsi che il codice sia questo granché sicuro.

Non userei mai uno strumento che…

Guardando un po’ di tool commerciali ho provato a farmi un’idea delle peggiori feature fornite. Ecco una Top 3:

• il tool lavora solo sul compilato, non gli serve il codice sorgente. Analisi statica del codice… e il codice non ti serve, bhé curioso come vincolo. In realtà questo approccio presuppone che esista nel processo di SDLC una building machine e questo quando ci sono tanti gruppi di lavoro che usano tool differenti, sotto strutture differenti è impossibile da ottenere. Mi si dica poi per applicazioni PHP o Ruby che razza di compilato io debba avere…
• il tool non si aggancia a server SVN (o a server di continous build). Uno dei pillar¹ della costruzione di un SSDLC che funzioni è automare. Sappiamo che i nostri team di sicurezza applicativa sono in perenne sofferenza numerica sugli sviluppatori e sui progetti. La chiave per fare il proprio lavoro in maniera efficente è automatizzare la maggior parte della cose (che scoperta, vero?). E’ fondamentale poter scriptare il mio strumento di analisi statica in modo che un commit o una build inneschi il primo processo di verifica. Se questo tool non ha questa feature, chi l’ha sviluppato non ha contatto con la realtà.
• non supportiamo il framework X o la versione Y del linguaggio. Di recente ho trovato un tool commerciale che non era in grado di fare una scansione su codice iOS 8 perché, appoggiandosi pesantemente su xcodebuild era fortemente dipendente dal comportamento del compilatore. “Il tool supporta solo iOS 7” mi han detto. iOS 8 però è uscito più di 6 mesi fa e secondo le statistiche dell’Apple Store è già diffuso quasi al 90%, che significa che il tuo tool non lo supporta? In un mondo dinamico, come quello mobile, avere uno strumento di analisi statico riduce l’efficacia a 0%… leggasi, hai buttato via i tuoi soldi.

Menzione d’onore va a: il mio tool lavora solo nel cloud.

Userei uno strumento che…

Un po’ come un vestito di sartoria o un qualsiasi gingillo elettronico, l’utilità delle feature è molto personale. Io, per l’uso che ne faccio, voglio che il mio strumento di analisi sia:

• libero da GUI pesanti, opprimenti e mal disegnate. Fidatevi, le grandi software house di security non hanno ancora capito che hanno bisogno di un bel UX designer e di un bravo sviluppatore frontend
• scriptabile, datemi quelle API. Devo poter personalizzare quanto più possibile il mio strumento… deve essere creta ed io il vasaio, altrimenti ancora una volta si rivela un prodotto utile a metà, forse un quarto.
• sia estendibile. Devo poter aggiungere controlli particolari, magari seguendo linee guida interne di sviluppo e devo poterlo fare senza impazzire.

Findbugs, il belloccio dell’opensource

Quando mi chiedono, ma tu cosa usi per fare l’analisi di codice Java, io vorrei tanto parlargli di Owasp Orizon ma ripiego spesso e volentieri su findbugs che ho scoperto, ieri, avere un plugin per aumentare il numero di controlli di sicurezza: Find Security Bugs.

Find Security Bugs è un Jar che si deve aggiungere a findbugs per avere 56 controlli di security aggiuntivi. Fornisce integrazione con Jenkins e Maven ed è opensource quindi si può estendere, si può contribuire al progetto… non resta che provarlo e farci un bel post.