Applying the OWASP Software Assurance Maturity Model (SAMM) in Your Environment

Last Updated on January 18, 2024

As dev/test teams increasingly seek to build security into the software development lifecycle (SDLC), the OWASP Software Assurance Maturity Model (SAMM) is proving its worth as both an assessment tool and as guidance for improvement.

How are forward-looking teams working with OWASP SAMM?

To talk about all aspects of using OWASP SAMM to improve software security and reduce risk, Taylor Smith, Network & Application Penetration Testing Lead at Pivot Point Security, joined a recent episode of The Virtual CISO Podcast. Hosting the show is John Verry, Pivot Point Security CISO and Managing Partner.

OWASP SAMM overview

OWASP SAMM lets you score your application security practices on a 1-to-3 scale, with 3 being most mature. You can use a decimal place after a score to fine-tune it (e.g., 1.5, 2.9, etc.).

At the end of an assessment, SAMM helps you evaluate whether each of your scores is or is not reasonable and appropriate given the risk associated with your application and the data it processes. If you need to improve, SAMM helps you set a target to achieve.

“SAMM is divided into five different business functions, and then each of those business functions is split into different security practices, with three security practices per business function,” reviews Taylor. “Each of those practices is scored on a 1-to-3 scale. And each practice also has a stream, which describes the activities you can perform to improve your maturity level for that particular security practice.”

During a SAMM assessment, teams use the above scoring methodology to come up with scores for each business function. The business functions (Governance, Construction, Verification, Operations and Assessment) are generic enough that most businesses can map them to their unique needs.

SAMM is prescriptive

SAMM is a “prescriptive” standard, where the streams and activities associated with the practices providing actionable guidance to move teams up the maturity ladder. The initial assessment is meant to be a starting point for a continuous improvement process.

Take as an example the Verification business function, which includes a security testing requirement. Stream A associated with security testing, which tends to be the easier of the two streams to achieve, is, “do automated testing.”

Stream B, which can jump you to the next maturity level for this requirement, is “perform manual security testing of high-risk components.” This requires skilled penetration testing efforts.

What’s next?

To listen to the complete podcast with Taylor Smith, click here.

Concerned about API security? Then don’t miss this podcast: Ep#97 – Rob Dickinson – What You Need to Know about APIs and API Security