Building Security In Maturity Model: Version 5 Released

Spearheaded by Gary McGraw (CTO at Cigital), Sammy Migues (director of knowledge management at Cigital) and Jacob West (CTO of enterprise security products at HP), BSIMM is described as "a measuring stick for software security." It is based not on security theory, but on the actual practices of 67 major firms (up from 51 in the previous version). 

The purpose is nothing less than to improve the security of software at the development phase rather than having to rely on additional security software overlaid when it is in use. By listing best practices gleaned from existing developers, other companies can learn from and relate to those practices, and develop more secure software.

It sounds a simple concept; but is actually based on sound science. The 'wisdom of crowds' is well-known. As long ago as a country fair in Plymouth, UK in 1906, it was observed that the median guess in a contest involving 800 people asked to guess the weight of an ox was within 1% of the correct weight. Individuals may be very wrong; but the crowd is usually right. The BSIMM crowd wisdom derives from the work of 975 software security professionals working with a development-based satellite of 1,953 people to secure the software developed by 272,358 developers.

By using the actual security-relevant practices within the 67 different, but major, companies involved in software development, the end result is going to be a very sound approach to secure software development.

“The BSIMM Project started as a simple data driven science project and has evolved into the world’s premiere measurement tool for software security”, said McGraw. “With BSIMM-V, we have significantly expanded the data set again and are now confident that we can measure any firm worldwide with the same measuring stick."

In total, BSIMM describes 112 different security activities (up from 111 in the last version). Companies are not expected to action all of these activities, nor is it prescribed how each activity should be undertaken; but in general, the more activities that are part of a developer's processes, the greater the resulting security. Conversely, the fewer of these activities that are part of a company's development practices, the less likely it is for the resulting software to be secure. "If you wonder how your firm’s software security practices stack up, we can tell you”, says McGraw.

The latest version has added just one new activity: bug bounties. "Operate a bug bounty program" is the recommendation. The description demonstrates how not all activities will be relevant to all developers. "The organization solicits vulnerability reports from external researchers and pays a bounty for each verified and accepted vulnerability received. Payouts typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g., remote code execution is worth $10,000 versus CSRF is worth $750), exploitability (demonstrable exploits command much higher payouts), or specific services and software versions (widely-deployed or critical services warrant higher payouts)."

This is relevant to companies developing software for public consumption, but is less relevant to companies developing proprietary software for internal use only. But it is by selecting and actioning those activities that are relevant to individual circumstances that companies can draw on the crowd wisdom of the BSIMM document, and either measure or improve their own secure software development.

What’s hot on Infosecurity Magazine?