Introduction to OWASP Software Assurance Maturity Model Introduction to OWASP Software Assurance Maturity Model

By Mark Stenbäck


This blog entry is about OWASP SAMM, which stands for Software Assurance Maturity Model, and it is intended as an introduction to the framework that can help to further enhance software security as part of Software Development Lifecycle.

“SAMM (Software Assurance Maturity Model) is the OWASP framework to help organizations assess, formulate, and implement a strategy for software security, that can be integrated into their existing Software Development Lifecycle (SDL). SAMM is fit for most contexts - whether your organization is mainly developing, outsourcing, or rather, focusing on acquiring software, or whether you are using a waterfall or an agile method - the same model can be applied.” (SAMM Quick Start Guide)

The Software Assurance Maturity Model v1.5 is based around a set of 12 security principles, which are divided into four business functions. However, the upcoming version 2.0 will extend this to 15 security principles in five business functions. The goal is to provide an effective and measurable way to analyse and improve an organization’s software security practices. This covers an entire software development lifecycle while being technology and process agnostic.

SAMM was originally introduced in 2009 as version 1.0 while the current release is version 1.5. At the time of writing this text, it is expected that the 2.0 release will be completed sometime around Q4/2019-Q1/2020.

The SAMM 2.0 is designed to be development paradigm agnostic, which means it can be applied to all kinds of projects ranging from waterfall to agile to DevOps as well as to some yet to be conceived models. As mentioned above, SAMM 2.0 has 15 security principles or practices. Each of these is divided into two “streams”, and each stream has an objective. A stream specific objective can be reached at various levels of maturity:

  • Level 0: an implicit starting point with the Practice unfulfilled
  • Level 1: an initial understanding and ad hoc implementation of the Practice
  • Level 2: structured realization with increased efficiency and effectiveness of the Practice
  • Level 3: a comprehensive mastery of the Practice at a scale that comes with an optimized operation.

Among other things, for each level, SAMM defines an objective, a set of activities and describes expected results.

The following two sites are the primary sources for SAMM documentation:

The following chapters provide a brief overview of the five business functions along with each function’s three security practices.

1 Governance

As a business function, Governance is about processes and activities related to how an organization manages its software development activities. This is covered by the following three security practices.

1.1 Strategy & Metrics

It is essential to have an overall plan when working on any kind of project. Without an overall plan, it is difficult, if not impossible to keep various project efforts aligned, proportional and ultimately productive. Therefore the goal of this practice is to build an efficient and effective plan for realizing the software security objectives within an organization that is both measurable and aligned with the business risks.

A: Create & Promote B: Measure & Improve
Maturity Level 1: Identify objectives and means of measuring effectiveness of the security program. Identify organisation drivers as they relate to the organisation’s risk tolerance. Define metrics with insight into the effectiveness and efficiency on the Application Security Program.
Maturity Level 2: Establish a unified strategic roadmap for software security within the organisation. Publish a unified strategy for application security. Set targets and KPI’s for measuring the program effectiveness.
Maturity Level 3: Align security efforts with the relevant organisational indicators and asset values. Align the application security program to support the organisation’s growth. Influence the strategy based on the metrics and organisational needs.

1.2 Policy & Compliance

In many ways, security issues are strongly anchored to internal and external laws, standards and regulations. Therefore, it is important to describe an organization’s standards as well as 3rd party obligations (such as laws and regulations) as application requirements in order to ensure that they are taken into account at all stages of application’s lifecycle.

A: Policy & Standards B: Compliance Management
Maturity Level 1: Identify and document governance and compliance drivers relevant to the organisation. Determine a security baseline representing organisation’s policies and standards. Identify 3rd-party compliance drivers and requirements and map to existing policies and standards.
Maturity Level 2: Establish application-specific security and compliance baseline. Develop security requirements applicable to all applications. Publish compliance-specific application requirements and test guidance.
Maturity Level 3: Measure adherence to policies, standards, and 3rd-party requirements. Measure and report on the status of individual application’s adherence to policies and standards. Measure and report on individual application’s compliance with 3rd-party requirements.

1.3 Education & Guidance

