Introduction

Background

OWASP Software Assurance Maturity Model has been designated as a “Flagship” project for several years, and I am excited to announce the second version of the model is finally ready to be released. This new model is a product of extensive efforts by a global team of application security professionals lead by Sebastian and Bart. While the general model ideals were preserved between versions 1.5 and 2.0, several notable changes mimic the evolution of application development methodologies and programming languages. These changes may seem drastic at first glance especially when compared to SAMM 1.5 but were necessary to make the new model effective at helping an organization measure and mature its application security programs.

Over the next month, I will publish a series of blogs to explain the new model and help organizations get started with SAMM 2.0. The new model is intended to be agile and dynamic enough to help accommodate the incredible velocity of change in the application development and subsequently application security methodologies. While these changes may seem natural and obvious for those seeing SAMM for the first time, they represent significant changes from the way SAMM was initially published, as well as a change from the way most maturity models or frameworks are managed today.

Evolution

I have been working in IT and Information Security industry for over 20 years, and in that time was fortunate enough to witness many changes in how the software is developed. The data perimeter yielded its role as the security battleground to applications, which are growing in numbers at an exponential rate. This change caught many security professionals off-guard and left a significant knowledge gap since most experienced security professionals are more likely to have a technical background focused mostly on servers, networks, and firewalls. I had this epiphany approximately 6-7 years ago made a significant investment in improving my understanding of the new software development methodologies, including actually learning to program in a few of the most common programming languages such as Python and JavaScript. While I took programming when I was in college, I found that most of my understanding of software structures needed to be updated to take advantage of the new technologies.

The biggest change that became immediately clear was programming getting a lot easier than it used to be. I still have nightmares about sitting through the night running a compiler over and over until I eventually find a syntax error causing the entire application to fail. Today, I found that I was able to “Google” my way through just about any function I was trying to write, in many cases finding existing modules I was able to leverage and avoid having to write code myself. While I was thrilled and flattered to see my programming (let’s be honest more like scripting) skills ramp up and allow me to write several small programs to help with my every-day tasks, I couldn’t help suspect that my way of solving those programs was not efficient but rather minimally functional. This suspicion was quickly confirmed as soon as I asked a professional developer peer-review my code.

Allowing less experienced people write code faster and create lots and lots of applications allowed businesses to flourish and solve problems faster than ever before… but also created many risks of insecure code responsible for managing access and protecting sensitive data. While these issues could be relatively easy to identify using modern static and dynamic code analysis tools, the growing number of applications within each organization’s portfolio made it easy for these problems to hide and linger for months or years. Combined with the decentralized nature of public cloud systems and multiple layers of abstraction in defining servers and layers of computing infrastructures many organizations are facing a growing challenge that’s still poorly understood by those responsible for protecting the organization from excessive security risks.

Identifying SAMM 1.5 Gaps

Many of the issues I described above may seem second nature to most professional developers, but I assure you, they are largely invisible and intimidating to security and internal audit professionals. Even those of us that tried to actively increase our understanding of application development find ourselves significantly challenged when tasked to evaluate an SDLC practice or build a roadmap for improving application security.

SAMM 1.0 was initially released in 2009 and was largely focused on supporting the waterfall development methodology. While many security practitioners found ways of interpreting the model to make it suitable for Agile software development methodology, it required many liberties with interpreting the different Security Practices. Over a few years, the SAMM core team spent a lot of time comparing SAMM to multiple DevOps maturity models to identify shortcomings and areas of the modern SDLC not covered by the existing model. SAMM 2.0 is intended to cover all aspects of DevOps as well as Waterfall and can be used to help evaluate legacy and modern development environments.

The “DevOps Release”

SAMM 2.0 has been dubbed as the “DevOps” release for many reasons. The most obvious one is, of course, to highlight coverage of the Agile development methodologies, as this was the driving force behind the need for change. However, the much more exciting change is the methodology the SAMM team used (and plans to use in the future) for changing and updating the model. Unlike its predecessor, SAMM 2.0 will not be maintained as a single document (a PDF version of the model may likely be published soon). The new SAMM is published as a static website auto-generated by a site generator and maintained in GitHub using markdown. The goal is to make it easy for the team to collect feedback (Issues), manage future changes (Branches, Pull Requests, and Versions), and make sure that all changes are available in real-time using a CI/CD pipeline.

The goal is to solicit feedback on an ongoing basis and continuously improve guidance to help the framework remain useful and viable as technology and development methodologies continue to evolve. While changes to the structure and scoring model of SAMM will remain infrequent, the guidance and supporting resources will continue to evolve and include the latest and best ideas for evolving and maturity application security programs.

Summary

The next five blogs will focus on each Business Function, covering related Security Practices and Activities, following by a blog focused on helping organizations get started with using the model and different approaches to calculating the SAMM scores. Concord is one of the sponsors of the SAMM project and over the next few weeks will be releasing a free online tool for calculating SAMM scores. Our goal is to increase awareness of SAMM 2.0 and to help drive companies to evaluate SAMM and to contribute feedback for ongoing improvements of the model. Until the next blog is published, anyone can get started by visiting owaspsamm.org and browsing through the latest version of SAMM.