Supponendo che tu stia lavorando su un pezzo di software che è richiesto per superare un test di sicurezza / penetrazione di terze parti prima di essere rilasciato al cliente, a quel punto nel ciclo di vita del progetto eseguiresti i test?
Il superamento del test significa che non vengono rilevati difetti importanti o, più probabilmente, che eventuali difetti rilevati sono stati correttamente corretti prima del rilascio.
Suppongo che dipenda da quanto è costoso (in contanti, tempo e risorse) eseguire il test, quanto spesso può essere ripetuto e quanto in anticipo è necessario negoziare le date dei test. E anche su quanto è limitata la sua validità, cioè se fai il cambiamento più semplice nel codice dopo aver superato il test, invalida l'intero test, costringendoti a ripeterlo completamente o parzialmente?
Se è costoso e difficile da organizzare, lo pianificherei nella fase UAT e cercherò di eseguire test più simili possibili in-house prima. Ovviamente, più facile e meno costoso farlo, prima vale la pena iniziare i test (una volta che ho una versione ragionevolmente stabile che include tutte le funzionalità critiche, cioè).
L'ovvia risposta semplice sarebbe: alla fine. Farlo a metà strada lascia spazio a difetti per insinuarsi durante la seconda metà dello sviluppo, ecc.
Più efficace sarebbe farlo ogni tanto. In questo modo sarai in grado di trovare e correggere i difetti più vicini a quando li hai effettivamente fatti, il che è molto più facile che ricordare quello che hai fatto mesi fa. Se riesci a mettere alcune delle basi del test di penetrazione in un test di unità, allora prima su un server di integrazione continua che può avvisarti se fai dei veri puzzolenti (anche se non puoi davvero sostituire i test reali).
When in the project life-cycle would you fit in external penetration/security testing of the software?
Succede in ogni fase del ciclo di vita.
Innanzitutto, i test di penetrazione sono solo una piccola parte di un puzzle di sicurezza più complesso.
In secondo luogo, i test di penetrazione includono una configurazione di runtime e un'adeguata amministrazione nonché un problema di implementazione del software. I test di penetrazione richiedono il corretto patching e configurazione di SO, server Web, database, firewall e software applicativo.
Esegui test di penetrazione dell'architettura prima di iniziare a fare progetti dettagliati. L'architettura è sicura?
Esegui test di penetrazione del design. Quanto è sicuro il design? Quali opportunità di penetrazione saranno presenti?
Esegui test di penetrazione come parte della codifica e dei test di unità. Il codice soddisfa il design? Utilizza correttamente le funzionalità architettoniche per prevenire problemi di sicurezza?
È quindi possibile sottoporre il prodotto software finale a tutti i tipi di controllo della sicurezza, inclusi - ma non limitati a - test di penetrazione.
La sicurezza è pervasiva. O ha dei buchi. Non è un "passo" nel piano di lavoro. È un principio di base.
Ovviamente è un rischio da fare alla fine, correggere le cose potrebbe costare solo molto tempo.
Ovviamente è un rischio farlo precocemente, le funzionalità aggiunte potrebbero aggiungere vulnerabilità alla sicurezza.
Il mio consiglio, fallo il più tardi possibile ma riduci il rischio.
Spero che questo aiuti
Lo farei parte del test di integrazione del sistema. A meno che il tuo sistema non sia altamente modulare, probabilmente non varrebbe la pena farlo come parte del test dell'unità. Lo pianificherei anche all'inizio della fase di test di integrazione, poiché i problemi di sicurezza sono noti per causare una significativa riprogettazione del sistema.
Leggi altre domande sui tag testing project-management security