While having strategies and metrics as well as policies and rules (not to mention good intentions) is important, it all works even better when people working within the organization are provided the necessary training, knowledge, and resources to design, develop and deploy secure software. This needs to be a systematic, continuous process as it is not enough to simply train a person once and expect him or her to be all-knowing and flawless in the future duties after that. No, it requires a change in the organization’s culture to support its members in their efforts to keep on learning as a continuous process.

A:Training & Awareness B: Organisation & Culture
Maturity Level 1: Offer staff access to resources around the topics of secure development and deployment. Provide security awareness training for all personnel involved in software development. Identify a “Security Champion” within each development team.
Maturity Level 2: Educate all personnel in the software lifecycle with technology and role-specific guidance on secure development. Offer technology and role-specific guidance, including security nuances of each language and platform. Develop a secure software centre of excellence promoting thought leadership among developers and architects.
Maturity Level 3: Develop in-house training programs facilitated by developers across different teams. Standardised in-house guidance around the organisation’s secure software development standards. Build a secure software community including all organisation people involved in software security.

2 Design

As a business function, Design is about processes and activities related to how goals are defined and how software is being created within projects. In other words, this is about product management, requirements specifications, understanding potential threat models, and high-level architecture design from the security perspective.

2.1 Threat Assessment

The need for security flows from the acknowledged existence of threats - this is one of those things where the increase of knowledge also increases pain, and yet it is small compared to the potential pain that tends to follow when a realization of an unknown threat takes us surprised and unprepared. Therefore, it pays to identify risks in applications and to treat them accordingly.

A: Application Risk Profile B: Threat Modelling
Maturity Level 1: Best-effort identification of high-level threats to the organisation and to individual projects. Basic assessment of the application risk. Best effort ad hoc threat modelling.
Maturity Level 2: Standardization and enterprise-wide analysis of software related threats within the organisation. Understand the risk for all applications in the organisation. Standardized threat modelling.
Maturity Level 3: Proactive improvement of threat coverage throughout the organisation. Periodically review application risk profiles. Improve quality by automated analysis.

2.2 Security Requirements

These requirements are considered within the context of secure software. For example, how the service can be protected and what how sensitive is the data it contains. From software security’s perspective, it is also important to take a look at the suppliers, especially when outsourcing any of the development work.

A: Software Requirements B: Supplier Security
Maturity Level 1: Consider security explicitly during the software requirements process High-level application security objectives. Evaluate the supplier according to security
Maturity Level 2: Increase granularity of security requirements derived from business logic and known risks Structured requirements engineering Build security into supplier agreements
Maturity Level 3: Mandate security requirements process for all software projects and 3rd party dependencies Build a standard requirements framework Ensure proper coverage for external suppliers

2.3 Security Architecture

Software architecture tends to quickly grow into a complex mesh of in-house code, software components, and 3rd party frameworks and libraries even when there are no external services to be integrated with. The architecture is secure only when security considerations are applied to all the parts that it consists of as well as to the design work itself.

A: Architecture Design B: Technology Management
Maturity Level 1: Insert consideration of proactive security guidance into the software design process Use basic security principles Elicit technologies, frameworks and integrations within the overall solution
Maturity Level 2: Direct the software design process toward known secure services and secure-by-default designs Establish common design patterns and security solutions Standardise technologies and frameworks to be used throughout the different applications
Maturity Level 3: Formally control the software design process and validate utilization of secure components. Create Reference Architectures Impose the use of standard technologies on all software development

3 Implementation

As a business function, Implementation is about processes and activities related to establishing reliable, automated methods for building and deploying applications, dependency management and keeping track of defects. The actual implementation work like design and programming is more related to Software Development Lifecycle (SDL) practices

3.1 Secure Build

It is important to be able to produce consistently repeatable builds, and this is best done by having an automated build environment that is based on reliable software components and services. The less manual work a build requires, the better. An automated build pipeline can perform automated regression and integration tests as well as include static/dynamic application security testing (SAST, DAST) mechanisms.

