I VA sono la sicurezza applicativa?

Negli ultimi tempi ho notato che a fronte della domanda "come assicurate la sicurezza delle applicazioni?" mi viene risposto: "facciamo dei vulnerability assessment, dei penetration test e delle code review". Peccato che queste pratiche siano realizzate a fine lavori (in rari casi, anche in fasi intermedie), mentre la sicurezza andrebbe considerata sin dall'inizio, quando si stabiliscono i requisiti funzionali, si progetta il software e la sua architettura e si scelgono gli strumenti di sviluppo e i compilatori; un poco dopo, ma sempre prima dei VA-PT-CR, si dovrebbero stabilire degli standard di codifica.

Perché quindi in molti riducono la sicurezza applicativa ai VA-PT-CR? Provo con delle deduzioni, ma è bene precisare che si applicano a coloro che veramente intendono assicurare un buon livello di sicurezza alle applicazioni; non è questa un riflessione sul perché molti non si interessano all'argomento.

In molti riducono la sicurezza applicativa ai VA-PT-CR perché:

1- i venditori dei servizi di VA-PT-CR sono molto più bravi dei venditori dei servizi di sicurezza a supporto dell'analisi, progettazione, sviluppo e realizzazione dei software;

2- quasi nessuno offre buoni servizi di sicurezza a supporto dell'analisi, progettazione, sviluppo e realizzazione dei software; i tecnici migliori e più preparati si dedicano a fare VA-PT-CR, anche per attitudine (è molto più divertente cercare di bucare un'applicazione che scrivere documenti o scrivere codice); questa non è una critica, ma una presa d'atto delle diverse attitudini di ciascuno;

3- in effetti, chi offre servizi di sicurezza a supporto dell'analisi, progettazione, sviluppo e realizzazione dei software o è un consulente con pochissima conoscenza tecnica dello sviluppo (e quindi si limita a dire "individuate i requisiti di sicurezza fin dalla fase di analisi" senza poi dare ulteriori consigli), oppure riduce il tutto all'OWASP Top 10 (che riguarda alcuni aspetti della progettazione e non dell'analisi e dello sviluppo);

4- gli sviluppatori sono orientati a realizzare funzionalità, non la sicurezza; quindi è ben lontano dalla loro mentalità affrontare questo argomento sin dall'inizio;

5- i libri che trattano di questi argomenti sono pochissimi, molto voluminosi e molto costosi; ottime scuse per evitare di affrontarli, sia per gli sviluppatori (che quindi preferiscono affidarsi ad esterni che, per il punto 1, vendono solo VA-PT-CR) sia per i consulenti (che vendono già altri servizi più "di moda" senza doversi impegnare in una nuova materia difficile e poco richiesta).

Per dimostrare ulteriormente il punto 2, si osservi l'andamento dei progetti OWASP (owasp.org): la testing guide è stata aggiornata nel 2007, 2008 e 2014. La development guide, invece, è stata scritta inizialmente nel 2002, aggiornata nel 2005 e poi basta, anche se da diverso tempo stanno lavorando ad una nuova versione.