Here you will find frequently asked questions about the BSIMM. For the full and unexpurgated model in all its glory, download the BSIMM document.
BSIMM (pronounced “bee simm”) is short for Building Security In Maturity Model. The BSIMM is a study of real-world software security initiatives organized so that you can determine where you stand with your software security initiative and how to evolve your efforts over time.
Software security is about building software to be secure even when it is under attack. As we have learned from years of network security drama, protecting software is much easier if the software is built with security in mind. Furthermore, security is a property and not a thing, so software security involves much more than simply adding security features like SSL or passwords to software.
Organizations that depend on software to work (pretty much everybody these days) need software that doesn’t leak millions of identity records, call election results into question, gin up huge legal liabilities, or allow secrets to fall into the wrong hands. The only way to make software trustworthy is to build security in. In short, everyone who relies on software needs the BSIMM.
We built the BSIMM entirely from observations we made by studying real software security initiatives. The BSIMM does not tell you what you should do; instead, it tells you what everyone else is actually doing. This approach stands in sharp contrast to “faith-based” approaches to software security.
On average, the 109 participating firms had practiced software security for 3.88 years at the time of current assessment (ranging from less than a year old to 19 years old as of June 2017). All 109 firms agree that the success of their initiative hinges on having an internal group devoted to software security—the SSG. SSG size on average is 11.6 people (smallest 1, largest 130, median 5) with an average satellite group of others (developers, architects, and people in the organization directly engaged in and promoting software security) consisting of 32.1 people (smallest 0, largest 1400, median 0). The average number of developers among our targets was 2,666 people (smallest 20, largest 35,000, median 800), yielding an average percentage of SSG to development of 1.60% (median 0.88%).
All told, the BSIMM describes the work of 1,268 SSG members working with a satellite of 3,501 people to secure the software developed by 290,582 developers.
The executives in charge of the software security initiatives we studied have a variety of titles, including director of enterprise information security, SVP application security, CTO, CISO, CSO, CIO, global head of application security, chief of product security, chief of enterprise architecture, manager of secure development life cycle engineering, VP cyber security, VP security operations and intelligence, director of global security and compliance, and VP standards, quality, and security. We observed a fairly wide spread in regard to where the SSG is situated in the firms we studied. In particular, 35 exist in the CIO’s organization, 15 exist in the CTO’s organization, 12 report to the COO, 4 report to the CFO, 3 report to each of the chief assurance officer, the CSO, and the general counsel, 2 report to the chief risk officer, and 1 SSG reports to the founder. Thirteen SSGs report up through technology or product operations groups (as opposed to governance organizations). Four report up through the business unit where they were originally formed.
When we describe an activity, we give the objective, a description, and one or more real examples to illustrate how organizations make it happen. The examples are never the only way to conduct a given activity, but we think they are helpful for understanding software security reality.
Never fear! There’s no organization that carries out all activities. We found a surprising amount of common ground between the financial services organizations, independent software vendors (ISVs), and technology companies we studied, but their initiatives are by no means identical, and every organization is at least a little bit different. You wouldn’t implement a carbon copy of a friend’s financial plan, would you? Don’t expect to lift someone else's software security initiative either. Use the BSIMM as a source of ideas and general guidance—as a trail guide rather than as a cookbook.
The 12 highlighted activities are those we observed most often in each practice.
|[SM1.4]||Identify gate locations and gather necessary artifacts.|
|[CP1.2]||Identify PII obligations.|
|[T1.1]||Provide awareness training.|
|[AM1.2]||Create a data classification scheme and inventory.|
|[SFD1.1]||Build and publish security features.|
|[SR1.3]||Translate compliance constraints to requirements.|
|[AA1.1]||Perform security feature review.|
|[CR1.2]||Have SSG perform ad hoc review.|
|[ST1.1]||Ensure QA supports edge/boundary value condition testing.|
|[PT1.1]||Use external penetration testers to find problems.|
|[SE1.2]||Ensure host and network security basics are in place.|
|[CMVM1.2]||Identify software bugs found in operations monitoring and feed them back to development.|
Though the healthcare vertical includes some very mature outliers, the data show healthcare generally lags behind in software security. We see a similar phenomenon in insurance, where the overall maturity of the vertical remains somewhat low. By contrast, the Internet of Things vertical benefits from member firms that have been practicing software security longer.
We create these charts by scoring the highest level of activity in each practice in each firm and then averaging those scores by practice across a group of firms. The spider chart has 12 spokes corresponding to the 12 practices.
The BSIMM is not a standard like Control Objectives for Information and Related Technology (COBIT) or the official rules of table tennis (ping-pong). Instead the BSIMM describes the set of activities practiced by the most successful software security initiatives in the world. In that sense, it is a de facto standard because it’s what organizations actually do. You could say we discovered it rather than dreamed it up.
If you don’t have a software security initiative, you need one. You can use the BSIMM to get started. The BSIMM can help you figure out how many people you’ll need in your software security group, what those people should do first, and what kinds of things they’ll probably be thinking about in a few years. If you already have a software security initiative, you can use the BSIMM to learn where you stand and make plans for the future.
The BSIMM is free. As in, have at it. We’ve released the BSIMM under a Creative Commons license. You can take it and use it as inspiration for your own internal documents or use our dataset to make a model of your very own. If you do those things, you are required to tell people where the material came from. In other words, point back to the BSIMM. If you need a little help, contact us.
All BSIMM participants have an internal group devoted to software security—the software security group (SSG). We have never observed an organization carrying out the activities in the BSIMM successfully without an SSG. We noted an average ratio of SSG to development of 1.60% across the entire group of 109 organizations we studied. That means one SSG member for every 60 developers when we average the ratios for each participating firm. The SSG with the largest ratio was 16.7% and the smallest was 0.01%. To remind you of the particulars in terms of actual bodies, SSG size on average among the 109 firms was 11.6 people (smallest 1, largest 130, median 5).
For many software makers (including ISVs, banks, healthcare providers, and governments), software security has been a real concern only for 10 years or less. The collective “we” are just now reaching the point where we have accumulated enough experience to compare notes and talk about what works at a macro level. Secure programming, penetration testing, and the like have been topics for a while now, but the best methods for organizing humans into software security initiatives have take longer to emerge.