Diventa Autore per CoreTech | Scopri di più
30/03/20 CoreTech Blog
Tutte le vulnerabilità di sicurezza sono il risultato di un errore umano. Tutti i problemi di sicurezza delle applicazioni web vengono introdotti dagli sviluppatori. Pertanto, l'approccio migliore per la creazione di software sicuro è quello di fare tutto ciò che è possibile per evitare di introdurre tali errori in primo luogo, invece di correggerli.
È possibile trovare diverse guide dettagliate su come creare codice sicuro durante lo sviluppo dell'applicazione, ad esempio quella fornita da Open Web Application Security Project (OWASP). Si concentrano su dettagli quali la convalida dell'input, la codifica dell'output, il controllo degli accessi, la sicurezza delle comunicazioni, la protezione dei dati, le procedure di crittografia e così via. Invece, vorremmo che tu esaminassi questo problema di sicurezza software da un punto di vista strategico.
Nella maggior parte dei casi, gli sviluppatori introducono rischi per la sicurezza nel codice sorgente semplicemente perché non sono consapevoli di tali rischi. Mentre le università spesso si concentrano sull'insegnamento di tali dettagli come la verifica formale, molti di loro non offrono corsi dedicati sulla sicurezza. Questo è particolarmente vero per gli sviluppatori più anziani che hanno seguito tali corsi diversi anni fa, quando ancora non c'era alcuna pubblicità sulla sicurezza.
Le università insegnano anche un numero limitato di linguaggi di programmazione quindi nella maggior parte dei casi che gli sviluppatori sono autodidatti, e alcuni problemi di sicurezza sono molto specifici del linguaggio di programmazione. Ad esempio, non troverai un rischio di overflow del buffer in Java o in C #. Anche se il corso insegna una lingua, raramente si concentra sulla codifica sicura in quella lingua.
Per assicurarsi che i team di sviluppo software non commettano errori a causa della mancanza di consapevolezza, comprensione o lacune nell'istruzione, è necessario affrontare il problema in modo strategico:
Anche gli sviluppatori più consapevoli e meglio istruiti continuano a commettere errori, quindi semplicemente fidarsi di loro per scrivere codice sicuro non è sufficiente. Hai bisogno di strumenti che li aiutino a realizzare i loro errori e correggerli.
In una situazione ideale, il software deve essere testato utilizzando i seguenti strumenti e metodi:
Tuttavia, i test di sicurezza richiede molto tempo e risorse. Pertanto, è spesso necessario un compromesso tra il tempo e lo sforzo necessari per eseguire i test e la qualità dei risultati. Se è necessario un compromesso di questo tipo, la scelta di uno scanner DAST veloce che fornisce proof-of-exploit è la scelta migliore.
Per ottenere la massima qualità del codice non è sufficiente avere requisiti di codifica sicuri e linee guida di codifica sicure in atto insieme a un'infrastruttura di test. I team non devono solo sentirsi obbligati a seguire i principi di codifica sicura durante il processo di sviluppo e farlo perché il loro codice verrà testato, ma devono anche sentire che la scrittura di codice sicuro è nel loro interesse. La codifica sicura non ha solo bisogno di regole e applicazione, ha bisogno dell'atteggiamento giusto.
Un approccio shift-left, come quello descritto in precedenza, presenta molti vantaggi, uno dei quali è che gli sviluppatori si rendono conto di essere parte integrante del panorama della sicurezza. Si sentono responsabili per la sicurezza del codice e si rendono conto che se commettono un errore, dovranno ripararlo immediatamente e non contare su qualcun altro che lo farà in seguito.
Naturalmente, è possibile testare l'applicazione per le vulnerabilità di sicurezza appena prima che entri in produzione. Tuttavia, ti costerà molto di più di quanto sarebbe ti spostassi a sinistra. Il software dovrà attraversare nuovamente tutte le fasi, che coinvolge altre risorse, non solo gli sviluppatori. Lo sviluppatore non ricorderà il codice su cui hanno lavorato o la correzione potrebbe essere assegnato a uno sviluppatore diverso da quello originale e, di conseguenza, lo sviluppatore avrà bisogno di più tempo per trovare e rimuovere la vulnerabilità. Di conseguenza, i test tardivi possono ritardare il rilascio anche di diverse settimane.
In conclusione, vorremmo che vi rendeste conto che i criteri di sicurezza, sebbene necessari, non sono sufficienti se vengono percepiti come una limitazione, non un miglioramento. La sicurezza inizia con l'atteggiamento giusto durante la creazione di applicazioni. E anche i migliori strumenti utilizzati per mantenere la sicurezza devono essere utilizzati nel modo corretto nel processo in modo che siano percepiti come utili, non come un onere.