Alcuni ricercatori hanno rilevato un trend allarmante che riguarda quasi tutte le aziende operanti in ambito ICT: gli sviluppatori dedicano più tempo alla manutenzione e alla messa in sicurezza del codice esistente piuttosto che dedicare tempo alla creazione di codici più sicuri già in partenza.
Le vulnerabilità di sicurezza hanno la cattiva abitudine di comparire durante il processo di sviluppo del software, per poi emergere dopo che un’applicazione è stata distribuita.
Che i bug esistano tutti lo sappiamo e (purtroppo) lo diamo per scontato. In fondo a scrivere il codice sono pur sempre esseri umani quindi è scontato che qua e là il programma andrà man mano limato. Questo ragionamento però fa acqua da tutte le parti!
Il problema è che aggiustare un codice compromesso prende molto più tempo di scriverne uno fatto bene una volta per tutte. Questo significa che la maggior parte di queste vulnerabilità si potrebbero evitare sul nascere, dal momento che gli strumenti per rilevare i bug ci sono eccome.
Perché i bug sono così pericolosi e andrebbero evitati il più possibile? È proprio sfruttando queste falle nel codice che gli aggressori possono prendere il controllo dei sistemi. Un bug sfruttato nel modo giusto può far crollare imperi, quindi perché rischiare danni potenziali enormi – dell’ordine di decine di milioni di dollari per intenderci – quando basterebbe scrivere il codice in maniera decente?
Mettiamo l’esempio anche di una vulnerabilità banale e non grave. Risolvere un bug minimo può diventare molto costoso, soprattutto se il difetto sta nella progettazione e tra i requisiti base di sicurezza. In questo caso andrà rivisto l’intero ciclo di vita di sviluppo software (SDLC).
Le soluzioni per ovviare a questo tipo di problema ovviamente ci sono. Basterebbe ad esempio dedicare più tempo alla stesura del codice, oppure testare più a lungo per rilevare i bug. Ma non solo. Pensiamo al DevSecOps: da solo non basta, serve un cambio di prospettiva perché la sicurezza va pensata già nelle prime fasi dello sviluppo. Prevenire è meglio che curare, quindi perchè non programmare già con concetti di programmazione difensiva come linee guida di codifica?
Le soluzioni, come già detto, sono molte. Ma prima di tutto deve cambiare la mentalità alla base dello sviluppo.