Security Maturity Models - BSIMM & SAMM Assessment

Master security maturity models: BSIMM, SAMM, CMMI assessment, target maturity, capability roadmaps, and measurable security improvement outcomes.

Security maturity models provide structured frameworks for assessing current security capabilities, setting target maturity levels, and building roadmaps for capability improvement. Security engineers use maturity models to prioritize security investments, track progress, and communicate security program status to executives.

Unlike ad-hoc assessments that produce inconsistent results, maturity models establish common vocabulary that enables meaningful benchmarking against industry peers and tracking of improvement over time. Effective assessment combines framework-based evaluation with engineering outcomes including mean time to remediation and defect escape rates.

Maturity Model Frameworks

Three primary frameworks dominate the security maturity landscape, each serving different organizational needs and assessment styles. Understanding their differences helps security teams select the right model—or combination of models—for their specific context.

BSIMM (Building Security In Maturity Model)

BSIMM is a descriptive model based on observed practices from real software security initiatives across hundreds of organizations. Rather than prescribing what organizations should do, BSIMM describes what organizations actually do in practice, making it valuable for benchmarking against peers in similar industries. The model emerged from empirical research conducted by Synopsys (formerly Cigital) and provides data-driven insights into how security programs evolve.

BSIMM organizes practices into twelve domains spanning governance, intelligence, secure software development lifecycle touchpoints, and deployment. Each practice has multiple activity levels representing increasing sophistication. The framework enables peer comparison by showing how an organization's practices compare to similar organizations—a software company can benchmark against other software companies rather than against banks or healthcare providers with different risk profiles.

Assessment involves structured interviews and evidence review across security and development teams, typically conducted by trained BSIMM assessors who ensure consistent scoring methodology. Organizations receive detailed scorecards showing their position relative to peers, identifying both strengths to leverage and gaps requiring investment. BSIMM is updated regularly based on new data from participating organizations, ensuring the model reflects current industry practices rather than outdated assumptions.

OWASP SAMM (Software Assurance Maturity Model)

OWASP SAMM is a prescriptive model defining what organizations should do to improve software security. Unlike BSIMM's descriptive approach, SAMM provides a clear improvement roadmap that organizations can follow regardless of their current state. As an open-source framework maintained by OWASP, SAMM is freely available and supported by extensive community resources including detailed implementation guidance.

SAMM organizes practices into five business functions: Governance, Design, Implementation, Verification, and Operations. Each business function contains three security practices, creating fifteen total practice areas. Each practice defines three maturity levels with specific activities and success metrics, providing clear progression paths from ad-hoc security to optimized capabilities. The structured levels help organizations understand exactly what capabilities they need to build at each stage.

A key strength of SAMM is its risk-based approach to target setting. Not all practices require the highest maturity level—organizations should set targets based on their specific risk profile and regulatory requirements. A financial services company handling sensitive customer data may require Level 3 maturity in data protection practices while accepting Level 1 in areas with lower risk exposure. SAMM assessment is self-service with detailed questionnaires and scoring guidance, enabling organizations to conduct rapid assessments and iterate on improvement plans without external consultants.

CMMI (Capability Maturity Model Integration)

CMMI defines five maturity levels: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Originally developed for software development process improvement by the Software Engineering Institute at Carnegie Mellon University, CMMI has been adapted for security functions through careful mapping of security processes to the framework structure. Each level represents increasing process capability and organizational discipline.

CMMI emphasizes process definition, measurement, and continuous improvement through a rigorous methodology. At lower maturity levels, processes may be ad-hoc and dependent on individual heroics. Higher maturity levels require defined processes, quantitative management, and systematic optimization based on data. This process focus enables systematic capability building that survives personnel changes and organizational transitions.

CMMI certification requires formal assessment by authorized appraisers, providing external validation that organizations can reference in customer communications and regulatory submissions. This makes CMMI particularly valuable for organizations requiring third-party attestation of their security capabilities, though the certification process requires significant investment in preparation and assessment activities.

Maturity Assessment

Accurate maturity assessment requires moving beyond checkbox self-assessments to evidence-based evaluation that captures both process maturity and security outcomes. Organizations frequently overestimate their maturity when assessments rely solely on documentation review without verifying actual implementation.

