OWASP Software Assurance Maturity Model has been a "flagship" project for several years and I am excited to announce the second version is finally ready to be released. This new model is a product of extensive efforts by a global team of application security professionals led by Sebastian and Bart. While we preserved the general model ideals between versions 1.5 and 2.0, several notable changes mimic the evolution of application development methodologies and programming languages. While it may seem drastic at first glance, especially as compared to SAMM 1.5, we deemed these changes necessary to make the new model effective at helping an organization measure and mature its application security programs.
Over the course of the next few months, I will share a series of blogs to explain the changes and help organizations get started with SAMM 2.0. The new model is intended to be agile and dynamic enough to 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 a significant improvement from the way SAMM was initially published and a sizable divergence from the typical management of most maturity models or frameworks today.
Programming is getting a lot easier than it used to be. I still have nightmares about staying up until the wee hours of the morning running a compiler over and over until I eventually find a syntax error causing the entire application to fail. Today, I can "Google" my way through just about any function, in many cases finding existing modules to leverage and avoid writing the code myself. While I was thrilled to see my programming skills (let's be honest…more like scripting) ramp up and write several small programs to help with my daily tasks, I suspected my way of solving problems was not efficient. This suspicion was quickly confirmed as soon as I asked a professional developer to peer-review my code.
Enabling the inexperienced programmer to write code and create lots of applications caused businesses to flourish and solve problems faster than ever before...but simultaneously created many risks of insecure code responsible for managing access and protecting sensitive data. Generally speaking, these issues could be relatively easy to identify using modern static and dynamic code analysis tools, but 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 are second nature to most professional developers, but I assure you, they are mostly invisible and intimidating to security and internal audit professionals. Even those of us who try to increase our understanding of application development actively face significant challenges when tasked with evaluating an SDLC practice or building a roadmap to improve application security.
SAMM 1.0 initially released in 2009 and primarily 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 explaining the different security practices. Over a few years, the SAMM core team spent much 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 and Waterfall and can be used to help evaluate legacy and modern development environments.
The “DevOps Release”
SAMM 2.0 has been dubbed the “DevOps Release” for many reasons, but the most obvious, of course, is to highlight coverage of the Agile development methodologies, as this was the driving force behind the need for change. The methodology the SAMM team used (and plans to use in the future) for changing and updating the model is much more exciting; unlike its predecessor, we will not maintain SAMM 2.0 as a single document. 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, manage future changes, and make sure that all changes are available in real-time using a CI/CD pipeline.
Soliciting feedback on an ongoing basis and continuously improving guidance will help the framework remain viable as technology and development methodologies continue to evolve. While changes to the structure and scoring model of SAMM will stay infrequent, the guidance and supporting resources will continue to grow and include the latest and best ideas for maturing application security programs.
The next few blogs will focus on each business function, covering related security practices and activities, followed by an article 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 released a free online tool to calculate your SAMM score. Our goal is to increase awareness of SAMM 2.0 and help drive companies to evaluate SAMM and contribute feedback for ongoing improvements of the model. In the meantime, anyone can get started by visiting owaspsamm.org and browsing through the latest version of SAMM.