James Smith* was the manager of information security at a large healthcare company. After several years of primarily running penetration testing, and a few limited source code reviews, James successfully made the case to internal IT leadership that security needed to come earlier in the software development life cycle (SDLC).

James had heard many people talk about the concept of secure SDLC at a high-level, but was having trouble planning concrete steps. What specifically should they change about requirements, design, development and testing?

Although most of the leadership was on board with the concept of bringing security earlier into the SDLC, there remained a few skeptics. In particular, Jill Lee, the chief technology officer, recently approached Bob and said, “The money we’ve put into this effort is money we’re taking away from the enterprise architecture refactoring project. You presented risk and cost reduction as the primary drivers for the SDLC security effort. For the former, I don’t see how it’d be more effective than our current penetration testing process. In fact, we haven’t had any serious breaches since we launched that process five years ago. For the latter, won’t we still need to perform penetration testing anyway? I have trouble seeing how adding more activities will reduce overall security costs. Our chief security officer seems to fully back your effort here, so I’m not going to strike down his decision but I want you to tell us what metrics you’ll use to prove both your cost effectiveness and risk reduction arguments. What benchmarks will we use to assess whether to continue this project or divert the money to other high-priority but currently unfunded projects?”

What concrete activities should James plan for, and how can he measure the effectiveness of his project according to Jill’s criteria?

^*All names are fictional and are generated from http://www.kleimo.com/random/name.cfm