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.

Why software security?

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.

Who needs this stuff?

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.

What makes the BSIMM so special?

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.

Whom did you study?

On average, the 120 participating firms had practiced software security for 4.13 years at the time of current assessment (ranging from less than a year old to 19 years old as of June 2018). All 120 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 13.3 people (smallest 1, largest 160, median 5.5), with an average satellite group of others (developers, architects, and people in the organization directly engaged in and promoting software security) consisting of 52.4 people (smallest 0, largest 2,250, median 0). The average number of developers among our targets was 3,463 people (smallest 20, largest 45,000, median 900), yielding an average percentage of SSG to development of 1.33% (median 0.67%).

All told, the BSIMM describes the work of 1,600 SSG members working with a satellite of 6,291 people to secure the software developed by 415,598 developers.

Who's actually responsible for this stuff inside these companies?

The executives in charge of the software security initiatives we studied have a variety of titles, including chief data and security privacy officer, CISO, CSO, director of enterprise security architecture, director global security and compliance, director product security, executive director product operations, head application security architecture and engineering, head application security programs, manager InfoSec engineering, manager product security, managing VP application security and technology analysis, VP cybersecurity, VP InfoSec, and web security manager. We observed a fairly wide spread in exactly where the SSG is situated in the firms we studied. In particular, 63 of the 120 participating firms have SSGs that are run by a CISO or report to a CISO as their nearest senior executive. Thirteen of the firms report through a CTO as their closest senior executive, while 10 report to a CIO, seven to a CSO, four to a COO, two to a CRO, and one to a CAO. Twenty of the SSGs report through some type of technology or product organization.

What's in the BSIMM?

BSIMM describes 116 activities organized in 12 practices according to the software security framework. During the study, we kept track of how many times each activity was observed. Here are the resulting data (to interpret individual activities, download a copy of the BSIMM document, which carefully describes the 116 activities).

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.

So now I have to go do 116 security activities? Sounds like a lot. I hope you're not expecting a big thank-you at this point.

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 IoT 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.

Why are some activities highlighted?

The 12 highlighted activities are those we observed most often in each practice.

Twelve core activities “everybody” does

Activity	Description
[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.2]	Create a Security Portal.
[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.

I'm more of a visual person. Draw a picture for me.

To give you some idea of the analysis capabilities provided by the BSIMM, here are three spider graphs showing average maturity level over some number of organizations for the 12 practices. The first graph shows data from all BSIMM firms (which we call Earth). The second graph shows data from a sample fake firm plotted against Earth.

Three verticals in the BSIMM operate in highly regulated industries: insurance, healthcare, and financial services. In our experience, large financial services firms reacted to regulatory changes and started their SSIs much earlier than insurance and healthcare firms. Even as the number of financial services firms doubled over the past five years with a large influx into the BSIMM of newly-started initiatives, the financial services SSG average age at assessment time remains 5.4 years, versus 3.1 years for insurance and 2.5 years for healthcare. Time spent maturing their collective SSIs shows up clearly in the side-by-side comparison. Although the insurance vertical includes some mature outliers, the data for these three regulated verticals show insurance generally lags behind in software security. We see a starker contrast in healthcare, with virtually no outliers. The overall maturity of the healthcare vertical remains low.

Is everybody in the study equally good at software security?

Not by a long shot. By computing a score for each firm in the study, we can also take a look at relative maturity and average maturity for one firm against the others. The range of the current pool is [5, 79].

We’re pleased that the BSIMM study continues to grow year after year. The dataset we report on here is over 35 times the size it was for the original publication. Note that once we exceeded a sample size of 30 firms, we began to apply statistical analysis, yielding statistically significant results.

Is the BSIMM a standard?

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.

What should I do with the BSIMM?

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.

That's so cool! Whom do I pay? How much does this cost?

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.

Can you shed some light on who we is, Mr. First Person Plural?

We are software security experts Gary McGraw, Sammy Migues, and Jacob West. Brian Chess was an author of the first three versions of the BSIMM.

What is a software security group (SSG)? Do I have to have one?

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.33% across the entire group of 120 organizations we studied. That means one SSG member for every 75 developers when we average the ratios for each participating firm. The SSG with the largest ratio was 10% and the smallest was 0.01%. To remind you of the particulars in terms of actual bodies, SSG size on average among the 120 firms was 13.3 people (smallest 1, largest 160, median 5.5).

If the BSIMM is so important, how has the world gotten along without it for so long?

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.

I get it, but my boss doesn't. How do software security initiatives get off the ground?

Over the years of the BSIMM study, we’ve seen the same kind of need to justify software security as we saw back in the day before IT security became mainstream. Back then, there were executives who simply didn’t get why firewalls were necessary or how intrusion detection helped prevent a small issue from becoming a big one or how simply teaching people how to think about security could actually change a corporate culture. In those early days, even managers who understood the problem intellectually were sometimes sorely tempted to see just how long the firm could wait before it became their turn to be victimized.

In the BSIMM data pool, we’ve seen software security groups get their charter and funding under four broad sets of circumstances:

Executive management said, “We will make secure software,” and funded the means to do it (e.g., the Gates memo at Microsoft).
An established upper management group responsible for some form of compliance determined that software security was a necessary expense in the firm’s governance processes.
The IT security crew proved that a breach was not their fault but rather a result of the firm’s applications. As a result, a software security person was appointed in the IT ranks.
A charismatic software security entrepreneur (e.g., in the CIO, CTO, legal, or governance group) worked the system to get the ball rolling and then parlayed early successes into funding for an actual program.

It seems that the hard part these days isn’t necessarily selling upper management on the problem but convincing them that you’re the right person to lead the solution and that you actually have a plan. If you are responsible for software security—in the sense that you are the person who would be fired after a major software security failure—and you cannot get resources for a program that will address the issues, quit now. Seriously. Life is just too short for that kind of nonsense, and there are plenty of employers willing to make real use of your abilities.

The BSIMM is designed to help you understand, measure, and plan a software security initiative. The BSIMM was created by observing and analyzing real-world data from leading software security initiatives.

Useful Links

About BSIMM

Privacy & Legal

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License