Hello everyone! I am extremely excited to have the opportunity to return to my blog posts after a long break. In this post, I would like to share an important topic that I have been working on and that has caught my attention: Software Security Maturity Models. This subject, which is discussed in the literature and brings together various approaches, is closely related to the world of DevSecOps and can actually be considered a specialized field in its own right. Moreover, there are various professions emerging from this area, such as Code Review Expertise.

The information presented in this article is supported by data obtained from the following source:

Demir, Bünyamin. Software Security: Attack and Defense. 4th Edition, Dikeyeksen Publishing.

In recent years, it is certainly no coincidence that major technology companies such as Google, Microsoft, and Yahoo have prioritized secure software initiatives. These companies have realized that simply identifying and fixing vulnerabilities is not enough to ensure software security. Achieving security requires a holistic approach that spans every phase of the software development lifecycle, from business processes to legal compliance.

This comprehensive approach necessitates addressing software security with an end-to-end mindset. However, this can only be successful when based on a formalized and continuously evolving process, supported by the necessary organizational backing. In response to these needs, software security maturity models emerged in 2008, beginning to systematically define the processes in this area.

Software security maturity models are systematic frameworks that assess an organization’s level in a specific domain and explain this level with structured criteria. These models not only serve as assessment tools but also act as guides for organizations in planning and developing their security strategies.

So, what benefits do these models provide for organizations?

1. Determines the Current State: It reveals the organization’s security level and allows for comparison with other organizations.
2. Creates a Common Language: It contributes to the development of a shared understanding and language for communication among internal teams and external stakeholders.
3. Identifies Gaps: It identifies potential gaps and shortcomings in security processes within the organization, making improvement opportunities clearer.
4. Provides Goals and Priorities: It ranks actions based on the organization’s needs and priorities, enabling the creation of a more effective strategy.

The need for this systematic approach to software security became more evident toward the late 1990s. The rapid expansion of the internet and the increase in successful cyberattacks demonstrated that software security was not just an option, but a necessity. However, the measures taken by organizations to address this issue were not formalized into a framework until 2008.

Systematic work on maturity models in the field of software security gained a roadmap and a foundation for discussion with the publication of two key documents in 2008. One of these documents is the BSIMM (Building Security In Maturity Model), and the other is presented under the name OpenSAMM (Software Assurance Maturity Model). These models offer comprehensive guidance on software security, making it easier for organizations of various sizes to approach this critical issue.

Although the implementation of maturity models is still in the adoption phase, there is a general consensus in the field: organizations must adopt and begin applying one of these models without delay. Software security is a process that requires a strategic approach and continuous effort; therefore, taking the first step is of critical importance.

By implementing these models, organizations can achieve the following benefits:
Assessing the Current State: Organizations can clearly see the maturity level of their existing software security processes according to the maturity models.
Identifying Gaps: Areas where security processes are either not implemented or are insufficient can be identified, uncovering opportunities for improvement.
Defining Goals and Priorities: Action plans can be created for the identified gaps, and these plans can be prioritized based on their significance, leading to a more effective strategy.

Now, let’s briefly take a look at the OpenSAMM maturity model, which is an OWASP project.

OpenSAMM, OWASP (Open Web Application Security Project)

OpenSAMM, developed by OWASP (Open Web Application Security Project), is a model that systematically addresses software security maturity processes. This model provides guidance to organizations on how to make their software development processes more secure. The primary goal of OpenSAMM is to help organizations assess their current security practices, identify gaps, and develop strategic plans to address these gaps.

OpenSAMM focuses on four main functional areas:
Governance: Establishing security policies, integrating risk management processes, and raising security awareness across the organization.
Design: Defining secure software architecture, determining security requirements, and implementing threat modeling processes.
Implementation: Adopting secure coding standards, performing security testing, and preventing security vulnerabilities.
Verification: Evaluating the software from a security perspective using various testing methods and analyzing the results.

Each functional area targets a different security aspect of the organization’s software development processes, with specific activities defined to facilitate progress in these areas. Additionally, OpenSAMM presents a three-level maturity model for each activity. These levels enable organizations to develop their software security processes in alignment with their current status and objectives:

 Level 1: Basic Awareness and Practices
