Using OWASP SAMM to measure secure development maturity

For many UK SMEs, secure development starts with a familiar pattern: a few coding standards, some security testing, and perhaps a checklist for releases. That is a useful foundation, but it does not tell you whether your software development capability is improving in a structured way. This is where OWASP SAMM, the Software Assurance Maturity Model, becomes valuable.

SAMM is not a compliance shortcut and it is not a replacement for secure coding guidance, threat modelling, or testing. It is a maturity model that helps you measure how well security is embedded into the way software is built and operated. For technical teams, that makes it useful as a management tool as much as a security one. It gives you a way to baseline current practice, identify gaps, and track whether improvements are actually sticking.

If you already use practices such as secure design reviews, application security testing, and dependency scanning, SAMM helps you understand how consistently those practices are applied across teams and products. It also helps you avoid the common problem of assuming that having a tool in place means the underlying process is mature. A pipeline can run SAST on every merge request and still be weak if findings are ignored, exceptions are unmanaged, or ownership is unclear. For a broader view of secure development foundations, it is worth pairing SAMM with secure SDLC principles and secure CI/CD practices.

What OWASP SAMM is and where it fits in a secure development programme

SAMM organises secure development into business functions and practices, then describes maturity across those practices. In practical terms, it gives you a structured way to ask questions such as: do we understand the security risks in our design process, do we test consistently, do we manage vulnerabilities with clear ownership, and do we learn from production issues?

That makes SAMM different from a control checklist. A checklist tells you whether a control exists. SAMM asks how well the control is embedded, measured, and improved. For example, you might have a dependency scanning tool in your build pipeline, but SAMM would push you to look at whether the tool is configured consistently, whether exceptions are risk accepted, whether false positives are triaged, and whether remediation times are tracked.

It is also different from a narrow secure coding standard. Secure coding guidance is essential, but it usually focuses on implementation detail at the code level. SAMM sits above that and looks at the operating model around development. That includes governance, design, implementation, verification, and operations. In other words, it helps answer whether security is a repeatable capability or just a collection of good intentions.

For engineering and security leaders, maturity models are useful because they create a common language. Product managers, developers, architects, and security teams can all discuss the same baseline without reducing everything to a pass or fail result. That is particularly helpful in SMEs, where the same people often wear multiple hats and there is limited appetite for heavyweight assurance processes. A maturity model can be scaled to the size of the organisation while still giving enough structure to support improvement.

How SAMM measures maturity in practice

SAMM works by assessing practices across several business functions, then scoring maturity within each one. The exact structure can vary by version and implementation, but the practical idea is consistent: you assess how well security is embedded in the software lifecycle, not just whether a single control exists.

In a typical assessment, you gather evidence for each practice and compare what you do today with the maturity characteristics described by the model. That evidence might include architecture review records, secure coding standards, CI/CD configuration, vulnerability management workflows, test results, incident learnings, and training records. The point is not to produce a glossy report. The point is to understand the current operating state.

A baseline assessment can tell you several useful things. It can show where security is strong in one product team but weak in another. It can reveal whether controls are manual and person-dependent, or repeatable and embedded in tooling. It can also expose where the organisation is relying on informal knowledge rather than documented and owned processes.

What it cannot tell you is whether the organisation is safe in an absolute sense. A high maturity score does not mean there are no vulnerabilities, and a low score does not mean the next release is doomed. SAMM is a management signal, not a guarantee. It helps you understand capability and consistency, which are both important, but it does not replace threat modelling, testing, or operational monitoring.

Preparing for a SAMM assessment

The quality of a SAMM assessment depends heavily on scope. If you define scope too broadly, the exercise becomes slow and vague. If you define it too narrowly, the results will not be useful. For UK SMEs, a practical starting point is to scope by product, platform, or delivery stream rather than by the whole company at once.

For example, you might assess a customer-facing SaaS platform separately from an internal line-of-business application. That lets you compare maturity where the delivery model is similar and avoids mixing very different risk profiles. You should also be clear about whether you are assessing one team, one product, or the whole engineering function. If your organisation uses shared platform teams, separate the responsibilities so you do not double count controls or miss ownership gaps.

Evidence collection should be lightweight but real. Good evidence usually comes from the systems and workflows the team already uses, not from documents created purely for the assessment. Useful sources include:

• Architecture decision records and design review notes
• Pull request templates and merge approval rules
• CI/CD pipeline definitions, such as GitHub Actions, GitLab CI, or Azure DevOps YAML
• SAST, DAST, and software composition analysis outputs
• Issue tracker tickets showing vulnerability triage and remediation
• Secrets management configurations and access policies
• Release gates, exception records, and risk acceptances
• Incident post-incident reviews and lessons learned

