The most effective time to do security testing

The most effective time to do security testing

At what point in the software development lifecycle (SDLC) is it appropriate, and most effective, to conduct security testing?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

This was first published in October 2007