Objective: To initiate security processes and establish basic awareness.

Characteristics:

• Security practices are not standardized across the organization.
• Security is typically addressed in a reactive manner; issues are resolved as they arise.
• The importance of security is communicated through training and awareness campaigns.

Example: Providing basic secure coding training to software teams or performing minimal security testing.

Level 2: Standardization and Improvement of Processes
Objective: To implement security activities in a systematic manner.

Characteristics:

• Security processes are now standardized and consistent across the organization.
• A proactive approach is adopted; security vulnerabilities are identified in advance to minimize risks.
• Advanced tools and techniques begin to be used.

Example: Regularly integrating threat modeling processes into projects or using automated security scanning tools (SAST, DAST, Log Analysis Tools, Dependency Scanning Tools: Aikido Security, Owasp ZAP, Splunk, Snyk, Probely, Qodana). 

Level 3: Optimization and Innovation
Objective: To optimize security processes and ensure continuous improvement.

Characteristics:

• Security activities are fully integrated into the organization’s business processes.
• The principle of continuous improvement is embraced; the organization updates its processes with new technologies and innovative methods.
• Security becomes not only a technical issue but also a part of the organizational culture.

Example: Adopting DevSecOps practices to prevent security vulnerabilities early in the project lifecycle or developing custom security tools tailored to the organization’s needs.

This three-level model provides organizations with the opportunity to assess their current capabilities and develop improvement plans accordingly. Organizations should first determine their current level and then create a roadmap to progress to higher levels. 

The flexible structure of OpenSAMM provides an effective development framework for both small and large organizations.

GOVERNANCE

Strategy & Metrics: For a software security program to be successful, goals must be clearly defined, and a roadmap must be created to achieve those goals. Strategy and Metrics address this need and provide the following benefits:

• Defining Goals: Software security goals that align with the organization’s risk tolerance are established. These goals should be measurable and realistic.
• Defining Metrics: Appropriate metrics are defined to measure the effectiveness of the software security program. These metrics may include factors such as the number of vulnerabilities, remediation time, and training levels.
• Creating a Strategic Roadmap: The steps and processes required to achieve the goals are outlined. The strategic roadmap should be reviewed and updated regularly.
• Measurement and Improvement: The program’s performance is regularly measured using the defined metrics. Based on the measurement results, necessary improvements are made to the program.

Example from the Strategy and Metrics Framework
An e-commerce company can define the following SMART (Specific, Measurable, Achievable, Relevant, Time-bound) goal to ensure the security of customer data: “By the end of 2024, mandate SSL certificates on all payment pages to achieve PCI DSS compliance and reduce the risk of card information theft by 95%.”

Key Performance Indicators (KPIs) for this goal could include:

• Monthly average number of PCI DSS non-compliance incidents
• SSL certificate renewal rate
• Percentage of customer complaints related to data breaches

Policy & Compliance
The Policy & Compliance (PC) practice focuses on understanding and meeting external legal and regulatory requirements while establishing internal security standards to ensure compliance in line with the organization’s business objectives.

A key theme for improvement within this practice is defining the organization’s standards and third-party obligations, allowing these to be applied within the SDLC and facilitating efficient, automated audits that continuously demonstrate compliance with all expectations.

The sophisticated implementation of this practice requires an understanding of both internal standards and external compliance drivers across the organization, ensuring that no project operates outside of expectations without visibility. Low-latency checkpoints are maintained with project teams to ensure this.

Education & Guidance
The Education & Guidance (EG) practice focuses on equipping personnel involved in the software lifecycle with the knowledge and resources needed to design, develop, and deploy secure software. With better access to information, project teams can proactively identify and mitigate the specific security risks relevant to their organization.

A key theme for improvement along these goals is providing training to employees, whether through instructor-led sessions or computer-based modules, to increase security awareness. As the organization progresses, a broad foundation of training is established, starting with developers and expanding to other roles. The addition of role-based training ensures applicability and effectiveness.

