Summarizing Open Software Assurance Maturity Model OpenSAMM Requirements

Download the Complete Article

Earlier, Information Security was all about protecting your network from malicious activities. But today, with the evolution of technologies and extended usage of devices and applications, information security has become a Business concern for any organisation. We now have to re-work on our development processes, methodologies to improve maturity of Application Security and adopt related Practices.

Many organisations have come up with their own frameworks to help this initiative keeping their Business requirements in view, however these frameworks lack flexibility and might be too complex for some organizations to adopt. Industry needs a model which is simple, defined and measurable. One such model is The Open Software Assurance Maturity Model (OpenSAMM), which is viable and can define building blocks for an assurance program.

About OpenSAMM

The Software Assurance Maturity Model (SAMM) developed by OWASP in 2009 is an open (free & vendor neutral)  framework assisting organizations in understanding, formulating and implementing Software Security strategy, which can be customized completely based on risk faced by the organization. 


  • Analyse existing Software Security Maturity state of an organization according to the followed practices and assurance programs
  • Build a balanced Software Security assurance program in a systematic and well-defined iterations
  • Demonstrate improvements in Security Assurance program and Software Security maturity
  • Define measurable Security activities across an organization.


Understanding the Model

At highest level, OpenSAMM defines 4 critical Business functional blocks, each providing 3 Security practices. So, in-total of 12 Security Practices, each practice is measured at 3 Maturity Levels, also called as Objectives.

To Summarize, we have,

4 Critical Business Functions (B.F.)

4 B.F. x 3 Security Practice = 12 Security Practices (S.P.)

12 S.P. x 3 Maturity Levels = 36 Objectives

Let’s, walk through these Business Functions, Practices and required objectives in brief:

A. Governance

Governance is all about the way Organization Manages Software Development Activities. It provides relations between effective Business Processes and Development groups, by providing effective measurable process and engagement rules.

1. Strategy & Metrics (SM)

This practice involves building Strategy to collect metrics defining organization’s Security posture. It assists in establishing a framework within organization for a Software Security Assurance program.


Strategy & Metrics Practice has 3 related Objectives, focussing on Establishment of Strategic Roadmap, which assist in measuring Data and other Software Asset values based on Business Risk. It also help is assessment of possible Security expenditure required to maintain Security posture.

2. Policy & Compliance (PC)

This practice primarily focuses on external legal and regulatory requirements and driving internal Security Standards to ensure required business purpose and compliances are met.


Policy and Compliance Business Practice has 3 related objectives, focussing on understanding of relevant governance and compliance requirements to the organization. This understanding assists in establishing Security Baseline (Policies and Standards) and related practices. It also assists establishing required compliance/quality gates for projects. Overall objective is to understand pre-project Risk and establish measures to manage them.

3. Education & Guidance (EG)

This practice is all about ensuring Educating and Guiding workforce involved in Software Lifecycle with required knowledge and resources to design develop and deploy secure software. This practice assist teams in proactively identify and mitigate related Security Risk in their domain.


Primary objective of Education and Guidance practice is to educate all personnel in Software life-cycle on Security Requirements and provide guidance according to their Role. Like, Developers should be trained on Secure Programming and Deployment practices. It also includes providing mandatory awareness Security Training and Certification programs.

B. Construction

Construction concerns the processes and activities related with Business Goals and Development projects. Overall it defines process of Building an Application, which includes activities related with Product management, Requirement gathering, High-level Architecture specification, detailed Design and implementation analysis.

1. Threat Assessment (TA)

This practice involves identification of project level Functional Threats and Risk to Software. Processes like Threat Modeling assist in such analysis.


Primary objective of this Security Activity is to identify and understand impact of possible Threats to an organization and project, assisting organization to granularly define and implement Security Controls. This includes threats against both internal and third-party software.

2. Security Requirements (SR)

This practice is all about building proactive practices, providing expected Software security behaviour. As a part of project initiation, security requirements along with functional expectations are collected for high-level business purpose.