Evidence-Based Scoring

Effective maturity assessment requires objective evidence including process documentation, tool outputs, and outcome metrics. Evidence should demonstrate not just that processes exist on paper, but that they are consistently followed in practice. This includes control implementation artifacts, configuration evidence from security tools, and metrics from operational systems. Checkbox self-assessments without supporting evidence provide false confidence and fail to identify genuine capability gaps.

Assessment should always include interviews with practitioners to understand actual practices versus documented procedures. These conversations frequently reveal gaps between policy and practice—security teams may have excellent documentation but inconsistent implementation, or strong informal practices that aren't captured in formal processes. Skilled assessors probe for both scenarios, looking for evidence that security activities are embedded in daily workflows rather than performed only during audit periods.

Engineering Outcomes

Process maturity alone doesn't guarantee security improvement. Mature processes that produce poor outcomes indicate fundamental problems with the approach, while immature processes that achieve good outcomes may be unsustainable or dependent on individual heroics. Effective assessment combines process evaluation with engineering outcome metrics that demonstrate actual security improvement.

Key outcome metrics include mean time to remediation (MTTR) for vulnerabilities, which measures how quickly organizations address identified issues. Improving MTTR indicates maturing processes even if total vulnerability counts remain stable. Defect escape rate—the percentage of vulnerabilities that reach production versus those caught during development—measures prevention effectiveness. Security testing coverage metrics show how thoroughly code is exercised by security tests, indicating testing practice maturity. Security incident frequency and impact provide lagging indicators of overall security effectiveness, with decreasing incidents validating that maturity improvements translate to real risk reduction.

Scoring Calibration

Consistent scoring requires calibration across assessors to prevent scoring drift over time or between assessment teams. Organizations should develop detailed scoring rubrics with specific criteria for each maturity level, reducing subjectivity in scoring decisions. Pilot assessments conducted before organization-wide rollout help validate the scoring approach and identify areas where rubrics need clarification. Calibration sessions where multiple assessors score the same evidence and discuss differences build shared understanding of scoring criteria.

Capability Roadmapping

Maturity assessment provides a snapshot of current capabilities, but sustainable improvement requires translating assessment findings into actionable roadmaps with clear ownership, sequencing, and resource allocation. Effective roadmapping connects maturity gaps to funded initiatives that deliver measurable improvement.

Target Maturity Definition

Target maturity should be defined per practice based on business risk and regulatory requirements, recognizing that not all practices require the highest maturity level. High-risk areas including authentication, authorization, and data protection typically warrant higher target maturity than lower-risk support functions. This risk-based targeting optimizes security investment by concentrating resources where they deliver the greatest risk reduction.

Regulatory requirements may mandate minimum maturity levels for specific practices—PCI DSS compliance requires specific controls that map to defined maturity levels, while SOC 2 attestation implies certain process maturity. Target maturity should be achievable within the planning horizon (typically 1-3 years), as unrealistic targets demotivate teams and undermine confidence in the maturity program. Organizations should set ambitious but achievable targets, planning for incremental improvement rather than overnight transformation.

Initiative Sequencing

Security improvement initiatives should be sequenced based on dependencies, risk reduction potential, and resource availability. Foundation capabilities including security governance and secure development lifecycle should be prioritized early, as they enable other capabilities. An organization cannot effectively implement advanced security testing automation without first establishing basic secure development practices.

Quick wins that deliver visible value should be included in the early roadmap phases to build momentum and organizational support for continued investment. These might include implementing secret scanning in CI/CD pipelines, deploying endpoint detection and response tools, or establishing security review processes for high-risk changes. Dependencies between initiatives must be identified and respected—attempting to implement capabilities before their prerequisites are in place leads to failed implementations and wasted resources.

Ownership and Accountability

Each roadmap initiative requires a clear owner with responsibility for delivery and authority to allocate resources. Ownership without authority creates accountability gaps where initiative owners are blamed for failures they lack the power to prevent. Initiative owners should have defined success metrics enabling objective progress tracking, and should participate in regular review sessions to report status and surface blockers.

Resource Planning

