Run an OWASP SAMM assessment with evidence and a practical roadmap

OWASP SAMM version 2 organizes improvement across five business functions and fifteen security practices. A maturity assessment asks whether defined activities operate within a chosen scope; it does not score the security of every product. Define teams, products, time period and assessment method before collecting answers. Different teams can have different practices, so averaging them into one number can hide the service where a critical activity is absent.

The fictional Ash group has three teams and twenty eligible design changes during one quarter. Its interview says all important designs are reviewed, but records cover only twelve changes. The assessment must preserve that mismatch. Choose a representative or risk-based sample and state its limits. A convenience sample of the team's best release is not evidence for the entire quarter. Where this guide uses numerical coverage, it is an internal measure of supplied evidence, not the official SAMM scoring algorithm.

SAMM version 2 arranges 15 security practices under five business functions, as in the table. Each practice has two streams, A and B, and each stream describes one activity at each of three maturity levels. Ash’s design reviews fall mainly under Design: Threat Assessment, whose stream B is Threat Modeling, with follow-up in Verification: Architecture Assessment.

The assessment answers one question per activity with “No” (0), “Yes, for some” (0.25), “Yes, for half” (0.5) or “Yes, for most” (1). A stream’s score is the sum of its three activities, so it ranges from 0 to 3; a practice averages its two streams, and business functions and the overall score average the levels below them. Because averages hide a missing activity, report the stream scores and the evidence behind each answer, not only the overall number. SAMM’s “percent to target” and “progress to date” measures compare current scores with a chosen target and baseline, which suits a roadmap better than chasing a perfect 3.

The current release of the SAMM core model is 2.2.0, published in the owaspsamm/core repository on 6 July 2026; its answer sets keep the 0, 0.25, 0.5 and 1 values, though the wording of the scale varies by activity (applications, teams, components or training). For how SAMM differs from BSIMM and NIST SSDF, see /frameworks/bsimm-samm-ssdf/.

Record one row per activity with the answer and the evidence behind it, not only the score. A reviewer can then sample rows and follow the evidence, and next year's assessment can compare like with like. The sample covers the Design function for the fictional Ash group.

function,practice,stream,level,answer,evidence
Design,Threat Assessment,A,1,0.5,risk profiles for 2 of 3 teams
Design,Threat Assessment,A,2,0.25,one central risk catalog entry
Design,Threat Assessment,A,3,0,
Design,Threat Assessment,B,1,0.5,12 of 20 eligible changes reviewed
Design,Threat Assessment,B,2,0,
Design,Threat Assessment,B,3,0,
Design,Security Requirements,A,1,1,requirements files in all three repositories
Design,Security Requirements,A,2,0.25,ASVS baseline used by API team only
Design,Security Requirements,A,3,0,
Design,Security Requirements,B,1,0.5,vendor questionnaire for 2 of 4 suppliers
Design,Security Requirements,B,2,0,
Design,Security Requirements,B,3,0,
Design,Secure Architecture,A,1,1,
Design,Secure Architecture,A,2,0,
Design,Secure Architecture,A,3,0,
Design,Secure Architecture,B,1,0.25,TLS and secrets standards documented
Design,Secure Architecture,B,2,0,
Design,Secure Architecture,B,3,0,

The script applies the scoring described above: a stream is the sum of its three activity answers, a practice is the mean of its two streams and a business function is the mean of its practices. It rejects answers other than 0, 0.25, 0.5 and 1 and flags any positive answer with no evidence. On the sample it prints Threat Assessment 0.625, Security Requirements 0.875 and Secure Architecture 0.625, a Design function score of 0.708, and flags Secure Architecture stream A level 1, which claims "most or all" with no evidence. Report the stream scores and the flags, not only the function score. Tested with Python 3.14.

"""Score SAMM answers: stream = sum of its three activity answers (0-3), practice = mean of
its two streams, business function = mean of its practices. Flags answers above 0 without evidence.

Usage: python samm_score.py samm-answers.csv
"""
import csv
import sys
from collections import defaultdict
from statistics import mean

