Press Release
Last Updated on January 18, 2024
What are the merits of the OWASP Software Assurance Maturity Model (SAMM), and how does it differ from OWASP’s Application Security Verification Standard (ASVS) framework? And why should you care?
From design to production, there are multiple crucial security considerations spanning from business functions to activities to controls to verification/validation.
Taylor Smith, Application Penetration Testing Lead at Pivot Point Security, provides insights into OWASP SAMM. She discusses definitions, the differences between SAMM, ASVS, and BSIMM, and how these models relate and can be used together in today’s software development environments.
Defining SAMM and establishing its importance
There is no shortage of acronyms in the information security world. While this can be intimidating for those not familiar with the ins and outs of information security, it doesn’t make the systems behind letters any less critical.
Taylor helps to clarify some vital systems and processes, starting with SDLC and SAMM. In simple terms, SDLC refers to the internal practice of developing software. Popularly depicted with anywhere from eight to thirteen steps, many SDLCs are growing in complexity as teams apply new techniques, tools and processes. While most SDLCs share commonalities, each org’s SDLC can look different.
SAMM is used to assess the maturity of an org’s software security program across the SDLC. First, it quantifies the maturity of an SDLC and analyzes its current level of secure functions. Then SAMM provides guidance to increase overall security and boost maturity. This maturity model is adaptable to meet the needs of different businesses and products.
“The whole goal of SAMM is for it to be an ongoing process of growth.” — Taylor Smith
The goal of SAMM is to support security throughout the entire software development lifecycle. While SAMM has been around for over a decade, it is generalizable and flexible enough to benefit any business that wants to build more secure software.
Organized into five business functions, each split into different security practices, SAMM allows organizations to understand their software security strengths and weaknesses, making it easier to identify what needs improvement and what they are doing right.
SAMM vs. ASVS, how they’re related, and what it all means
The Application Security Verification Standard, or ASVS, is complementary to SAMM. ASVS provides a list of controls that developers can use as a metric internally to build an app. However, buyers can also use it to test or validate existing applications. Finally, ASVS provides guidance on what controls should accomplish and how they relate.
In many cases, ASVS elaborates on requirements that SAMM approaches more generally. While SAMM is a more general and adaptable model, ASVS is more granular and technical. While either is extremely helpful on its own, their value compounds when utilized simultaneously.
SAMM provides the foundation, and ASVS delivers the specific, contextual, technical actions. Together, they offer comprehensive security coverage.
BSIMM: Origins similar to SAMM, but a completely different child
Building Security in Maturity Model, or BSIMM, has foundations similar to SAMM. However, they are significantly different.
SAMM is prescriptive, flexible, and adaptable.
In comparison, BSIMM is strict in nature. As a narrative model, it offers a wealth of detail. BSIMM is a descriptive system that helps you determine whether you meet the model’s requirements for software security.
“The goal isn’t necessarily to get the high score, it’s not to win the game. It’s to meet the security requirements that fit the needs of your particular business strategy, or your application development strategy.” — Taylor Smith
While SAMM is focused on continuous improvement, BSIMM has a more concrete, compliance-centric approach.
BSIMM helps determine the maturity of SDLC security. However, it does not offer insight into options for correcting any potential problems. In short, BSIMM will reveal existing problems and unmet standards but is not specifically designed to support continuous improvement.
Tangible business functions of SAMM
SAMM defines five business functions. Each function is then broken down into three practices (processes/activities).
For example, governance is one of SAMM’s business functions. Governance is then broken down into three practices: policy and compliance, strategy, and education and guidance.
Another SAMM business is design. Thinking about security during the software design phase can help make an application “secure to the core” so that it can be made compliant with application security standards and ship with minimal vulnerabilities. This returns to the idea of continuous improvement, where SAMM can guide ongoing security steps end-to-end within the SDLC.
“If you’re getting code from someone else, if you’re getting materials from someone else for testing, that falls into the requirements of design.” — Taylor Smith
Implementation is another SAMM business function. Its three practices include secure build, secure deployment, and defect management. This function requires basic protection measures, significant lifecycle tracking, and documentation, documentation, documentation.
Verification is also a SAMM business function. Verification requires ensuring that your security policies are performing as intended. This requires proper documentation for each process, conducting an internal review, and/or hiring a third party to conduct penetration testing, code reviews, and more.
SAMM plays a vital role in the quest for a secure SDLC. Paired with ASVS, businesses can garner strong support to achieve robust software security. Understanding SAMM can generate a pivotal movement towards optimized information security.
What’s next?
To listen to the podcast episode on Breaking Down the Latest in Software Security Standards & the Impact on SaaS Business, click here.