Mandated across projects, objective of this practice is to ensure Security explicitly during Software requirement gathering process. This increase granularity of Security controls against business logics and known risk including from 3rd party dependencies and SLAs.

3. Secure Architecture (SA)

This can also be taken as a pro-active Security practice to ensure Security is ensured by default in Software Design itself.


Primary objective of this practice is to consider security in Software design and related processes itself by using known secure services and design principles. Establishment of formal reference security design architectures and patterns are done as a part of that 

C. Verification

As name suggest, it is related with verification and testing of Software. It focuses on processes and activities related to how organization review and analyse (test) produced entities throughout Software development.

1. Design Review (DR)

This practice is focussed on assessment of Software design and architecture for security concerns. It involves detailed data-level design inspections and enforcement of Baseline expectations at design level.


Identification of Software Attack Surface, analysis against known Security Requirements, Development of Data flow diagrams and inspection of complete Security mechanism are few objectives of this process. It also includes adding requirements in Release Gates related with design review, which needs to be applied across projects.

2. Code Review (CR)

This practice focuses on software source code inspection for Security vulnerabilities. It involves integration of Code review practices in development process and setting measurable expectations for same.


Objectives include creation of review checklist from known security requirements followed by both Automated and Manual code analysis process. It also includes adding requirements in Release Gates related with secure code review, which needs to be applied across projects.

3. Security Testing (ST)

This practice focuses on software inspection in runtime environment for Security concerns. It also involves adding Security Functional aspects in automated environment. Security testing results should play major role in project release acceptance criteria.


Primary objective of this Security practices is to at least establish a process of performing basic security test based on implementation and Software requirements and then further effectively automate the complete process. Security testing phase should be part of Release Gate criteria.

D. Deployment

Deployment business requirement talks about processes and activities related with Software release procedures. This also includes how products are shipped to end users, deployment of same and expected operations in runtime environment.

1. Vulnerability Management (VM)

Vulnerability Management practices defines the required processes for handling Vulnerabilities and Operational incidents. It talks about methods of collecting information from reports and analysing root case for the concern. 


This includes building of High Level Plan for effective Vulnerability or Incident Management, which may involve creation of Security Response Team and establishment of Incident Response process for same. Along with these, a process should be established to effectively conduct root-cause analysis and collection of incident metrics.

2. Environment Hardening (EH)

This practice assists in hardening of Security posture in the surrounding environment of Deployed Software.


This includes maintaining of operational environment specification along with identification and installation of Security upgrades and patches. Establishment of Patch Management process is a part of Environment Hardening practices. Along with these, consideration should be taken on deployment of required operation protection tools and expansion of audit program to analyse environment configuration.

3. Operational Enablement (OE)

This Security practice primarily focuses on communicating Secure Deployment and other critical information to end-users. Providing details on Security configuration, features and Best Practices are part of same.


Primary objective here is to document procedures especially alerts and critical security information in form of Operational and Security Guides. This also involves creation of pre-release change management procedures. Effective validation criteria should be established like Code Signing etc. Audit program should also be expanded for this prospect.


Building Assurance Program

The main purpose of using SAMM is to build a software assurance model for an organisation. This process begins with the Security assessment using existing model in the organisation. After the assessment, OpenSAMM proposes several roadmaps templates to choose from. Organizations can further customize their roadmap based on these templates, which explains which section of Security practice needs improvement and try to achieve the required level.


The Open SAMM Model is quick and easy to deploy and will help organisations to improve their Software Security state by building Assurance Program, according to organisation structure and understanding. It allows them to do self-assessment with some guidance to gain valuable insights on their Software assurance matters and help Demonstrate concrete improvements to their security assurance program. Their future plan also includes mapping them with existing standards like ISO, PCI and more.

Hack2Secure can assist organizations in analysis and adoption of OpenSAMM model for Secure SDLC process implementation. Our Training, Certification, Consultation, Testing and Assessment services can assist organizations across the OpenSAMM model requirements.

Download the Complete Article

    All Comments (0)

    No one has commented yet.

Leave a comment