The OWASP Software Assurance Maturity Model (SAMM) was first introduced in 2009 by Pravir Chandra as a practical guide to developing secure software. Since its inception, SAMM has evolved to keep pace with emerging technologies, threats, and industry standards. The most recent iteration of SAMM (Version 2.0), refines its structure and expands its applicability to modern development methodologies, including Agile and DevOps.

The OWASP Software Assurance Maturity Model (SAMM) is more than just a framework; it’s a roadmap for building secure, resilient software. By providing structured guidance tailored to an organisation’s unique needs, SAMM empowers development teams to address vulnerabilities proactively, align security with business goals, and adapt to an ever-changing threat landscape. Whether you’re starting your security journey or seeking to refine existing practices, SAMM offers the tools and insights needed to succeed in the face of modern cybersecurity challenges.

Organisations that embrace SAMM can expect several tangible benefits:

• Improved Security Posture: Systematic improvements reduce vulnerabilities and enhance resilience.
• Business Alignment: Security efforts that align with business goals are more likely to receive executive support.
• Measurable Progress: Maturity levels provide a clear framework for tracking progress and justifying investments.
• Scalability: SAMM’s flexibility ensures that it can be applied to organisations of any size, from startups to enterprises.

SAMM stands out as an open-source framework, tailored to meet the diverse needs of organisations across industries. It bridges the gap between business objectives and security requirements, offering actionable insights that can be applied at any stage of the Software Development Life Cycle (SDLC).

Robust Core Principles

The OWASP Software Assurance Maturity Model (SAMM) is built on four core principles:

Flexibility

SAMM adapts to organisations of all sizes and across various industries, recognising that security needs differ. For example, a financial institution with stringent compliance requirements may use SAMM differently from a tech start-up with a fast-paced development cycle.

Actionable Guidance

The framework provides detailed, step-by-step guidance for improving security practices. This includes templates, sample policies, and recommended tools to support implementation.

Business Alignment

SAMM ensures that security efforts align with overarching business objectives. For instance, integrating security into Agile workflows helps minimise disruptions while still meeting project deadlines.

Community Contribution

As an OWASP project, SAMM benefits from continuous updates and feedback from the global security community. This collaboration ensures that SAMM remains relevant in addressing current and emerging threats.

The Structure of SAMM

The OWASP Software Assurance Maturity Model (SAMM) is organised into five core business functions: Governance, Design, Implementation, Verification, and Operations. Each function is further divided into three security practices, making a total of 15 practices. These practices cover a wide spectrum of activities, ensuring a holistic approach to software security.

Governance: Setting the Foundation for Security

Governance provides the organisational backbone for implementing security initiatives. By aligning security with business objectives, this function ensures accountability and long-term commitment to secure software development.

• Strategy & Metrics: This practice ensures that security objectives are clearly defined and measurable. For example, an organisation might set a goal to reduce the number of critical vulnerabilities in production by 50% within a year. Metrics such as “time to remediate vulnerabilities” or “percentage of security issues identified pre-production” provide insights into the effectiveness of security efforts.
• Policy & Compliance: Policies act as a roadmap for secure practices, while compliance ensures adherence to regulatory requirements. For instance, GDPR mandates stringent data protection policies, and organisations can use SAMM to map their compliance efforts.
• Education & Guidance: Training and awareness are crucial for building a security-conscious workforce. For example, development teams can undergo secure coding workshops, while executives might receive training on the business implications of data breaches.

Design: Embedding Security Early

Security considerations must begin at the design stage to minimise risks later in the development process. The Design function ensures that security is integrated into every aspect of software architecture and planning.

• Threat Assessment: Threat modelling helps teams identify potential vulnerabilities and attack vectors. For example, using the STRIDE framework, developers can evaluate how spoofing, tampering, and information disclosure might impact their application.
• Security Requirements: This practice focuses on defining clear security objectives for each project. For example, a banking application might specify encryption for all sensitive data, robust authentication mechanisms, and logging for all user transactions.
• Secure Architecture: Architectural reviews ensure that systems are resilient against attacks. For instance, adopting microservices architecture with isolated environments can limit the blast radius of an attack.

Implementation: Secure Coding and Deployment