A: Build Process B: Software Dependencies
Maturity Level 1: Build process is repeatable and consistent The build process is defined and consistent All application dependencies are identified and documented
Maturity Level 2: Build process is optimised and fully integrated into the workflow The build process is fully automated and does not require intervention by the developer All components and libraries are periodically reviewed for known security vulnerabilities and licensing issues
Maturity Level 3: Build process helps prevent known defects from entering the production environment Security defects may trigger the build to stop executing Components and libraries are independently scanned for vulnerabilities

3.2 Secure Deployment

While it is essential to consider security aspects during the software’s design and implementation, the same work must carry over the deployment as well. This begins by automating the deployment process as much as possible in order to reduce (if not entirely remove) the chances for human errors and to maintain consistently repeated processes with necessary checks and logs. Equally, if not more, importantly the deployment process must protect the foundations for privacy and maintaining control over sensitive data such as private keys, passwords, and other tokens as well as the integrity of data storages.

A: Deployment Process B: Secret Management
Maturity Level 1: Deployment processes are fully documented Deployment is automated or done by someone other than the developer Production secrets are encrypted and not handled by developers
Maturity Level 2: Deployment processes include security verification milestones Integration of security verification in deployment (e.g. binary static code analysis / AV scan) Secrets are dynamically included during the deployment process
Maturity Level 3: Deployment process is fully automated and incorporates automated verification of all critical milestones Integrity of the code is verified prior to deployment Files and repositories are checked periodically for secrets that should be protected

3.3 Defect Management

There is no such thing as flawless software that has no bugs; not having any issues should be a cause for concern as opposed to relief as it is all but guaranteed that whatever issues testing might miss, those will be discovered in production. Defects and software go together like a house on fire so it pays to establish a controlled process to collect, record and analyse software (security) defects to enable metrics-based decision making.

A: Defect Tracking B: Metrics & Feedback / Learning
Maturity Level 1: All defects are tracked within each project Track all defects Calculate and share basic metrics, such as total counts
Maturity Level 2: Defect tracking used to influence the deployment process Assign SLA based security rating on the defect Calculate more advanced metrics that include new issue velocity, remediation speed metrics, and trends.
Maturity Level 3: Defect tracking across multiple components is used to help reduce the number of new defects Measure and enforce compliance with the SLA Use trend analysis to influence changes in the Design and Implementation phase across multiple projects.

4 Verification

As a business function, Verification is about processes and activities related to quality assurance such as organization checks and test artefacts produced throughout the software development. This includes also other review and evaluation activities in addition to typical QA work.

4.1 Architecture Assessment

Architecture is reviewed from the security’s point of perspective: identify application and infrastructure architecture components, list all the interfaces and their security-related functionalities as well as having a list of security mechanisms. Both the application and supporting infrastructure architectures need to be validated against known threats and existing security requirements.

A: Architecture Validation B: Architecture Compliance
Maturity Level 1: Review the architecture to ensure baseline mitigations are in place for known risks Identify application and infrastructure architecture components Ad hoc review of the architecture against compliance requirements
Maturity Level 2: Review the complete provision of security mechanisms in the architecture Validate the architecture security mechanisms Analyse the architecture against known security requirements and best practices
Maturity Level 3: Review the architecture effectiveness and feedback results to improve the security architecture Review of the architecture components effectiveness Feedback the architecture review results into the enterprise architecture, organisation design principles & patterns, security solutions and reference architecture

4.2 Requirements Driven Testing

Security testing includes both positive and negative test cases. At least this should cover the standard security controls as well as using fuzzing to verify the input validations. Come up with misuse and abuse cases for the application to identify the potential attack and exploit scenarios. Use regression testing to verify that squashed bugs stay that way instead of reintroducing them in some later revision. Nothing should be merged nor deployed unless it at the very least passes the existing tests.

A: Control Verification B: Misuse / Abuse Testing
Maturity Level 1: Opportunistically find basic vulnerabilities and other security issues Test for standard security controls Perform security fuzzing testing
Maturity Level 2: Perform implementation review to discover application specific risks against the security requirements Derive test cases from known security requirements Create and test abuse cases and business logic flaw test
Maturity Level 3: Maintain the application security level after bug fixes, changes and/or during maintenance Perform regression testing (with security unit tests) Denial of service and security stress testing

