Al ritorno del TechEd tenuto quest'anno, in quel di Barcellona, un mio amico ha avuto l'insana idea di portarmi il seguente libro:
The Security Development Lifecycle - Microsoft - Michael Howard, Steve Lipner
Premettendo che ancora non l'ho finito di leggerlo, ho voluto fare il sunto di qualche parti che, per alcuni potranno essere scontate mentre per altri potranno tornare utili.
Introduzione: SDL
Applicare SDL a un progetto è un processo alquanto dispendioso ed ad oggi poco quantificabile.
Perchè allora un'azienda dovrebbe applicare SDL?
Un'azienda spesso è composta da personale tanto orgoglioso del proprio codice che difficilmente ammetterà la necessità di doverne rivedere alcune parti (o tutto).
In più rivedere il proprio codice è un lavoro tedioso e richiede molto tempo; questo più è vero più l'azienda è piccola.
Scrivere subito codice migliore significa perdere meno tempo nel rivederlo alla ricerca di bugs, che si traduce in avere più tempo per: andare in palestra, giocare con i bimbi, girare in moto e leggere un buon libro (non d'informatica).
In più a fronte di un progresso che sta portando le varie applicazione a interagire tra di loro affinchè l'utente possa avere i dati da lui ricercati, è d'obbligo produrre dei software che riescano a relazionarsi fra di loro con pochissimi problemi e con una forte componente di sicurezza e privacy.
Un’altra motivazione che spinge un'azienda ad applicare SDL all'interno del loro processo di produzione è la qualità del prodotto che verrà immesso nel mercato:
Com’è visibile dal grafico poco sopra, le aree: Privacy, Security, Reliability e Quality, sono strettamente relazionate.
L’azienda può rivendere i costi di applicazione di SDL come un bonus dell’applicazione.
Tags: SDL