Quanto impatta il Code Review nel GDPR? È notizia di ieri: un gruppo di hackers ha usato un progetto pubblico su GitHub (che per chi non lo sapesse è una piattaforma di pubblicazione del codice e sua eventuale miglioria e condivisione) per inserire un malware in un pezzo di codice usabile dentro Xcode di Apple il framework di sviluppo proprietario della casa della mela morsicata.

Spieghiamo per i non addetti.

Io posso costruire un mio programma, metterlo su Github e chiunque (se io decido che sia possibile) può prendere quel codice e migliorarlo, aggiungendo funzioni e costruendo così delle alternative (fork) al mio progetto originario.

A repository's fork button

Tutto ciò in un mondo privo di hacker sarebbe il paradiso dello sviluppatore. Idee liberamente in circolo. Se non fosse che gli hacker esistono e possono essi stessi mettere mano a quel progetto migliorandolo, ma inserendovi dentro anche del malware (software malevolo in condizione di eseguire operazioni all’insaputa dell’ignaro utilizzatore).

In sostanza dopo l’intervento dell’hacker, il normale sviluppatore decide di prendere quel piccolo progetto e inserirlo nel suo. Questo perché offre delle funzionalità che altrimenti lui ci metterebbe troppo tempo a sviluppare. Quindi, in ottica di riutilizzo del codice e di risparmio lo sviluppatore incorpora nel suo codice quello sviluppato da altri. Gli hacker appunto.

Quando l’applicazione viene rilasciata, il codice malevolo agisce al suo interno all’insaputa di tutti quanti. Dando così luogo a potenziali databreach anche di proporzioni piuttosto importanti. Il codice malevolo può importare o esportare file, può usare telecamera e microfono per spiare il proprietario del device.

Code Review

In ottica GDPR, questo genere di situazioni sono estremamente difficili da individuare e richiedono un’attenta analisi del codice da parte delle società committenti, il Code Review appunto. Operazione costosa. Si tratta di pagare un soggetto che apra l’applicazione (comprate sempre il codice che commissionate) e la ricontrolli cercando codice malevolo. Ma eseguire un Code Review è perfettamente in linea con gli articoli 5 e 32 del GDPR stesso.

Quante aziende fanno questo genere di controlli? Ancora troppo poche, proprio per la loro dispendiosità. Ma quanti sviluppatori usano codice sviluppato da altri nei loro progetti? Praticamente tutti. Persino chi scrive, nella sua pur brevissima carriera di sviluppatore iOS ha usato i cocoapod (appunto snippet già pronti di codice).

Se traduciamo tutto questo sistema in termini di analisi del rischio, lo vedremo schizzare alle stelle, con codice altamente rischioso e potenziali databreach su ogni fronte.

Concludendo

Quanto impatta il Code Review nel GDPR? Era la domanda iniziale. Direi che le aziende che sviluppano software hanno davanti a se scelte importanti. O sviluppano dalla a alla z. Oppure dovranno garantire che il codice terzo utilizzato sia veramente sano. Dovranno spendere e i committenti idem per far sì che casi come questo non si ripetano.

D’altro canto ci si può anche chiedere la commissione di ricontrollo delle applicazioni di Apple come mai non individui questi problemi. Non ha tempo. Fa un controllo molto veloce del programma. Non entra più di tanto nel codice, altrimenti i clienti si lamenterebbero del troppo tempo di approvazione e dei costi troppo elevanti che Apple richiederebbe per un servizio aggiuntivo come questo.

Jaera team

Jaera team

Jaera S.r.l. si occupa di consulenza aziendale in ottica compliance e di nomina di specifiche funzioni aziendali, di consulenza in informatica e formazione.