If you already have secure design checkpoints in place, those artefacts can be strong evidence. The same is true for automated controls in the pipeline, provided they are enforced rather than merely reported. For example, a build that fails on critical dependency vulnerabilities is more meaningful than a dashboard that nobody checks. If you need a deeper reference point for design-stage controls, our article on secure design reviews and architecture checkpoints in the SDLC is a useful companion.

Interpreting SAMM maturity levels without over-reading the score

One of the most common mistakes is to treat maturity levels as a scoreboard. That is not how SAMM is most useful. A score is only meaningful when you understand what operational behaviour sits behind it.

At lower maturity, security practices are often ad hoc. Teams may know what they should do, but execution depends on individual effort. Threat modelling might happen only for major changes. Security testing may be manual and inconsistent. Vulnerability remediation may rely on engineers noticing alerts rather than on a defined process. In this state, the main issue is usually inconsistency rather than total absence of controls.

At intermediate maturity, practices start to become repeatable. There may be standard templates, defined approval paths, and some automation in the pipeline. Security requirements are more likely to be documented, and teams can show evidence of regular testing or review. However, the process may still vary between teams, and exceptions may not be managed in a disciplined way.

At higher maturity, security is more integrated into normal delivery. Controls are measured, automated where possible, and supported by clear ownership. Teams can show trend data, not just point-in-time evidence. They can explain how findings flow from testing into remediation, how exceptions are approved, and how lessons learned feed back into design and implementation.

The mistake to avoid is assuming that a higher score automatically means better security outcomes. A mature process can still be poorly targeted if the team is measuring the wrong things. Likewise, a lower score in one area may be acceptable if the underlying risk is low and the team has deliberately chosen a lighter control set. Maturity should be interpreted in context, alongside business risk and delivery constraints.

Turning SAMM findings into a practical improvement plan

The real value of SAMM comes after the assessment. If the output is just a heat map and a workshop deck, the exercise will not change much. The findings need to become a prioritised improvement plan with owners, milestones, and measurable outcomes.

Start by grouping gaps into three categories: high risk, high effort, and low effort. High-risk gaps are the ones that materially affect confidentiality, integrity, or availability, or that create obvious supply chain exposure. High-effort items may still be important, but they need sequencing and dependency management. Low-effort items are useful quick wins that can build momentum.

For example, if you find that dependency updates are handled manually across several repositories, that may be a good candidate for automation because the effort is manageable and the risk reduction is immediate. If you find that architecture reviews are inconsistent, you may need to standardise the review template before you can automate anything. If you discover that vulnerability remediation has no service level target, that is usually a governance gap that should be addressed early.

Each action should have a named owner, a target date, and a success measure. Good metrics are specific. Rather than saying “improve security testing”, define the measure as “percentage of production services with automated security tests in the release pipeline” or “median time to remediate critical application vulnerabilities”. If you want to prioritise remediation more effectively, our article on using CVE and CWE data to prioritise remediation is a useful next step.

It is also worth linking SAMM actions to delivery metrics. If a control adds too much friction, teams may bypass it. If a control is invisible, teams may not maintain it. The best improvements are the ones that fit the way engineers already work. For instance, adding policy checks to pull requests, enforcing secret scanning in pre-commit hooks, or requiring security sign-off only for defined high-risk changes can improve maturity without creating unnecessary bureaucracy.

Using SAMM alongside other security frameworks

SAMM is most effective when it is used alongside other frameworks rather than as a standalone model. Each framework answers a different question.

OWASP ASVS is useful when you want to define application security requirements at a more detailed control level. It tells you what the application should do. SAMM tells you how well the organisation is able to deliver and sustain those controls. Microsoft SDL is helpful when you want a structured set of secure development practices. SAMM can then be used to measure whether those practices are actually embedded across teams. DevSecOps provides the delivery model, especially where automation and continuous integration are central. SAMM helps you assess whether that model is mature or still dependent on manual effort.

NIST CSF can also be a useful companion because it gives a broader risk management structure. SAMM is narrower and more development-focused, so it fits well inside a wider security programme. In practice, many SMEs use SAMM to assess engineering capability, then map the results into a broader risk register or security roadmap. That makes it easier to communicate with leadership without losing technical detail.