This practice, in addition to training, requires a significant investment from the organization to improve the organizational culture through collaboration, encouraging application security. Enhanced transparency between collaboration tools, technologies, and tools themselves supports this approach to improving the security of applications.

DESIGN

The Threat Assessment practice focuses on identifying and understanding project-level risks based on the functionality of the developed software and the characteristics of the runtime environment. By identifying threats and potential attacks for each project, the organization works more effectively by prioritizing security initiatives and making better decisions. Additionally, risk acceptance decisions are made more consciously, which aligns better with business objectives.

Starting with simple threat models and creating application risk profiles, an organization matures over time. As a result, a sophisticated organization tightly connects this information with compensating controls and transition risks from external entities. This provides a broader understanding of potential downstream impacts from security issues, trade-offs, or flaws, while also closely monitoring the organization’s current performance against known threats.

Threat Modeling
The best way to define high-level threats for an organization and individual projects. A risk assessment of the application is conducted to understand the likelihood and impact of an attack. Risk-based threat modeling should be conducted using existing diagrams that include brainstorming and simple threat checklists.

Standardizing threats related to software within the organization and analyzing them at the enterprise level. By centralizing the risk profile inventory for stakeholders, the organization understands the risks associated with all applications. Standardize threat modeling training, processes, and tools to scale across the organization.

Proactively improving the scope of threats across the organization. Regularly review application risk profiles to ensure accuracy and reflect the current state. Continuously optimize and automate your threat modeling methodology.

Security Requirements

The Security Requirements (SR) practice focuses on the security requirements that are critical in the context of secure software. The first type deals with typical software-related requirements that define the objectives and expectations for protecting the core services and data of the application. The second type specifically addresses the requirements related to external vendors, which are part of the development context of the application. Since outsourcing can have a significant impact on the security of the application, it is important to standardize expectations regarding secure development. The security of third-party (technical) libraries is part of the software supply chain flow (see Secure Build) and is not included in this practice.

Vendor Security

Security should be explicitly considered during the software requirements process. High-level application security goals are aligned with functional requirements. Evaluate vendors based on organizational security requirements.

Increase the level of detail for security requirements derived from business logic and known risks. Structured security requirements are available and used by development teams. Ensure compliance with organizational requirements by incorporating security into vendor agreements.

Mandate the security requirements process for all software projects and third-party dependencies. Create a framework of requirements that product teams can use. Provide appropriate security coverage for external vendors by defining clear goals.

Secure Architecture

The Secure Architecture (SA) practice focuses on the security aspects related to the components and technologies encountered in your software’s architectural design. Secure Architecture Design centers on selecting and integrating the components that form the foundation of your solution, emphasizing security features. Technology Management examines the security of supporting technologies used during development, deployment, and operations, such as development stacks and tools, deployment tools, and operating systems and utilities.

Technology Management

Integrate proactive security guidance into the software design process. Teams are trained on the use of core security principles during design. Identify technologies, frameworks, and integrations within the overall solution to define risks.

Direct the software design process toward known secure services and secure-by-default designs. Create common design patterns and security solutions for adoption. Standardize the technologies and frameworks to be used across different applications.

Officially govern the software design process and verify the use of secure components. Reference architectures are used and continuously evaluated for adoption and suitability. Mandate the use of standard technologies across all software developments.

IMPLEMENTATION

Implementation focuses on the processes and activities related to how an organization builds and deploys its software components and addresses related flaws. Activities within the Implementation function have the greatest impact on the daily work of developers. The common goal is to reliably deliver software that works with minimal defects.

Secure Build

The Secure Build (SB) practice emphasizes the importance of creating software in a standardized, repeatable manner using secure components, including third-party software dependencies.

The initial flow focuses on removing any subjectivity from the build process by striving for full automation. An automated build pipeline, for example, can include additional automated security checks, such as SAST and DAST, to flag security regressions early and provide further assurance in case of build failures.

The second flow acknowledges the prevalence of software dependencies in modern applications. It aims to identify and monitor their security statuses, thereby limiting the impact of vulnerabilities in an application’s security. In an advanced form, similar security checks are applied to software dependencies just like the application itself.

