One of my favourite quotes from Good Morning Vietnam, with the late Robin Williams still resonates for me in my working life; particularly when we look at the ‪security‬ of our software.

Perhaps more apt would be to state “we don’t have a problem with security….. We don’t have any security”

Where historically testing was always the forgotten child of a programme, security in many respects has taken over the mantle. Testing, whether conducted by the developer or dedicated tester is now recognised as an essential part of any delivery. Security on the other hand is seen by many as cumbersome, time consuming and “most developers now avoid SQL injection threats as standard practice”

If we look at security as a bolt-on, as a checklist item before we finally go to production, the stigma and indeed the last minute pressure of finding a security flaw in the system the reputation will always be a barrier to progress (as used to be the case with testing), mention security testing in an agile team and the sighs are clearly visible.

But why?

When you look at it logically, security testing “should” fit quite nicely into the iterative delivery of ‪‎agile‬. If we look at the reliance on APIs, natural defences are built in the form of wrappers to shield downstream systems from direct workflow or transactional attack.

Tool providers; such as ‪Dynatrace‬ and ‪Smartbear‬ have enhanced their products to provide the ability to monitor and gain feedback early in the cycle to reduce impact. Dynamic review of the code provides the development team with pointers and tips to close flaws.

I believe there will continue to be the need for the full Penetration Tests, however as we have seen with testing in general perhaps the mindset and objective needs to change. If project teams include security standards as part of a stories definition of done, then we may reach the stage where formal penetration testing becomes an assurance task as a final seal of confidence that the product is ready to go-live.

db