ALLOWED = {0.0, 0.25, 0.5, 1.0}


def score(rows):
    streams = defaultdict(float)
    for r in rows:
        answer = float(r["answer"])
        if answer not in ALLOWED:
            raise ValueError(f"{r['practice']} {r['stream']}{r['level']}: answer must be 0, 0.25, 0.5 or 1")
        if answer > 0 and not r["evidence"].strip():
            print(f"NO EVIDENCE {r['practice']} stream {r['stream']} level {r['level']} (answer {answer})")
        streams[(r["function"], r["practice"], r["stream"])] += answer
    practices = defaultdict(list)
    for (function, practice, _), value in streams.items():
        practices[(function, practice)].append(value)
    functions = defaultdict(list)
    for (function, practice), values in practices.items():
        print(f"{practice:24} streams {' / '.join(f'{v:.2f}' for v in values)}  practice {mean(values):.3f}")
        functions[function].append(mean(values))
    for function, values in functions.items():
        print(f"{function} function score {mean(values):.3f}")


if __name__ == "__main__":
    with open(sys.argv[1], newline="", encoding="utf-8") as f:
        score(list(csv.DictReader(f)))

Interview answers explain how the team believes work happens. Operating records show whether the claimed activity occurred: design decisions, review comments, release gates, security tests and follow-up actions. A template proves the organization can create a record; it does not prove engineers used it. A calendar invitation proves a meeting was scheduled; it does not show the threat was considered or an action closed. Assess the substantive behavior required by the selected SAMM activity and quality criteria.

In Ash's sample, four reviewed designs lack an identified trust boundary and three resulting actions have no owner. Those gaps matter even where a review record exists; /domains/appsec/threat-modeling/threat-modeling-methods/ describes what a complete review records. Counting documents can overstate the maturity of the practice. A stronger assessment reads the rationale and follows one finding into delivery, looking for a decision that changed the product. Evidence of a missed high-risk change should lower confidence in the claimed scope and trigger investigation rather than be excluded as an outlier.

A useful roadmap addresses causes and dependencies. If teams cannot identify which changes need review, adding a more elaborate review template may produce better paperwork for the same incomplete population. If actions lack owners, more assessments may expand a queue that nobody can resolve. Choose a small set of improvements with accountable roles, capacity and measurable acceptance criteria. The sequence should reflect current consequences rather than a desire to raise every maturity score equally.

Ash has capacity for two initiatives. One defines review triggers and integrates them into change intake; another creates action ownership and expiry rules. Advanced automation can follow after the underlying decision rules are stable. This is a tradeoff: delaying automation sacrifices immediate scale, but automating an ambiguous process can institutionalize its blind spots. SSDF can help connect the selected improvements to lifecycle work (/frameworks/ssdf-product-lifecycle/), while SAMM remains the chosen maturity model. A cross-reference does not make the models interchangeable.

Reassessment should use the same scope and definitions, or explicitly document changes. Compare eligible changes, review coverage, review quality and action completion. If intake improves and discovers more eligible changes, a lower apparent coverage percentage may reflect a more honest denominator. Do not remove late or failed work from the cohort simply because it would lower the score. Retain the previous assessment and explain how new evidence changes confidence.

The exercise's next-quarter target is a local operating goal: at least 90% of eligible changes reviewed, all reviewed high-risk changes with a trust-boundary argument, and all actions assigned an owner and due date. Meeting it would demonstrate progress on these measures, not automatic achievement of a named SAMM maturity level. Apply the official assessment's activity questions and quality criteria before making a level claim. This distinction lets teams use quantitative feedback without fabricating a certification from a dashboard.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP SAMM version 2 model
2. OWASP SAMM core model release v2.2.0. 6 July 2026.
3. OWASP SAMM: Threat Assessment practice
4. OWASP SAMM blog: SAMM scoring, percent to target and progress to date
5. NIST SP 800-218: SSDF 1.1, final. Version 1.1 (February 2022).

Reference information

Tags

AppSec programsCompliance and assurance evidence

SDLC phase

Security program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring