|
For years testing applications for security meant a pen test, or penetration test, at deployment. For almost as long, security consultants have urged users to push security testing to earlier in the development lifecycle. I agree. Threat modeling, security requirements definition and architectural reviews are critical during the design phase. During the development phase, however, you need to account for code velocity or code churn. It is not efficient to test applications for security while code is being added and removed in large chunks. Once one gets to the build stage, this changes. Major features are largely in place and code churn is lower. I recommend static analysis as builds progress, followed by static analysis and dynamic analysis as a staging environment is ready.
In the past, companies would focus on run-time security, i.e. testing applications after they are deployed in live environments, such as a Web site/ecommerce site. Over the past few years, many companies have been advocating the philosophy that you should start testing as early as possible. Why? If you catch potential vulnerabilities early, they are easier to fix and you will avoid much higher costs that could result from a breach later. The downside of that approach is that developers who are not security experts are spending significant amounts of time learning about and concentrating on security rather than focusing on writing good, functional code.
I have a different perspective. Rather than scanning an application every day or week, I recommend focusing on key milestones in the software development lifecycle. Testing code doesn't make sense until applications are past the build stage, i.e. at the integration testing level. That's because until you get to the integration testing level where the code is able to be compiled, you are looking at piecemeal code. Critical milestones are unit integration testing, alpha testing, beta testing, pre-deployment (staging environment), and then during the deployment cycle, typically quarterly for compliance assessments. I call this "injecting" best practices at critical milestones in the SDLC.
|
