Why Maturity Models are Needed in the First Place

The maturity model is a framework that describes the different stages of organizational maturity in a particular domain, such as project management or software development.

However, not every organization needs to follow a predefined maturity model in its entirety. Instead, organizations can "right-size" the maturity model to fit their specific needs and resources. By right-sizing the maturity model, you can develop a framework that is tailored to your organization's specific needs and goals, rather than trying to fit your organization into a predefined framework that may not be the best fit.

Software security maturity models are frameworks that provide a structured approach for organizations to evaluate and improve their software security practices. Security maturity models are frameworks that organizations can use to assess and improve their cybersecurity posture over time. Security endures a complexity that requires a systematic approach.

As with any new initiative/program, introducing a security programs is extremely challenging for organizations

• First of all, an organization’s behavior changes slowly over time. Hence changes need to be smaller and iterative to really take hold and make a difference.
• Secondly, there is no single recipe that works for all organizations. 
• Thirdly, guidance related to security activities must be prescriptive.

Why this blog, and what is YAAMM?

As the topic of this blog suggested, one may quite rightly ask why the Purple Book Community (PBC) has assembled a team to generate Yet Another AppSec Maturity Model (YAAMM). 

It’s a fair question. After all, what’s wrong with OWASP SAMM (Open Web Application Security Project Software Assurance Maturity Model)? Frankly, nothing - SAMM does what it claims. Doesn’t BSIMM (Building In Security Maturity Model) measure maturity? Within some fairly tight constraints, yes.

There are several different security maturity models available, but they all generally follow a similar structure. Some of the most widely recognized ones are:

• Capability Maturity Model Integration for Development (CMMI-DEV) - This is a comprehensive framework that covers all aspects of software development, including security. The CMMI-DEV model provides a set of practices and processes that organizations can use to improve their software security maturity.
• Building Security In Maturity Model (BSIMM) - This model is based on real-world data from hundreds of organizations and provides a detailed description of the software security practices observed in these organizations (a “capabilities” model). The BSIMM model is divided into several domains, such as governance, intelligence, and assurance, and provides specific activities and metrics for each domain.
• Open Web Application Security Project (OWASP) Software Assurance Maturity Model (SAMM) - This model is designed specifically for web application security and provides a framework for organizations to assess and improve their application security practices. The SAMM model is organized into four categories: governance, construction, verification, and deployment.

These maturity models can help organizations assess their current security practices and identify areas for improvement. By adopting the recommended practices and processes, organizations can improve the security of their software products and reduce the risk of security incidents.

 We are sure that there are others. 

Existing models: what they offer and potential weaknesses

"The overall increase in maturity of firms shows continued and growing investment," he explained, "and the growth of BSIMM membership in new verticals—cloud software, insurance, healthcare, and most recently Internet of Things (IoT)—shows that software security is becoming an important focus for firms outside the traditional areas of financial services and software."

In a landscape where organizations are rushing toward digital transformation, secure code becomes more important than ever, added Jeff Williams, CTO and co-founder of Contrast Security, an application protection company. "The BSIMM itself doesn't measure or demonstrate anything about the criticality of software security," he said.

Here are a few weaknesses of existing models:

• Limited scope: Both BSIMM and SAMM primarily focus on software security practices and may not provide a complete picture of an organization's overall security posture. It does not cover other important areas such as network security, physical security, or employee training.
• Inflexibility: Both models may not be applicable to every organization or industry, and it may not be flexible enough to accommodate specific needs and requirements.
• Reliance on self-assessment: The models are based on self-assessment, which means that an organization's results may be skewed by internal biases or the inability to accurately assess their own security practices.
• Limited guidance on implementation: While both BSIMM and SAMM provides a framework for measuring and improving software security practices, it does not provide detailed guidance on how to implement specific security practices or processes.
• OWASP SAMM has five dimensions, each with three subareas, which are then broken down into three maturity levels. That’s 15 different areas to assess for current state and improvements. Plus, OWASP’s mandate is web security. Lots of software has nothing to do with the web, but still needs AppSec.
• BSIMM measures what each participant organization does. The capabilities measured are built from the universe of what has been done at all the member organizations, not necessarily what is effective (though BSIMM measures how effective each capability is). 
• BSIMM companies are almost universally large, financially successful, and have been doing information security for a long time. While the range of industries is fairly broad, the type of company is not. BSIMM measures the software security practices of large, financially stable organizations who care enough about AppSec to pay for a BSIMM. That’s a  fairly select group. Plus, being large and perhaps long-established, these companies’ development practices may not be at the cutting edge of development practice, which tends to move from startups and into larger, more established organizations.

Purple Book Community  Angle and Approach

The Purple Book Community believes that there’s room for another more inclusive (and thus more applicable) software security maturity model that:

1. Models up-to-date development practices and environments
2. Readily scales from small/startup to enterprise, leaving no organization out
3. Understands that required levels of maturity are contextual, and that every organization needn’t strive for the highest levels in all practices
4. Includes risk as a maturity driver
5. Is easily customized 

As an example: Brook Schoenfield, one of the maturity model team, worked on a model at McAfee circa 2015-16. One of the model’s co-authors, Harold Toomey, has repeatedly presented that model. Like McAfee, dissatisfied or just plain desperate teams repeatedly invent local models that more closely align with their AppSec program or that are easier to understand and follow. Therein lies the problem the Purple Book Community wishes to address:

Provide a capabilities-focused model that can easily be understood and readily implemented by all those involved in software development at any size organization. 

Extant models seem primarily targeted for security people and/or executives at larger, more complex organizations who must report on their AppSec security posture and capabilities. These simply don’t apply well to every organization that requires AppSec capabilities.

Consider an early stage company just starting on their security journey. Typically, there will be no dedicated security department, no security team. If there is anyone whose role is committed to security, they may very well be working solo. Governance, such as it is, is often “leaders’ best efforts.” So models that require a baseline application policy set at step 1, and security requirements for “all applications” to reach step 2, don’t really make much sense for a startup  (see https://owaspsamm.org/model/governance/policy-and-compliance/). We at PBC are asking, “What does such an organization need to start? And where are the most relevant next steps?”

Wrap Up

The Purple Book Community includes a rich collection of industry leaders, practitioners, thought leaders who we believe can collectively build a better “mousetrap” software security model intended not just for huge enterprises and long running programs, but for every organization that builds and operates software.