Software Dependencies

The build process should be repeatable and consistent. To ensure the build process is both consistent and repeatable, establish a formal definition. Create records with a Bill of Materials (BOM) for your applications and analyze them opportunistically.

The build process should be optimized and fully integrated into the workflow. Automate the build pipeline and secure the tools being used. Add security checks to the build pipeline. Evaluate the dependencies used and respond promptly to situations that pose risks to your applications.

The build process should prevent known flaws from entering the production environment. Define mandatory security checks within the build process and ensure that the creation of incompatible artifacts fails. Analyze the dependencies used, comparing them to your own code for security issues.

VERIFICATION

Verification focuses on the processes and activities a company uses to review and test the artifacts produced during software development. This often includes quality assurance activities such as testing but may also involve other review and evaluation activities.

Architecture Review

The Architecture Review (AR) practice ensures that the application and infrastructure architecture meet all relevant security and compliance requirements and adequately mitigate identified security threats. The first flow focuses on verifying that the security and compliance requirements defined in the Policy & Compliance and Security Requirements practices are met, initially validating each interface in the system, followed by a more systematic verification. The second flow reviews the architecture first for measures taken against typical threats, and then for specific threats defined in the Threat Assessment practice.

In a more advanced form, the application architecture security review process is formalized, continuously evaluating the effectiveness, scalability, and strategic alignment of the architecture’s security controls. Identified weaknesses and potential improvements are fed back to the Secure Architecture practice for the development of reference architectures.

Review the architecture to ensure that basic mitigation measures are in place for typical risks. Identify and review the application and infrastructure architecture components from a foundational security perspective. Conduct a specific review of the architecture for unmitigated security threats.

Review the complete implementation of security mechanisms within the architecture. Verify the architecture’s security mechanisms. Analyze the architecture for known threats.

Enhance the security of the architecture by reviewing the effectiveness of its components and incorporating feedback from the results. Review the effectiveness of architectural components. Provide feedback on architectural review results to the enterprise architecture, organizational design principles, patterns, security solutions, and reference architectures.

Requirement-Focused Testing

The goal of the Requirement-Focused Testing (RFT) practice is to ensure that the applied security controls function as expected and that the project meets the specified security requirements. This is achieved by progressively developing a set of security test and regression cases and executing them regularly.

An important aspect of this practice is its focus on both positive and negative testing. Positive testing validates that the security controls of the application meet the specified security requirements and work correctly. These requirements are typically functional in nature. Negative testing, on the other hand, addresses the quality of implementation of security controls and aims to identify unexpected design flaws and application errors through abuse and misuse tests. In more advanced forms, the practice encourages security stress tests, such as denial-of-service attacks, and continuously improves application security by automating unit security tests for all identified and corrected flaws and generating security regression tests.

Although both Requirement-Focused Testing and Security Testing practices are related to security tests, the former focuses on verifying the correct implementation of security requirements, while the latter aims to uncover technical implementation weaknesses in an application, independent of the requirements.

Abuse/Misuse Testing

Opportunistically identify basic security vulnerabilities and other security issues. Test software security controls. Perform security fuzz testing.

Conduct application reviews to identify application-specific risks. Derive test cases from known security requirements. Create and test abuse cases and business logic error tests.

Maintain application security levels during bug fixes, changes, or maintenance. Conduct regression testing (with security unit tests). Perform denial-of-service and security stress testing.

REFERENCES

1. OWASP. Threat modeling process. Retrieved from https://owasp.org/www-community/Threat_Modeling_Process

2. OWASP. OWASP Software Assurance Maturity Model. Retrieved from https://owasp.org/www-project-samm/

3. OWASP SAMM. OWASP Software Assurance Maturity Model: Model. Retrieved from https://owaspsamm.org/model/

4. OpenSAMM. SAMM 1.0 download. Retrieved from https://opensamm.org/downloads/SAMM-1.0.pdf

5. Demir, Bünyamin. Software Security: Attack and Defense. 4th Edition, Dikeyeksen Publishing.