If you are already working with software supply chain assurance, SAMM can help you assess whether supplier controls are actually operationalised. For example, if your procurement process requires SBOMs, signed artefacts, or vulnerability disclosure commitments, SAMM can help you check whether those requirements are consistently enforced in delivery. Our article on software supply chain assurance controls covers that operational side in more detail.

What good evidence looks like for a technical team

Technical teams often ask what counts as evidence in a maturity assessment. The best answer is that evidence should be objective, repeatable, and tied to actual workflow. A policy document alone is rarely enough. You want to show that the policy is implemented in the systems engineers use every day.

Good evidence examples include a branch protection rule that requires security checks before merge, a pipeline job that runs SAST and dependency scanning on every build, a ticket queue showing how findings are triaged, and an exception process that records risk acceptance and expiry dates. If you have container scanning, show the configuration and the failure thresholds. If you have infrastructure as code scanning, show the rule set and how false positives are handled. If you use secrets management, show that no long-lived secrets are stored in source control and that access is role-based.

Architecture artefacts can also be strong evidence when they are current and used. A threat model that is reviewed during major changes is more valuable than a one-off diagram. Similarly, a post-incident review that results in backlog items, control changes, or test cases demonstrates that the organisation learns from operational issues.

Tooling outputs are useful, but only when they are connected to action. A dashboard showing hundreds of findings is not evidence of maturity unless there is a clear process for prioritisation and closure. The same applies to training records. Training is useful, but maturity depends on whether the training changes engineering behaviour.

How often to reassess maturity and track progress

There is no single reassessment interval that fits every SME. The right cadence depends on delivery speed, team size, and how much change is happening in the environment. For fast-moving product teams, a quarterly or half-yearly review can be sensible. For smaller teams with slower release cycles, an annual assessment may be enough, provided there is some lighter-weight tracking in between.

The key is to avoid treating SAMM as a one-off exercise. If you only assess once, you get a snapshot. If you reassess regularly, you get trend data. Trend data is much more useful because it shows whether the organisation is improving in the areas that matter. It also helps you spot where a control has drifted, perhaps because a team changed, a tool was replaced, or a process was bypassed under delivery pressure.

Track a small number of metrics alongside the maturity model. Useful examples include percentage of services with threat models, percentage of repositories with automated security checks, mean time to remediate critical vulnerabilities, and number of security exceptions past expiry. These measures help you see whether maturity is translating into operational change.

For SMEs, the aim should be steady improvement rather than perfect coverage. A mature programme is one that can show progress, explain trade-offs, and adapt as the product and threat landscape change.

Practical limitations and trade-offs when using SAMM

SAMM is helpful, but it can become too heavy if you try to apply it as a full-scale enterprise programme in a small team. That is the main trade-off. The model is only useful if the assessment effort is proportionate to the size and risk of the organisation.

In smaller teams, keep the assessment focused on the practices that matter most to your delivery model. You do not need to assess every possible area at once. Start with the parts of the lifecycle that create the most risk, such as architecture, implementation, verification, and vulnerability management. Then expand as the team matures.

It is also sensible to keep the evidence bar realistic. If you require too much documentation, teams will spend time producing artefacts rather than improving security. If you require too little, the assessment becomes subjective. The right balance is evidence that already exists in the engineering workflow and can be reviewed without much extra effort.

Finally, remember that maturity is not the same as risk appetite. A business may choose to accept lower maturity in a low-risk internal tool, while investing more heavily in a customer-facing platform or a regulated service. That is a valid trade-off if it is deliberate, documented, and reviewed.

Used well, OWASP SAMM gives technical teams a practical way to measure secure development maturity without turning the exercise into a compliance project. It helps you see where security is repeatable, where it still depends on individuals, and where investment will make the biggest difference. For many UK SMEs, that is exactly the kind of clarity needed to improve security in a way that supports delivery rather than competing with it.

If you would like help turning a SAMM baseline into a realistic improvement roadmap, or want support aligning secure development practices with your wider information security programme, speak to a consultant.

Frequently asked questions

What are the OWASP SAMM maturity levels?

SAMM maturity levels describe how embedded and repeatable a security practice is, moving from ad hoc activity towards defined, measured, and continuously improved processes. The exact labels can vary by version, but the practical idea is to show whether a team relies on individuals, standard processes, or data-driven improvement.

Can OWASP SAMM be used for small engineering teams?

Yes. SAMM can work well for small teams if you keep the scope focused and use evidence that already exists in delivery workflows. The model is most useful when it is applied proportionately, with a small set of high-value practices assessed first and expanded over time.