IT Planner: 5 Steps to Secure Development

"Just as [it's more effective to fix] quality during coding than once in production, the same holds true for security," Weider said. "It's a mindset shift that needs to be created—baked-in security. Testing for quality needs to go hand in hand with testing for security. The development process needs to be adapted over time so that organizations are thinking about application security right away—during requirements, design, development and testing."

Adam Kolawa, co-founder and CEO of Parasoft, a maker of automated software quality tools, said developers must "realize there is no silver bullet for security and that security is really an infinite issue."

Kolawa added that it's important to get away from thinking about security in terms of fixing bugs and instead look at it as making sure that security errors don't exist in the code in the first place. "Security errors cannot be treated as bugs," he said. "You may or may not find bugs, but you must prevent security errors. In other words, you need to guarantee that certain classes of security errors do not exist in the code."

Step 2: Educate the players.

The second step in developing secure software is to educate the players in your software development organization.

Software security hasn't exactly been at the forefront of computer engineering, so chances are your developers, architects, product managers, QA (quality assurance) engineers and so on are not properly trained in what it means to design and implement secure software, Coverity's Chelf said.

"It's not just a matter of programming securely," Chelf said. "If you have a system that is perfectly implemented from a coding perspective but allows access because of poor password choices for the users, the system is still insecure. So it really does begin at the very earliest part of the software development life cycle."

Chelf said a variety of good resources, including books and online courses, are available for training developers on how systems can be compromised.

But in addition to book smarts, he said, developers need street smarts.

"You can set up a real lab, with a real system, and then exploit the system with a previous and known exploit," Chelf said. "Give your teams of developers the firsthand experience of debugging the exploited system, tracing the failure to its root cause and seeing firsthand not only how difficult it can be to track down the problem in an exploited system but also how subtle the error likely is that was taken advantage of. The goal of this type of exercise is to get your developers to feel the real impact of security vulnerabilities in the system."

As an adjunct to a lab, Microsoft's Bidstrup suggested, set up a security response process. "And be prepared to update your security development life cycle based on what you learn from your root-cause analysis of discovered vulnerabilities," Bidstrup said.