At RSAC Conference 2025 I presented a session called “Software Security Maturity Models SAMM vs. BSIMM: Which is Better?”. The question comes up in almost every conversation I have about application security programs, so here’s the comparison in writing, updated with the latest BSIMM and SAMM data.
A disclosure first: I’m a core team member of OWASP SAMM. I’ve tried to be fair to both models, and I’ll tell you where BSIMM is the better choice.
The policy versus reality gap
Every serious software company has a secure software development lifecycle (SSDLC) policy. It lists the activities that should happen: threat modeling at design time, SAST, SCA and secret scanning on every commit, DAST and fuzzing before release, signed artifacts, vulnerability management and incident response in operations.
Assess how many of those activities actually happen, consistently and across all teams, and you’ll almost always be disappointed. The policy describes a perfect world. Reality is a patchwork: some teams do most of it, some do a little, and nobody has a complete picture.
Executives sense this gap even when they can’t name it. A question I’ve heard CIOs ask their CISO goes roughly like this: “You have smart people and they’re busy all the time. How do we know they’re working on the right things? And how would we know when to change where they spend their time?”
A maturity model is how you answer that question.
What a maturity model does
A software security maturity model is a framework that helps you assess and improve your software security practices through defined levels of maturity. In practice you use it to:
- take stock of the security activities you already do, as opposed to the ones your policy says you do
- compare your current state to where you want to be, or to what peers do
- turn the gaps into a prioritized plan of small, achievable steps
- reassess regularly and show progress over time
Typical reasons to start:
- You’re just getting started with application security and want to know where to begin. A model breaks a big, vague problem into small steps.
- You need to justify more budget and want an outside reference point. An internal advocate can make the case, but it’s often easier politically when an independent assessor says the same thing.
- You have a mature program and want to find out where it can still improve.
- You want to show others what a complete program looks like and use it as the frame for a long-term roadmap.
BSIMM and SAMM grew out of the same work around 2008 and 2009 and still share a lot of DNA. But they’ve developed in different directions, and those differences decide which one fits you.
BSIMM: a descriptive model
BSIMM, the Building Security In Maturity Model, is descriptive. It observes what real organizations do and reports it, without saying what you should do.
The data comes from structured interviews in participating organizations. Assessors look for evidence that each activity is actually performed, consistently and with enough coverage across the organization. Plans, intentions and one-off efforts don’t count. The anonymized results are pooled, analyzed for trends, and the model is updated with each yearly report. BSIMM is now run by Black Duck, formerly Synopsys’ Software Integrity Group. BSIMM16, published in February 2026, is based on 111 organizations that together build about 91,000 applications.
The model has four domains (Governance, Intelligence, SSDL Touchpoints and Deployment), each with three practices, and 128 activities in total.
BSIMM’s levels work differently from what most people expect. They don’t describe doing the same thing better. An activity’s level reflects how often it’s observed among participants: the most commonly observed activities are level 1, rarer ones are level 2 or 3. Scoring is binary. Each activity either counts (1) or doesn’t (0), and your scorecard shows how many you do, per practice and domain, next to the community average.
OWASP SAMM: a prescriptive model
OWASP SAMM, the Software Assurance Maturity Model, is prescriptive. It tells you what good looks like and how to get there, step by step. It’s an open OWASP flagship project, free to use, and works for organizations of any size and any development methodology.
SAMM has five business functions (Governance, Design, Implementation, Verification and Operations), each with three security practices. Every practice has two streams of activities over three maturity levels, which makes 90 activities in total.
The OWASP SAMM model. Source: owaspsamm.org, CC BY-SA 4.0.
SAMM’s levels describe progression within the same practice:
- Level 0: the practice isn’t in place.
- Level 1: an ad hoc, best-effort implementation.
- Level 2: a consistent, repeatable process you can rely on.
- Level 3: effectiveness maximized through continuous improvement, based on timely feedback.
Each assessment question comes with quality criteria and graded answers between 0 and 1, so partial implementation earns partial credit. A practice that’s in place for some teams scores higher than one that isn’t there at all, which reflects reality better and keeps teams motivated.
SAMM also doesn’t expect you to reach level 3 everywhere. You set the target level for each practice yourself, based on your risks and goals.
Side by side
The structures look different, but they cover largely the same ground. The table below is a simplified, domain-level comparison; the SAMM project publishes a detailed mapping of BSIMM activities to SAMM streams.
| BSIMM domain | BSIMM practices | Closest SAMM business function and practices |
|---|---|---|
| Governance | Strategy & Metrics; Compliance & Policy; Training | Governance: Strategy & Metrics; Policy & Compliance; Education & Guidance |
| Intelligence | Attack Models; Security Features & Design; Standards & Requirements | Design: Threat Assessment; Secure Architecture; Security Requirements |
| SSDL Touchpoints | Architecture Analysis; Code Review; Security Testing | Verification: Architecture Assessment; Requirements-driven Testing; Security Testing |
| Deployment | Penetration Testing; Software Environment; Configuration Management & Vulnerability Management | Operations: Incident Management; Environment Management; Operational Management |
| (spread over several practices) | – | Implementation: Secure Build; Secure Deployment; Defect Management |
The most visible difference is SAMM’s Implementation function. Secure build pipelines, secure deployment and defect management have their own practices in SAMM, while BSIMM spreads related activities over other practices. If software supply chain security and your CI/CD pipeline are where your risk sits, that’s worth knowing.
And the key factors beyond structure:
| BSIMM | OWASP SAMM | |
|---|---|---|
| Purpose | Descriptive: observes and reports what organizations do | Prescriptive: guides you in what to do next |
| Ownership | Run by a vendor, Black Duck | Open-source OWASP flagship project, run by a volunteer community |
| Assessment | Performed by the vendor's assessors | By your own team, or with an external practitioner of your choice |
| Scoring | Binary per activity | Graded per activity, 0 to 1, with quality criteria |
| Levels | How common an activity is among participants | How mature a practice is in your organization |
| Tooling | Vendor tools | Free tools, such as the SAMM Toolbox spreadsheet and web tools like SAMMwise |
| Benchmark | Large, consistent data set from vendor-led assessments | Smaller, community-donated data set |
| Improvement guidance | Assessment report and advice from the assessors | Public guidance per activity, plus community support |
| Cost | Paid assessment | Free; you pay only for your own time or a consultant |
Assessment: by yourself or with professionals
A BSIMM assessment is done by the vendor’s assessors. They interview stakeholders across the organization, collect evidence for each activity and produce a scorecard with your results next to the community data. It’s consistent and independent, and that has a side effect: because the organization paid for an outside assessment, management tends to take the results seriously.
A SAMM assessment can be done by your own team, or with an external practitioner. You define one or more assessment scopes, such as a business unit or a product line, interview the people involved and answer the questions with the quality criteria in front of you. The free tools calculate the scores and show the results per practice.
Scopes matter more than they seem. Different business units can have different risks, technologies and starting points, and with SAMM each scope gets its own score and its own roadmap.
A word of caution for both models: a maturity assessment works best as an honest internal tool. Once the scores are used to judge teams, or as an audit, people start answering for the score instead of describing reality. Keep that separation clear, and teams will tell you where they actually struggle.
Roadmap: small achievable steps
The assessment is only the start. Its real value is the roadmap that follows:
- Prioritize the gaps by risk and business goals, not by which score looks lowest.
- Break the work into small, achievable steps per quarter.
- Report progress to stakeholders in the same structure every time, so trends become visible.
- Give each scope a roadmap that fits it, instead of one plan for the whole company.
SAMM is built around this cycle: assess, set targets, implement, reassess. BSIMM gives you the comparison with peers and leaves the choice of activities to you and your assessors.
Benchmarks
Benchmarking is where BSIMM has traditionally been strongest. Its data comes from consistent, vendor-led assessments of more than a hundred organizations each year. It tells you which activities organizations like yours perform, which is useful when you need to show executives or customers where you stand.
There’s a bias to keep in mind. BSIMM participants are mostly large organizations with established security programs: the 111 firms in BSIMM16 employ about 223,700 developers between them, around 2,000 per firm, and their security initiatives are 5.6 years old on average. The community average is therefore not representative of the industry as a whole, and a smaller company that compares itself with it will look worse than it really is.
SAMM now has a benchmark too. The SAMM Benchmark collects anonymized assessment data donated by practitioners and organizations. Its first report is based on 30 assessments, and it can segment results by company size; comparison by industry is a goal once there’s enough data to keep submissions anonymous. It’s much smaller than BSIMM’s data set, and because the data comes from many different assessors it’s less consistent. It also skews toward global multinationals for now. Every data set donated makes it better, so if you’re comfortable sharing your results anonymously, please do.
Guidance for improvement
With BSIMM, improvement guidance comes from the assessment report and the assessors, plus the trends in the yearly report. The BSIMM16 report, for example, describes how AI-generated code and regulations like the EU Cyber Resilience Act are changing what organizations do: 30% more firms now create bills of materials for deployed software, and streamlined vulnerability disclosure grew by over 40% since BSIMM15.
With SAMM, guidance is public and community-driven. For every activity, owaspsamm.org describes the benefit, what the activity involves, the assessment question, the quality criteria and answers, and implementation guidance. You can get help through the community channels, but the implementation work happens in-house, or with a consultant you choose.
Which model is better?
The statistician George Box said it best: “All models are wrong, but some are useful.” Neither model describes your organization perfectly. The right question is which one is more useful for what you’re trying to do.
Choose BSIMM if you’re a large organization with an established program, you need an independent, consistent benchmark against peers, and you value an outside assessment that management will take seriously.
Choose SAMM if you’re building or growing a program and want clear guidance on what to do next, if you want to assess yourself and repeat it often at low cost, or if you need different roadmaps for different parts of the organization.
Combining them is also an option. Some organizations run SAMM internally to steer the work and do a BSIMM assessment every few years for an external benchmark.
What matters most is that you use one. Every company that builds software should use a maturity model to assess, plan and track its application security work. And if you’re preparing for the EU Cyber Resilience Act, a maturity model gives you a structured way to show that security by design is more than a policy document. Our CRA guide for SMBs explains how SAMM fits into that.
What to do next
Next week:
- Familiarize yourself with both models.
- Review how your organization currently approaches software security, and decide whether SAMM, BSIMM or a combination fits your needs.
- Talk to your software development colleagues and key stakeholders about how security maturity is assessed and improved today, and listen to their first reactions.
In the next three months:
- Run a first assessment with SAMM or BSIMM.
- Set clear maturity targets and priorities.
- Start on small, actionable improvements based on the findings.
And remember: application security is a journey, not an exam. Long-term trends tell you far more than the score of any single assessment.
If you want an experienced practitioner to run that first assessment with you, our SSDLC maturity assessment is based on OWASP SAMM. The Measure and Improve article helps you pick the metrics to track progress afterwards.
Resources
- OWASP SAMM: the model, guidance, tools and benchmark
- BSIMM: the latest BSIMM report from Black Duck