4.3 Security Testing

Security testing should be a routine part of development and deployment. While automated tests can scan code base and perform static analysis better than humans, they lack the contextual awareness necessary to understand the business logic and more complex attack vectors. So both automated and manual security testing is required. The main body of this testing work should be based on granular test cases based on the application’s intended functionality and requirements. Additional issues should be reviewed and handled as necessary.

A: Scalable Baseline B: Deep Understanding
Maturity Level 1: Perform security testing (both manual and tool based) to discover security defects Utilise automated security testing tools Perform manual security testing of high risk components
Maturity Level 2: Make security testing during development more complete and efficient through automation complemented with regular manual security penetration tests Employ application specific security testing automation Conduct manual penetration testing
Maturity Level 3: Embed security testing as part of the development and deployment processes Integrate automated security testing into the build and deploy process Integrate security testing into development process

5 Operations

As a business function, Operations is about processes and activities related to release management, deployment, and maintenance. This covers topics such as issue management, hardening the operational environment against discovered vulnerabilities

5.1 Incident Management

It is all but guaranteed that an application will be faced with defects and incidents once it has been deployed into production: the probability is higher with an application that is directly exposed to the Internet and the hordes of users, but no system is truly safe (unless it is contained within a solid block of concrete at the bottom of the ocean). In this context, a security incident is a breach or threat of an imminent breach of at least one system asset due to malicious or negligent behaviour such as a denial of service attack or unauthorized data access. Once a security incident has been identified it is essential to limit the exposure and exercise damage control by acting in an organized and premeditated manner.

A: Incident Detection B: Incident Response
Maturity Level 1: Best effort incident detection and handling Best effort incident detection with available log data Defined high-level incident response strategy
Maturity Level 2: Formal incident management process in place Automated log evaluation driven by process Root Cause Analysis with a feedback loop
Maturity Level 3: Mature incident management Reliable timely incident management Proactive incident + emergency exercises

5.2 Environment Management

In order to maintain secure production environment, a proactive approach is required: new security features and patches are being continuously released just as new threats and vulnerabilities are being discovered. An organization that adopts reactive practices instead of striving to be proactive makes a conscious choice to do too little too late. It is vitally important to actively maintain keep up with information about new vulnerabilities and to react in a timely fashion.

A: Configuration Hardening B: Patching & Updating
Maturity Level 1: Best effort patching and hardening Prioritised best effort hardening Prioritised best effort patching
Maturity Level 2: Formal process with baselines in place Hardening baseline and guidelines available Formal process covering the full stack
Maturity Level 3: Conformity with continuously improving process enforced Detection and handling of non-conformities Consolidating update process with SLA and reporting

5.3 Operational Management

It is not enough to focus on just the application’s security aspects. Security must also be part of the supporting operational activities such as system administration, database administration, backup administration and so on. It is not possible to maintain application security if the underlying service infrastructure and processes have vulnerabilities.

A: Data Protection B: System Decommissioning / Legacy Management
Maturity Level 1: Foundational practices Basic data protections in place Identification of unused and legacy applications / services
Maturity Level 2: Managed, responsive processes Data is catalogued and data protection policies are established Decommissioning and legacy migration processes are in place
Maturity Level 3: Active monitoring and response Data policy breaches are detected and acted upon Proactive and reliable handling of legacy applications / services


The best way to get started with SAMM is simply by taking the first step and begin using it without too much worrying about “doing it right”. It is an iterative process so it is quite alright to spend the first cycle or two to just learning the ropes.

A common iterative cycle includes phases:

  1. Prepare
  2. Assess
  3. Set the target
  4. Define the plan
  5. Implement
  6. Roll-out (followed by Assess when the next cycle begins)

The OWASP SAMM websites provide plenty of helpful documentation, such as the Quick Start Guide for SAMM 1.5

You are also more than welcome to contact us to have our professionals to help you get started and to further support your organization in adopting SAMM and Software Development Lifecycle (SDL) methodology in general.