Code Writers Finally Get Security? Maybe

A new study finds software writers increasingly intent on baking security into their code writing, and Microsoft gets high marks for helping the process along.

Security practitioners often rant about sloppy software writing as the main reason attacks flourish. But newly released survey results suggest code writers are slowly starting to get it.

Atlanta-based Errata Security conducted a survey on software security assurance at the RSA Conference and Security B-Sides event in San Francisco earlier this month and found, among other things, that the most popular formal software security assurance methodology was the Microsoft SDL, followed closely by Microsoft SDL-Agile. At 46, the number of respondents was small. But the results provide an interesting snapshot of how secure coding has grown in importance, said Marisa Fagan, security project manager for Errata.

"There is still a large percentage of software companies who are not considering security the first time they write their application," Fagan said. "Waiting until a bug appears in the news is like paying someone to follow behind you and unravel all of your hard work. It's just a matter of time before they find a hole."

But the survey results suggest secure coding is of much deeper importance than it used to be. More than half of the participants said they included preventative security activities in the development lifecycle of their product. The most popular formal software security assurance methodology was the Microsoft SDL, followed closely by Microsoft SDL-Agile.

Thirty-five percent of respondents use the Agile SDLC, which explains the rapid adoption of the newly released SDL-Agile methodology.

The survey also indicated that companies with product development teams of less than 10 people actually manage to implement formal methodologies more successfully than companies of 100-plus members. The smaller companies also seem more serious about giving security training to a wider group of employees. Larger companies more frequently used an ad-hoc or custom methodology, Fagan said.

Awareness of formal methodologies like SDL, BSIMM, SAMM, and CLASP is high, at 81 percent, but 43 percent of companies still choose not to use one, citing a lack of resources. Errata also found that security tool vendors are increasing awareness by explaining where their tools fit in the security development lifecycle.

"Our analysis shows that the root cause of software vulnerabilities is in the early stages of the software development lifecycle," said David Maynor, CTO for Errata Security. "As consultants, we're in the field seeing what happens after a security breach. We've decided we need to attack the problem where it starts."

The push to make secure code writing easier has been gaining momentum in recent years. Among Microsoft's efforts to bake security into its code from the beginning is a set of guidelines released late last year for developers building Web applications and for those using the Agile process.

The move came several months after security firms Cigital and Fortify rolled out BSIMM -- the Building Security In Maturity Model. It's a set of best practices Cigital and Fortify developed by analyzing real-world data from nine leading software security initiatives and creating a framework based on common areas of success.

By studying what the nine initiatives were doing, BSIMM's creators were able to build a best-practices model that's broken into 12 categories software makers can follow:

  • 1. Strategy and metrics
  • 2. Compliance and policy
  • 3. Training
  • 4. Attack models
  • 5. Security features and design
  • 6. Standards and requirements
  • 7. Architecture analysis
  • 8. Code review
  • 9. Security testing
  • 10. Penetration testing
  • 11. Software environment
  • 12. Configuration and vulnerability management

Delving deeper, the BSIMM model recommends such things as employing one dedicated security practitioner for every 100 software developers on a staff.

Join the discussion
Be the first to comment on this article. Our Commenting Policies