Have you heard of the BSIMM? If you have, you know it’s the best way to measure your software security initiative (SSI) year after year to see how it’s evolving and how you compare to your peers. If you haven’t, you’re in luck: The latest version is out now, and it’s notably different from last year’s version. Read on for a summary, or read the whole thing here.
The BSIMM is the Building Security In Maturity Model. It compiles all the observations collected from BSIMM assessments (analyses of individual organizations) and draws conclusions about best practices, how real-life SSIs mature and evolve, and the state of software security within and across verticals. In other words, it represents the software security activities performed by real-world organizations—not what they should do but what they actually do.
When an organization asks for a BSIMM assessment, we send a team of consultants to conduct in-depth interviews with key security personnel from the software security group (SSG) and the legal, compliance, training, intelligence, incident response, and engineering teams. Using these observations, we score the organization’s existing efforts in 116 software security activities.
These SSIs are real people who go to work every day and interact with thousands of other people to make a real difference in the software security world. They do a great job responding to everything going around them, and the BSIMM numbers show it.
—Sammy Migues, BSIMM author and principal scientist, Synopsys
In the BSIMM results, we compare the organization’s SSI to other organizations in the same vertical, and we discuss areas of strength and potential improvement. Then we add all those observations to the BSIMM pool, updating the model incrementally with every assessment (and removing those assessments that have aged out). That’s how we can be sure the model reflects the state of software security and the maturity of SSIs in the real world.
BSIMM9 is the ninth version of the BSIMM. It describes 116 activities (grouped into 12 general practices in four domains) performed by 120 firms we assessed within the last 42 months. Some firms got multiple assessments during that time (to see how their SSIs are maturing), and some firms had multiple business units assessed separately, so we ended up with 320 measurements.
BSIMM9 incorporates the largest set of data collected about software security anywhere. By measuring your firm with the BSIMM measuring stick, you can directly compare and contrast your security approach to some of the best firms in the world.
—Dr. Gary McGraw, BSIMM author and VP security technology, Synopsys
With that much data, it’s easy to see patterns emerge. And BSIMM9 has patterns aplenty, plus three brand-new activities that confirm what we all know: Everyone’s moving to the cloud.
First off, BSIMM9 is bigger. We have more data than we had for BSIMM8, and the scope of the organizations we assessed is larger—the developer population grew by 43%. But the number of people involved in software security increased even more, by 65%. The difference in growth between these populations could reflect one of many possibilities. But maybe firms (and their boards) are simply more aware of the resources needed to produce real software security, not just software security theater.
|Total SSG and satellite||4,769||7,891||65%|
In addition to the six verticals from BSIMM8—financial services, independent software vendors (ISVs), healthcare, cloud, Internet of Things, and insurance—we added two new ones, technology and retail. And retail has already proven itself as one to keep an eye on.
Retail has just 10 firms in the pool; its average SSG is only 3.2 years old and has fewer than eight full-time people. But as a vertical, retail already beats the BSIMM pool in the practices of Configuration Management and Vulnerability Management, Software Environment, and Architecture Analysis, while keeping apace in all other practices—except Compliance & Policy. (Retail’s stellar debut also shines a spotlight on the healthcare and insurance verticals, which lag badly.)
We noticed a trend this year in the convergence of the cloud, IoT, and ISV verticals: Their charts are all starting to look the same. That’s probably because they all create software, and software (no matter what it’s used for) is all starting to look the same. It’s lighter on the front end, it’s heavier on the back end, everything’s connected, and it’s all in the cloud.
Organizations still face tough questions around how and when to deploy tools as part of their software security initiatives. However, armed with the BSIMM, they no longer suffer the uncertainty of answering those questions in a near vacuum.
—Jacob West, BSIMM author and vice president of cloud operations, Oracle
We’ve also added three new activities to the 113 in BSIMM8, for a total of 116 in BSIMM9. Not surprisingly, all three are in the practice of Software Environment—because they’re all related to the cloud.
Containers make deploying fast, easy, and (most importantly) scalable. But because of that, you need to fully ensure your containers are secure before releasing them into the wild. With orchestration, you can secure your containers as easily as you containerize your applications.
While it’s theoretically possible to secure software you don’t even know you have (maybe you just enjoy downloading all the patches on patch day), why make it difficult? Find out what’s in your environments, including components, dependencies, configurations, external services, and so on.
Your cloud services provider offers a range of security features in your cloud environment. But in the end, you’re the one responsible for protecting your data wherever it is, whether it’s in transit or at rest. Cloud security, like software security, starts with the basics. (But it doesn’t end there.)
You might have read an earlier version of the BSIMM. You might even have had a BSIMM assessment. Or you might be new to the SSI-measuring party, in which case we welcome you. In any case, we encourage you to download BSIMM9 (again, it’s free) and consider how your organization could improve its software security initiative—or start one, if you don’t have one already. Software security is never going to get easier, but by sharing what we know, learning from one another’s mistakes, and always building on existing best practices, we can make it better.