Software Assurance Maturity Models (SAMM, BSIMM)

Why This Topic Matters
Secure software does not happen by accident. Organizations need a structured way to understand where they are today, where they want to be, and how to close the gap. That is exactly what a maturity model provides. Within the CSSLP domain of Secure Software Lifecycle Management, maturity models are the primary tools for measuring, benchmarking, and improving an organization's software security program. The exam expects you to know the two most prominent models in the industry: OWASP SAMM (Software Assurance Maturity Model) and BSIMM (Building Security In Maturity Model). More importantly, it expects you to understand the philosophical difference between them and when a security professional would choose one over the other.

From a business perspective, maturity models give leadership a defensible, repeatable, and quantifiable view of security investment. Instead of saying we do some code review, a CISO can say we are at Level 2 in Secure Build and have a roadmap to Level 3 within 18 months. This translates security work into language that executives, auditors, customers, and regulators understand.

What Is a Maturity Model?
A maturity model is a framework that describes a progression of capability, typically organized into levels (for example, Level 0 through Level 3, or Level 1 through Level 5). Each level represents a more complete, more consistent, and more measurable way of performing a set of activities. The classic ancestor of software maturity models is CMMI (Capability Maturity Model Integration), which describes general process maturity from Initial (ad hoc) through Optimizing (continuously improving). SAMM and BSIMM apply the same concept specifically to software security assurance.

Maturity models answer three questions:
1. Where are we? (Assessment or measurement)
2. Where should we be? (Target state, driven by risk appetite and business goals)
3. How do we get there? (Roadmap and prioritization)

OWASP SAMM: The Prescriptive Model
SAMM originated as OpenSAMM, created by Pravir Chandra in 2009, and is now maintained by the OWASP Foundation as an open, vendor-neutral project. The current version, SAMM v2 (released 2020), is designed to be prescriptive: it tells an organization what it should do to improve its software security posture, step by step, in a measurable way.

Structure of SAMM v2:
SAMM is organized into 5 Business Functions, each containing 3 Security Practices, for a total of 15 Security Practices. Each practice is split into 2 Streams (Stream A and Stream B), and each stream has 3 Maturity Levels. Maturity is scored from 0 (no activity) to 3 (comprehensive mastery).

The 5 Business Functions and 15 Practices:
1. Governance – Strategy & Metrics, Policy & Compliance, Education & Guidance
2. Design – Threat Assessment, Security Requirements, Security Architecture
3. Implementation – Secure Build, Secure Deployment, Defect Management
4. Verification – Architecture Assessment, Requirements-driven Testing, Security Testing
5. Operations – Incident Management, Environment Management, Operational Management

A helpful memory aid for the business functions is G-D-I-V-O: Govern, Design, Implement, Verify, Operate. Notice that it mirrors the software development lifecycle itself, which is deliberate.

How SAMM Works in Practice:
An organization performs a self-assessment (or works with an assessor) using the SAMM questionnaire. Each stream receives a maturity score. The organization then defines a target maturity for each practice based on its risk profile, since not every practice needs to reach Level 3. Finally, it builds a phased roadmap, implementing specific activities defined in the model to move from current to target state. SAMM provides the activities, success metrics, and quality criteria for each level, making it a true improvement framework rather than just a measuring stick.

Key characteristics of SAMM: open source, free, prescriptive, technology-agnostic, risk-driven, self-assessable, and applicable to organizations of any size. It is particularly well suited to organizations that want a clear, actionable roadmap and do not have a large budget for external assessments.

BSIMM: The Descriptive Model
BSIMM (pronounced bee-simm) was first published in 2008 by Gary McGraw, Brian Chess, and Sammy Migues at Cigital (later Synopsys, now Black Duck). Unlike SAMM, BSIMM is descriptive rather than prescriptive. It does not tell you what you should do; it documents what real organizations actually do. BSIMM is built from observational data collected through interviews and assessments of participating firms across industries such as financial services, healthcare, technology, cloud, and IoT. New versions are published roughly annually (BSIMM1 through BSIMM14, BSIMM15, and so on), and each release reflects updated data from the participating community.

Structure of BSIMM:
BSIMM is organized around the Software Security Framework (SSF), which has 4 Domains, 12 Practices, and roughly 120 to 130 Activities (the exact count changes with each release). Activities are grouped into 3 Levels based on how commonly they are observed: Level 1 activities are the most common and foundational, Level 3 activities are rare and advanced.

The 4 Domains and 12 Practices:
1. Governance – Strategy & Metrics, Compliance & Policy, Training
2. Intelligence – Attack Models, Security Features & Design, Standards & Requirements
3. SSDL Touchpoints – Architecture Analysis, Code Review, Security Testing
4. Deployment – Penetration Testing, Software Environment, Configuration Management & Vulnerability Management

A memory aid for the domains is G-I-T-D: Governance, Intelligence, Touchpoints, Deployment.

Key BSIMM Concepts:
- Software Security Group (SSG): The central, dedicated team responsible for software security in the organization. BSIMM research consistently shows that having an SSG is the single most common attribute of successful programs. BSIMM also tracks SSG size relative to developer headcount.
- Satellite (Security Champions): Developers, architects, and testers distributed across the organization who are interested in security and extend the reach of the SSG.
- Benchmarking: BSIMM's defining feature. An organization's observed activities are compared against the entire participant pool or against its industry vertical using a spider chart (radar chart) and a high-water mark for each practice. This answers the question how do we compare to our peers?
- Observation, not judgment: BSIMM intentionally avoids saying an activity is good or bad. If many firms do it, it is noted; the organization decides whether it is appropriate for them.

How BSIMM Works in Practice:
A BSIMM assessment is typically conducted by trained assessors who interview the SSG and stakeholders. Each of the activities in the current SSF is marked as observed or not observed. The result is a scorecard showing which activities are present, mapped onto the spider chart against the community average. Organizations use this to identify gaps relative to peers, justify budget, and track year-over-year progress. BSIMM data has historically been released under a Creative Commons license, but full assessments are generally performed as a commercial service.

SAMM vs. BSIMM: The Critical Comparison
This comparison is the heart of what the exam tests. Memorize these distinctions:

Nature: SAMM is prescriptive (what you should do). BSIMM is descriptive (what others actually do).
Source: SAMM is an OWASP open-source project, community-developed. BSIMM is data-driven from observed real-world firms, originally Cigital/Synopsys.
Primary Purpose: SAMM builds an improvement roadmap. BSIMM provides a benchmark against peers.
Structure: SAMM has 5 business functions, 15 practices, 2 streams each, levels 0-3. BSIMM has 4 domains, 12 practices, approximately 120+ activities, 3 levels.
Assessment: SAMM is designed for self-assessment and is free. BSIMM is typically an assessor-led engagement.
Flexibility: SAMM lets you set your own target maturity per practice based on risk. BSIMM shows what is common, leaving interpretation to you.
Update Cadence: SAMM has major versions (v1, v1.5, v2). BSIMM is refreshed roughly annually with new data.

Both models share the goal of improving software assurance, both are technology-agnostic, both are organized by lifecycle-oriented domains, and many organizations use both together: BSIMM to understand how they compare externally, and SAMM to build an internal improvement plan. They are complementary, not mutually exclusive.

Related Frameworks You May See as Distractors
- Microsoft SDL (Security Development Lifecycle): a process for building secure software, not a maturity model, though its optimization model has maturity-like phases.
- NIST SSDF (Secure Software Development Framework, SP 800-218): a set of high-level secure development practices; not a maturity scoring model.
- CMMI: a general process maturity model with 5 levels, not security-specific.
- ISO/IEC 21827 (SSE-CMM): Systems Security Engineering Capability Maturity Model, an older security engineering maturity standard.
- OWASP ASVS: a verification standard for application security requirements, not an organizational maturity model.
Knowing what each of these is not helps you eliminate wrong answers.

How Maturity Models Fit the Secure Software Lifecycle
Within lifecycle management, maturity models support governance (policy, metrics, accountability), continuous improvement (measuring progress over time), resource justification (showing executives where investment yields the most risk reduction), and supplier and third-party assurance (asking vendors to demonstrate maturity). A CSSLP is expected to recommend the right model for the organization's goals, interpret results, and translate findings into a prioritized roadmap integrated into the SDLC.

Exam Tips: Answering Questions on Software Assurance Maturity Models (SAMM, BSIMM)

Tip 1: Lock in the one-word distinction. If a question uses the word prescriptive, roadmap, what we should do, or OWASP, the answer is SAMM. If it uses descriptive, observed, benchmark, compare to peers, what real organizations do, or data from participating firms, the answer is BSIMM. This single distinction resolves the majority of questions.

Tip 2: Know the numbers. SAMM = 5 business functions, 15 practices, 3 maturity levels (plus level 0). BSIMM = 4 domains, 12 practices, 3 levels, 120+ activities. Questions sometimes test whether you can identify a domain or practice by name, so recognize that Intelligence and SSDL Touchpoints are BSIMM terms, while Design, Implementation, Verification, and Operations are SAMM business functions. Note that Governance appears in both.

Tip 3: Recognize the SSG. Any reference to a Software Security Group, satellite, or security champions network as a measured attribute points to BSIMM.

Tip 4: Match the scenario to the goal. If a scenario says the organization has limited budget and wants a free self-assessment to build an improvement plan, choose SAMM. If the organization wants to know how it stacks up against other companies in its industry, or needs external validation for executives or customers, choose BSIMM. If the question asks for the best approach and offers using both, that is often the strongest answer because the models are complementary.

Tip 5: Do not confuse maturity models with development processes. Microsoft SDL and NIST SSDF describe how to build software securely. SAMM and BSIMM describe how to measure and mature the program that builds software securely. If a question asks which option is a maturity model, eliminate SDL, SSDF, and ASVS.

Tip 6: Remember that maturity targets are risk-based. A common trap is an answer suggesting every practice must reach the highest level. The correct mindset, especially for SAMM, is that target maturity is chosen per practice based on business risk and resources. Not every organization needs Level 3 everywhere.

Tip 7: Think like a manager, not a coder. CSSLP questions in this domain focus on governance, metrics, and program improvement. When two answers seem plausible, prefer the one that emphasizes measurable, repeatable, risk-driven improvement integrated into the lifecycle rather than a one-time technical fix.

Tip 8: Watch for historical and ownership details. SAMM was originally OpenSAMM and is now an OWASP flagship project. BSIMM was created at Cigital and later maintained by Synopsys. If an answer attributes SAMM to a vendor or BSIMM to OWASP, it is wrong.

Tip 9: Understand level semantics. In SAMM, levels represent increasing sophistication and consistency of a specific practice, and Level 0 means nothing is being done. In BSIMM, levels reflect how commonly an activity is observed: Level 1 activities are widespread, Level 3 activities are rare and advanced. Do not assume the two models' levels mean the same thing.

Tip 10: Eliminate absolutes. Answers claiming a maturity model guarantees security, replaces testing, or certifies software are almost always wrong. Maturity models measure and guide an organization's program; they are not product certifications.

Quick Review Summary
- SAMM: OWASP, open, prescriptive, roadmap-oriented, 5 functions (Governance, Design, Implementation, Verification, Operations), 15 practices, 2 streams, levels 0-3, self-assessable.
- BSIMM: Observational, descriptive, benchmark-oriented, 4 domains (Governance, Intelligence, SSDL Touchpoints, Deployment), 12 practices, 120+ activities, 3 levels, built around the SSG, updated annually, assessor-led.
- Use SAMM to decide what to do next. Use BSIMM to see how you compare. Use both for the most complete picture.

Master these distinctions and you will handle any CSSLP question on software assurance maturity models with confidence.