Effective roadmaps include explicit resource requirements covering headcount, budget, and tooling. Resource constraints should be identified early in the planning process, as they may require roadmap adjustments including extended timelines or reduced scope. Hiring plans should align with roadmap timelines, accounting for the reality that security talent acquisition often takes 3-6 months from requisition approval to productive new hire. Organizations that assume instant hiring fail to deliver on roadmap commitments.

Progress Reporting

Maturity improvement is a multi-year journey requiring sustained organizational commitment. Regular progress reporting maintains executive visibility and support while identifying roadblocks before they derail initiatives.

Quarterly Maturity Reviews

Maturity should be reassessed quarterly to track progress, balancing assessment overhead with visibility needs. Quarterly cadence provides sufficient time for meaningful improvement between assessments while maintaining momentum. Maturity burndown charts showing progress toward target maturity provide visual tracking that executives can quickly understand, highlighting both achievements and areas requiring attention.

Progress should be reported to executives and governance committees in business terms, connecting maturity improvements to risk reduction and business outcomes. Reports should highlight both successes and challenges, providing honest assessment of progress and surfacing resource constraints or organizational blockers requiring executive intervention.

Budget Alignment

Maturity roadmaps should be directly tied to security budget requests, creating clear linkage between funding and expected capability improvements. Budget requests referencing specific maturity gaps and target improvements are more compelling than abstract requests for security investment. Budget tracking should demonstrate progress on funded initiatives, showing executives that their investments are delivering expected results. This evidence-based approach builds trust and supports future budget requests.

Trade-offs between maturity investment and other organizational priorities should be communicated clearly to stakeholders, enabling informed decisions about resource allocation. When resource constraints force deferrals, the risk implications of deferred maturity initiatives should be documented explicitly. Maturity targets may need adjustment based on resource constraints, but adjustments should be explicit and approved through governance processes rather than silently allowed to slip.

Maturity Model Selection

Selecting the right maturity model—or combination of models—requires understanding organizational context, industry requirements, and assessment objectives. Each framework offers distinct strengths suited to different organizational needs.

BSIMM suits organizations wanting peer comparison and descriptive assessment based on empirical data about industry practices. BSIMM is particularly valuable for organizations seeking to understand how their practices compare to similar companies and wanting external validation of their security program. SAMM suits organizations wanting a prescriptive improvement roadmap with self-service assessment capabilities. SAMM's open-source nature and detailed implementation guidance make it accessible for organizations beginning their maturity journey.

CMMI suits organizations requiring formal third-party certification or those with strong process improvement cultures. CMMI's broader scope beyond software security may benefit organizations seeking to mature multiple capability areas simultaneously. Many organizations use multiple models together—BSIMM for external benchmarking and peer comparison combined with SAMM for internal roadmapping and self-assessment is a common and effective approach.

Customization

Generic maturity models may not perfectly fit specific organizational contexts, industries, or regulatory environments. Customization should maintain the core model structure while adapting specific practices to organizational needs. For example, a healthcare organization might add specific practices related to HIPAA requirements that aren't explicitly covered in general-purpose frameworks.

Custom practices and adaptations should be documented with clear rationale, enabling consistent assessment over time and helping future assessors understand why certain modifications were made. Excessive customization, however, undermines the comparability benefits that standardized frameworks provide.

Conclusion

Security maturity models provide structured frameworks for assessing capabilities, setting risk-based targets, and building improvement roadmaps with clear ownership and accountability. Security engineers use maturity models to prioritize investments, track progress over time, and communicate program status to executives in terms they understand.

Success requires evidence-based assessment that combines process evaluation with outcome metrics, risk-based target setting that concentrates investment where it delivers greatest value, and clear roadmaps with explicit ownership, sequencing, and resource allocation. Organizations that invest in maturity model fundamentals build systematic capability improvement programs that deliver sustained security improvement rather than point-in-time compliance.

References

• BSIMM (Building Security In Maturity Model) — Data-driven software security maturity model based on observed practices
• OWASP SAMM (Software Assurance Maturity Model) — Open framework for software security assessment and improvement
• CMMI Institute — Capability maturity model with formal certification
• NIST Cybersecurity Framework — Comprehensive framework for managing cybersecurity risk
• ISO/IEC 21827 — Systems Security Engineering Capability Maturity Model