August 29, 2022

Last Updated on August 20, 2024

In software security circles, the Building Security in Maturity Model (BSIMM) is among the most trusted frameworks for improving your security posture. But the equally popular and proven OWASP Software Assurance Maturity Model V2 (OWASP SAMM) is gaining momentum and interest.

What do these two maturity models have in common, how do they differ, and which is right for your development team?

To review everything you need to know about OWASP SAMM, a recent episode of The Virtual CISO Podcast features Taylor Smith, Network & Application Penetration Testing Lead at Pivot Point Security. Pivot Point Security CISO and Managing Partner, John Verry, hosts the show.

Intro to BSIMM and SAMM

First published in 2009, BSIMM categorizes 122 “real-world” activities to assess software security across 12 practices organized into 4 domains: Governance, Intelligence, SSDL Touchpoints, and Deployment.

Descriptive rather than prescriptive, BSIMM is not a how-to guide. Its goal is to help you determine where your program stands today and how best to enhance it. However, it emphasizes alignment with its control set as a way to achieve software security.

Also dating to 2009, SAMM is an effort to “take software security to the next level” by combining an industry proven maturity standard with the wealth of OWASP resources, especially its Application Security Verification Standard (ASVS). SAMM’s mission is to provide an effective and measurable way to analyze and improve your secure development lifecycle.

Similar to BSIMM, SAMM organizes its practices into 5 business functions that encompass the complete software development lifecycle (SDLC): Governance, Design, Implementation, Verification, and Operations. SAMM is intended to be adapted in concert with iterative risk assessment to drive continuous improvement in your software security program.

How SAMM and BSIMM differ

As Taylor notes, SAMM and BSIMM have a common ancestor, and BSIMM essentially started life as an offshoot of SAMM.

“BSIMM is very narrative and very concrete,” offers Taylor. “Whoever wrote BSIMM had a good sense of humor.”

Whereas SAMM is prescriptive at a high level, BSIMM is descriptive. BSIMM is structured to “observe and report,” not to offer guidance. BSIMM is also not as flexible as SAMM.

“BSIMM is there to determine if you are meeting the guidelines set by the BSIMM security model,” Taylor notes. “It’s a maturity model, but in being descriptive it’s going in and seeing things as they are, defining them and scoring them. While SAMM is meant to do something similar, but with more of a focus on continuous improvement rather than trying to get the best score.”

In fact, SAMM explicitly states that its goal isn’t to get you to compliance with a standard. SAMM aims to help you meet the security requirements that fit with your business strategy and, by extension, your application development strategy. BSIMM, on the other hand, is more overtly concrete, in that it specifies the requirements you need to meet.

“One of the metaphors I’ve seen used is, BSIMM is walking into a room and saying, ‘You don’t have any lights in here,’” relates Taylor. “SAMM is going into a room and saying, ‘You don’t have any lights in here. Here are your five different options for how you can meet this requirement.’”

The importance of context

Pivot Point Security recommends SAMM to its SaaS clients and others that develop and sell software.

John explains that SAMM’s greater flexibility and its applicability to a huge range of orgs is a key reason why Pivot Point Security favors SAMM over BSIMM for clients that aren’t already using a maturity model approach to software security.

“A, we’re huge fans of OWASP and are already using the OWASP ASVS,” says John. “And B, that type of more helpful guidance is why we tend to lean more towards SAMM. But if someone uses BSIMM well, they’ll also end up in a good spot.”

“In our case, we need a lot of that flexibility because we have clients from every type of business, every maturity level and all across the globe,” Taylor replies. “With SAMM, we’re getting something that is a lot more case specific. So if we come across something that just doesn’t fit what BSIMM might require, we can work with the client in a way that makes more sense for their use case.”

In short, like its ASVS and other OWASP guidance, SAMM does a good job enabling the user to define their context and adapt the framework to it.

What’s next?

To hear this podcast episode with software security expert Taylor Smith, click here.

Want some background on the OWASP ASVS? This podcast will help you get oriented: EP#11 – Daniel Cuthbert – OWASP ASVS: The Go-To Standard for Application Security