The software development life cycle (SDLC) comprises all of the steps in conceptualizing, developing, and releasing software. In this video, learn how to integrate security testing into the SDLC.
- [Instructor] In order to determine where and how to integrate your AppSec testing activities, you need to think in terms of the software development life cycle, or SDLC. The SDLC is a big picture concept that you break down into three concrete activities. One, conceptualize your application. What do you want it to do? Two, develop the application. Write the actual code. And three, release the application to the intended user population. So let's consider the SDLC from a developer's point of view for a second. Where exactly does security fit in? In order to answer that question, the best advice I can give you is something I picked up in Stephen Covey's book, the Seven Habits of Highly Effective People. "Seek first to understand, then to be understood." Developers have a lot of competing priorities. Imagine someone approaches you and says, "Hey, I need you to build me this thing. "I'm not exactly sure what it should look like, "but I'll know when I see it. "Here's a list of loosely defined features. "You don't have a lot of time or money to get this done, "and I needed it two weeks ago. "Can you have it done by Friday?" Now imagine that person walks away and someone else immediately steps in and says, "Oh, yeah, can you make sure "that the thing you build is secure?" You can teach your developers to understand how to integrate security testing into an already overwhelming development process, if you break that security down into manageable chunks. Think of that big, nebulous thing we call security as four distinct touchpoints in the SDLC. One, review the related documentation for security language, including contracts with third parties who are writing apps on your behalf. Two, review the source code for security vulnerabilities. Three, review the QA process to ensure that it includes security tests. And four, review the deployed applications for exploitable weaknesses. Offline testing includes the first two touchpoints in this list. It's best to start with offline testing for a few reasons. First, it's much less expensive to address security issues before you deploy an application to production. Second, security built in at the beginning is often more effective than security bolted on after the fact. And finally, offline testing doesn't come with the risk of breaking a production application. Low impact, high value. The key to building effective offline tests is balance. Take time to understand the development process from a developer's point of view. Analyze the market conditions that might impact your testing. Things like accelerating schedules to release a competing application. Or outsource development and hosting to keep internal costs down. Take a close look at the skills of both the developers and the security testers. Figure out everyone's strengths and weaknesses. Don't make assumptions about what the team is capable of doing. Be mindful of all of these items when designing your tests. Find the right balance among them, and your testing efforts are much more likely to yield positive results. This approach will enable you to more effectively integrate security testing into the SDLC, reducing both the likelihood and impact of a potential security issue later on.
- Security frameworks
- OWASP Top Ten
- Building Security In Maturity Model (BSIMM)
- Planning your testing projects
- Creating security policies
- Source code reviews
- Application threat modeling
- Offline testing for OWASP Top Ten vulnerabilities