OWASP Software Assurance Maturity Model (SAMM)

Best Practice: OWASP Software Assurance Maturity Model (SAMM)

The OWASP Software Assurance Maturity Model (SAMM) is an open framework for measuring and improving how an organization builds software securely. It is organized into five business functions, governance, design, implementation, verification, and operations, each with security practices scored across maturity levels. SAMM matters because it shifts security from a checklist of tools to a measurable program. Leaders can see where they stand, set realistic targets, and track improvement over time rather than guessing. For a new team it answers "where do we even start?" by ranking gaps; for leadership it turns security spend into a tracked maturity curve. The main trade-off is honesty: a self-assessment is only as useful as the candor of the people scoring it. Because the model is technology-neutral, it works equally well for a startup with a handful of services and a large enterprise with hundreds. The assessment itself is lightweight, often a workshop and a spreadsheet, so the cost of getting a first honest baseline is low compared with the clarity it provides about where to invest next.

Step-by-Step Implementation Guidance

1. Run a SAMM assessment to score each security practice at its current maturity level.
2. Define target maturity levels per practice based on risk and business goals, not perfection.
3. Identify the largest gaps between current and target maturity.
4. Build a roadmap of concrete activities that close those gaps in priority order.
5. Assign owners and timelines for each roadmap item.
6. Re-assess on a regular cadence (for example every 6 to 12 months) to measure progress.
7. Report maturity trends to leadership to justify continued investment.

Common Mistakes Teams Make When Ignoring This Practice

• Buying security tools without a program to measure whether they reduce risk.
• Aiming for maximum maturity everywhere instead of risk-appropriate targets.
• Running one assessment and never re-measuring, so progress is invisible.
• Treating SAMM as an audit exercise rather than a planning and budgeting tool.
• Ignoring governance and operations while over-focusing on code-level controls.
• Letting one person score the whole organization, producing a flattering but inaccurate baseline.

Tools and Techniques That Support This Practice

• The official OWASP SAMM toolbox and assessment spreadsheets.
• OWASP ASVS to define concrete verification requirements within the model.
• Threat modeling practices to strengthen the design function.
• CI/CD security gates and SAST/DAST to support implementation and verification.
• Dashboards and trackers to record maturity scores and roadmap progress.
• Benchmarking data to compare your maturity against peers in similar industries.

How This Practice Applies to Different Migration Types

• Cloud Migration: Use SAMM to confirm operations and incident response practices mature alongside new cloud infrastructure.
• Database Migration: Strengthen design and verification practices covering data classification and protection before moving sensitive data.
• SaaS Migration: Assess vendor governance and operations maturity as part of third-party risk decisions.
• Codebase Migration: Use the implementation and verification functions to set security standards the migrated code must meet.

Checklist

• Completed a baseline SAMM assessment
• Defined risk-appropriate target maturity levels
• Identified and prioritized the largest gaps
• Built a roadmap with owners and timelines
• Scheduled periodic re-assessment
• Reported maturity trends to leadership
• Linked roadmap items to concrete security activities