Implementation ensures that secure development practices are embedded into the coding and deployment phases.

• Secure Build: Automated tools, such as dependency checkers and static analysis tools, help identify vulnerabilities early. For example, tools like Snyk or OWASP Dependency-Check can detect outdated libraries with known vulnerabilities.
• Secure Deployment: Deployment pipelines should include automated security checks. For instance, a CI/CD pipeline might include a step to validate that configuration files do not expose sensitive data, such as API keys. Using automated Static Application Security Testing (SAST) tools (such as SonarQube) can also be a useful method in identifying code-level vulnerabilities before your application is deployed to production.
• Defect Management: Security issues must be tracked and resolved promptly. Bug tracking systems can be integrated with security scanners to create tickets automatically when vulnerabilities are detected, ensuring accountability.

Verification: Validating Security Measures

Verification provides confidence that security measures are working as intended and that vulnerabilities are identified before they become critical issues.

• Architecture Assessment: Regular reviews of system architecture help uncover weaknesses. Conducting security hardening reviews on cloud infrastructure is crucial to ensure that sensitive data is not exposed to unnecessary risks, as often the application is only as secure as the environment that it’s hosted in. Our Amazon AWS Cloud Security Review or Microsoft Azure Cloud Security Review can help your organisation ensure that your cloud environment is built to a robust hardening standard (such as CIS). For network-connected components, conducting a Network Segregation Test is crucial in ensuring the attack paths within your hosting environment are minimal and that the potential for an attacker to move laterally between critical hosts is reduced.
• Security Testing: Conducting regular application security assessments is critical to identify real-world vulnerabilities that may be exploited by hackers when your application is put into production. Ideally, penetration testing should be conducted on your application while it is deployed in your QA or Pre-Production environments to ensure that no code-changes are taking place that could invalidate the test results. Our CREST accredited penetration testing team are on hand for organisations to conduct Web Application Penetration Testing and API Penetration Testing in accordance with the latest OWASP Testing Methodology. For organisations that have deployed their application(s) to a mobile platform (such as iOS or Google Android), conducting a Mobile Application Penetration Test should also be considered. Lastly, if your organisation has developed a thick-client application or an application that will be installed onto an End User Device, a Desktop Application Security Assessment will help you ensure that your binary executable files and associated libraries are free from vulnerabilities that could affect the underlying operating system.
• Requirements-Driven Testing: Security requirements need to be validated through targeted tests. For example, a requirement for password complexity can be tested by attempting to create weak passwords during quality assurance.

Operations: Maintaining Security Over Time

Operations ensures that security is maintained throughout the lifecycle of an application, even after deployment.

• Incident Management: Organisations need a robust incident response plan. For instance, if a data breach occurs, the plan should outline steps for containment, forensic analysis, and communication with stakeholders.
• Environment Management: Securing the operational environment involves regular patching and configuration reviews. For example, ensuring that databases are only accessible from authorised IP ranges reduces the risk of unauthorised access.
• Operational Management: Ongoing monitoring and logging are critical for detecting anomalies. For instance, implementing SIEM (Security Information and Event Management) solutions like Splunk or Elastic Security can provide real-time alerts on suspicious activities.

Maturity Levels: A Roadmap for Improvement

SAMM’s maturity levels provide organisations with a structured path for improving their security posture:

• Level 1: Practices are informal and inconsistently applied. For example, a company might conduct ad hoc penetration testing but lack a formal process for remediation.
• Level 2: Security practices are standardised and integrated. At this level, organisations might implement a documented threat modelling process for all major projects.
• Level 3: Practices are optimised and continuously improved. For instance, metrics from defect tracking systems might be analysed to refine development practices and reduce vulnerabilities over time.

Implementing OWASP SAMM in Organisations

Implementing SAMM begins with a comprehensive assessment of current practices. Organisations then prioritise improvements based on their specific risks and business objectives. A phased approach often works best, starting with foundational practices before advancing to more complex initiatives.

For example, a small software company might focus on integrating automated security testing into their CI/CD pipeline as a first step. Over time, they could expand their efforts to include comprehensive threat modelling and continuous security monitoring.

If you want to find out more about how we can implement the OWASP Software Assurance Maturity model (SAMM) in your organisation – get in touch today!