OWASP SAMM Assessment Template
OWASP SAMM v2 assessment: 15 practices and 30 streams, original prompts per level, scoring formulas, current vs target scores, findings, phased roadmap, metrics
使用方法: Use it to baseline and improve a software security programme with OWASP SAMM v2. Fill the scope, method and answers per stream first, then set risk-based targets and the phased roadmap. The main pitfall is scoring the whole company as one unit or setting level 3 targets everywhere.
预览
OWASP SAMM Assessment: [Organisation or assessment scope]
Maturity assessment of a software security programme using the OWASP Software Assurance Maturity Model (SAMM) version 2: five business functions, fifteen security practices, two streams per practice and three maturity levels. The template records the scope, the scoring method, current and target scores, findings and a phased improvement roadmap. Model structure as published at owaspsamm.org (model v2; core release v2.2.0, July 2026). The assessment prompts in section 4 are original wording written for this template, not the official SAMM questionnaire; use the SAMM Toolbox if you need the official questions. Worked examples use Corvid Commerce, a fictional SaaS company. Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | [SAMM-ASSESS-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@appsec-lead] |
| Approvers / reviewers | [@ciso], [@cto], [@head-of-engineering] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential |
| Assessment scope | [Example: Corvid Commerce product engineering: 9 product teams and the platform team] |
| SAMM model version | OWASP SAMM v2 (core release v2.2.0) |
| Scoring method | Section 3.3 of this document |
| Assessment window | YYYY-MM-DD to YYYY-MM-DD |
| Previous assessment | [Document ID and date, or "First assessment"] |
| Next assessment | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Chief information security officer (sponsor) | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief technology officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of engineering | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after interviews |
| 0.2 | YYYY-MM-DD | [@name] | Example: Scores calibrated with practice owners; targets added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved with roadmap phases 1 and 2 funded |
Contents
1. Introduction and scope
1.1 Purpose and drivers
| Driver | Description |
|---|---|
| [Business driver] | [Example: Enterprise customers ask for evidence of a structured application security programme] |
| [Risk driver] | [Example: Two critical vulnerabilities in 2026 traced to missing design review] |
| [Regulatory or contractual driver] | [Example: Contract clauses referencing NIST SP 800-218; EU Cyber Resilience Act obligations for the SDK] |
| [Programme driver] | [Example: Baseline before funding the security champions programme] |
1.2 Scope
| Item | Value |
|---|---|
| Organisational units | [Example: Product engineering (9 teams), platform team, SRE] |
| Applications or products | [Example: Corvid Storefront SaaS, Corvid Checkout SDK, internal admin tools] |
| Excluded | [Example: Corporate IT, acquired product "Corvid Lite"] |
| Roll-up rule | [Example: One assessment for the whole scope; teams that differ by more than one answer step are noted in findings] |
1.3 Assessment approach
Choose one approach and keep it for later cycles:
- Interview-based: facilitated sessions with practice owners and a sample of teams; answers recorded with the interviewee role. Fast; less rigorous.
- Evidence-based: each answer supported by an artefact reference
(
EVD-NNN). Slower; suitable when results are shared with customers or auditors. - Hybrid (recommended): interviews for all streams, evidence for any answer at or above "at least half".
Example: Corvid Commerce used the hybrid approach, with 14 interviews and 62 evidence items.
2. The SAMM model
SAMM v2 organises software security into five business functions. Each
function has three security practices. Each practice has two streams (A and
B) that progress through three maturity levels. Level 1 is an initial,
ad hoc implementation; level 2 is a structured, more efficient one; level 3
is comprehensive and optimised. This template uses the identifiers from the
SAMM core model files, for example G-SM-A for Governance, Strategy and
Metrics, stream A.
| Business function | Security practice | ID | Stream A | Stream B |
|---|---|---|---|---|
| Governance | Strategy and Metrics | G-SM | Create and Promote | Measure and Improve |
| Governance | Policy and Compliance | G-PC | Policy and Standards | Compliance Management |
| Governance | Education and Guidance | G-EG | Training and Awareness | Organization and Culture |
| Design | Threat Assessment | D-TA | Application Risk Profile | Threat Modeling |
| Design | Security Requirements | D-SR | Software Requirements | Supplier Security |
| Design | Secure Architecture | D-SA | Architecture Design | Technology Management |
| Implementation | Secure Build | I-SB | Build Process | Software Dependencies |
| Implementation | Secure Deployment | I-SD | Deployment Process | Secret Management |
| Implementation | Defect Management | I-DM | Defect Tracking | Metrics and Feedback |
| Verification | Architecture Assessment | V-AA | Architecture Validation | Architecture Mitigation |
| Verification | Requirements-driven Testing | V-RT | Control Verification | Misuse/Abuse Testing |
| Verification | Security Testing | V-ST | Scalable Baseline | Deep Understanding |
| Operations | Incident Management | O-IM | Incident Detection | Incident Response |
| Operations | Environment Management | O-EM | Configuration Hardening | Patching and Updating |
| Operations | Operational Management | O-OM | Data Protection | System Decommissioning / Legacy Management |
SAMM also describes an improvement cycle of six steps: Prepare, Assess, Set the Target, Define the Plan, Implement and Roll Out. Sections 1 to 5 of this template cover Prepare and Assess, section 6 sets the target, and sections 8 and 9 define, implement and roll out the plan.
3. Assessment method
3.1 Roles
| Activity | AppSec lead (assessor) | Practice owners | Team leads | Security champions | CISO |
|---|---|---|---|---|---|
| Plan scope and schedule | A/R | C | I | I | C |
| Run interviews | R | C | C | C | I |
| Provide evidence | C | R | R | R | I |
| Score and calibrate | A/R | C | C | C | I |
| Set targets | R | C | C | I | A |
| Approve roadmap | C | C | I | I | A |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
3.2 Evidence rules
- Record one answer per stream per level, with the interviewee role and, for answers above "some", at least one evidence reference.
- Answer for the whole scope. When teams differ, the answer reflects the share of the scope that meets the prompt.
- Do not credit planned or piloted activity unless it operates for the share claimed.
- Note quality concerns in the findings even when the activity exists (for example, threat models that are never updated).
3.3 Answer scale and scoring
Each prompt in section 4 is answered on a four-step coverage scale:
| Answer | Meaning | Value |
|---|---|---|
| None | The activity is not performed, or only by individual initiative | 0 |
| Some | Performed for a minority of the scope | 0.25 |
| At least half | Performed for at least half of the scope | 0.5 |
| Most or all | Performed for most or all of the scope, consistently | 1 |
Formulas.
- Stream score = L1 value + L2 value + L3 value (range 0 to 3).
- Practice score = (stream A score + stream B score) / 2 (range 0 to 3).
- Business function score = mean of its three practice scores.
- Overall score = mean of the fifteen practice scores.
This additive approach follows the spreadsheet-style scoring used by the SAMM Toolbox, which publishes answer sets with values of 0, 0.25, 0.5 and 1. Check owaspsamm.org/assessment for the current Toolbox and its rules before comparing your scores with other organisations.
Optional gating rule. Some assessors credit a higher level only when the lower level scores at least 0.5. If you apply the rule, state it here and apply it in every cycle: [Applied / Not applied].
3.4 Calibration
Hold a calibration session after interviews. For each stream, the assessor presents the proposed answers and evidence; practice owners may challenge. Record changed answers and the reason. Target a variance of no more than one answer step between assessors scoring the same stream.
4. Assessment prompts
Each row gives one prompt per maturity level for a stream. Answer each prompt on the scale in section 3.3.
4.1 Governance
| Stream | Level 1 prompt | Level 2 prompt | Level 3 prompt |
|---|---|---|---|
| G-SM-A Create and Promote | Have business drivers and risk tolerance for software security been agreed with leadership? | Is there a published multi-year software security plan with budget and owners? | Is the plan reviewed against business changes and adjusted on a fixed cycle? |
| G-SM-B Measure and Improve | Are a few security measures defined and collected? | Do the measures have targets and feed regular management reports? | Do results drive changes to the programme strategy? |
| G-PC-A Policy and Standards | Is there an approved secure development policy covering all teams? | Are there technology-specific standards (languages, frameworks, cloud) derived from the policy? | Is adherence to standards measured and reported per team? |
| G-PC-B Compliance Management | Are external obligations (laws, contracts, certifications) affecting software identified? | Are those obligations mapped to internal controls and standards? | Is compliance status measured and gaps tracked to closure? |
| G-EG-A Training and Awareness | Do all engineers receive baseline secure development awareness training? | Is there role-specific training (developer, tester, architect, manager)? | Is training content maintained internally with organisation-specific lessons, and is proficiency assessed? |
| G-EG-B Organization and Culture | Does each team have a named security contact or champion? | Is there a central group that supports teams with guidance and reusable solutions? | Is there an active internal community that shares practices and influences standards? |
4.2 Design
| Stream | Level 1 prompt | Level 2 prompt | Level 3 prompt |
|---|---|---|---|
| D-TA-A Application Risk Profile | Is a basic risk rating assigned to applications? | Is there a complete inventory of applications classified by risk? | Are risk profiles reviewed periodically and used to drive security activities? |
| D-TA-B Threat Modeling | Are threats identified for high-risk changes, even informally? | Is a standard threat modelling method used, with training and reusable threat libraries? | Are threat models maintained over time, improved from findings and partly automated? |
| D-SR-A Software Requirements | Are security requirements written for new features based on business risk? | Is there a structured catalogue of security requirements that teams select from? | Are requirements tracked to verification and improved from defect and incident data? |
| D-SR-B Supplier Security | Is the security capability of key software suppliers evaluated? | Do supplier contracts include security requirements and responsibilities? | Are suppliers held to the same security standards as internal teams, with verification? |
| D-SA-A Architecture Design | Do designs apply recognised security principles such as least privilege and defence in depth? | Are shared security services and reference architectures provided and used? | Is the use of reference architectures enforced and their effectiveness reviewed? |
| D-SA-B Technology Management | Are the main technologies and frameworks in use identified with their security risks? | Is there an approved list of recommended technologies? | Is use of non-approved technology detected and handled through an exception process? |
4.3 Implementation
| Stream | Level 1 prompt | Level 2 prompt | Level 3 prompt |
|---|---|---|---|
| I-SB-A Build Process | Is the build process documented and repeatable? | Is the build automated in a pipeline that runs security checks? | Do failed security checks stop the build, and is the pipeline itself protected and verified? |
| I-SB-B Software Dependencies | Is there an inventory of third-party dependencies for each application? | Are dependencies assessed for known vulnerabilities and licence risk, with a defined response? | Are dependency risks handled proactively, including end-of-life tracking and verification of origin? |
| I-SD-A Deployment Process | Is the deployment process documented and repeatable? | Is deployment automated with security verification steps? | Is the integrity of deployed artefacts verified before release to production? |
| I-SD-B Secret Management | Are secrets kept out of source code with restricted access? | Are secrets stored in a dedicated store and injected at runtime? | Are secret issuance, rotation and revocation automated and monitored? |
| I-DM-A Defect Tracking | Are security defects recorded in a tracking system? | Are defects rated consistently and handled within agreed timeframes? | Are remediation timeframes enforced with escalation? |
| I-DM-B Metrics and Feedback | Are basic counts of security defects reported? | Are defect trends analysed regularly by team and category? | Do defect insights change standards, training and tooling? |
4.4 Verification
| Stream | Level 1 prompt | Level 2 prompt | Level 3 prompt |
|---|---|---|---|
| V-AA-A Architecture Validation | Is the architecture checked for the presence of required security mechanisms? | Is the architecture validated against the threat model and security requirements in a structured review? | Is the validation process reviewed and improved from its findings? |
| V-AA-B Architecture Mitigation | Are architectures reviewed against common threat categories? | Are identified design weaknesses tracked to mitigation? | Do review outcomes update reference architectures and shared services? |
| V-RT-A Control Verification | Are security controls tested to confirm they work as intended? | Are tests derived systematically from security requirements? | Are these tests automated and run as regression tests on each change? |
| V-RT-B Misuse/Abuse Testing | Is any testing done with unexpected or malicious input, such as fuzzing? | Are abuse cases derived from threat models and tested? | Are business-logic abuse and resilience scenarios tested regularly? |
| V-ST-A Scalable Baseline | Are automated security testing tools run against applications? | Are the tools tuned per application to reduce false positives and missed issues? | Is automated testing integrated into the pipeline with results feeding defect tracking? |
| V-ST-B Deep Understanding | Do experts manually review high-risk components? | Are penetration tests performed on a defined schedule or trigger? | Is expert testing integrated with development so that findings feed back continuously? |
4.5 Operations
| Stream | Level 1 prompt | Level 2 prompt | Level 3 prompt |
|---|---|---|---|
| O-IM-A Incident Detection | Are security events from applications logged and reviewed, even informally? | Is there a defined detection process with monitoring and alerting? | Is detection timely and measured, with tuning from incident lessons? |
| O-IM-B Incident Response | Are incident response roles and contacts known? | Is there a documented incident response process including root cause analysis? | Is the process exercised regularly and supported by a dedicated or on-call capability? |
| O-EM-A Configuration Hardening | Are systems hardened on a best-effort basis? | Are hardening baselines defined and applied consistently? | Is conformance to baselines monitored automatically, with drift corrected? |
| O-EM-B Patching and Updating | Are components patched when issues become known? | Is there a patching process with timeframes by severity? | Is patch status monitored and reported, with exceptions managed? |
| O-OM-A Data Protection | Are basic data protection practices applied to production data? | Is data classified and protected according to a policy? | Is data protection enforced and monitored automatically? |
| O-OM-B System Decommissioning / Legacy Management | Are unused applications and services identified? | Is there a decommissioning process that removes data, access and infrastructure? | Are legacy and end-of-life components managed proactively with migration plans? |
5. Current maturity scores
5.1 Stream answers and practice scores
Example answers for Corvid Commerce. L1, L2 and L3 columns show answer values for stream A / stream B.
| Practice | L1 (A / B) | L2 (A / B) | L3 (A / B) | Stream A | Stream B | Practice score |
|---|---|---|---|---|---|---|
| G-SM Strategy and Metrics | 1 / 0.5 | 0.5 / 0 | 0 / 0 | 1.5 | 0.5 | 1.00 |
| G-PC Policy and Compliance | 1 / 0.5 | 0.5 / 0.25 | 0 / 0 | 1.5 | 0.75 | 1.13 |
| G-EG Education and Guidance | 1 / 0.5 | 0.25 / 0 | 0 / 0 | 1.25 | 0.5 | 0.88 |
| D-TA Threat Assessment | 0.5 / 0.5 | 0 / 0.25 | 0 / 0 | 0.5 | 0.75 | 0.63 |
| D-SR Security Requirements | 1 / 0.25 | 0.5 / 0 | 0 / 0 | 1.5 | 0.25 | 0.88 |
| D-SA Secure Architecture | 0.5 / 1 | 0.25 / 0.5 | 0 / 0 | 0.75 | 1.5 | 1.13 |
| I-SB Secure Build | 1 / 1 | 1 / 0.5 | 0.5 / 0.25 | 2.5 | 1.75 | 2.13 |
| I-SD Secure Deployment | 1 / 1 | 1 / 0.5 | 0.25 / 0 | 2.25 | 1.5 | 1.88 |
| I-DM Defect Management | 1 / 0.5 | 0.5 / 0.25 | 0 / 0 | 1.5 | 0.75 | 1.13 |
| V-AA Architecture Assessment | 0.25 / 0.25 | 0 / 0 | 0 / 0 | 0.25 | 0.25 | 0.25 |
| V-RT Requirements-driven Testing | 0.5 / 0.25 | 0 / 0 | 0 / 0 | 0.5 | 0.25 | 0.38 |
| V-ST Security Testing | 1 / 0.5 | 0.5 / 0.25 | 0 / 0 | 1.5 | 0.75 | 1.13 |
| O-IM Incident Management | 1 / 1 | 0.5 / 0.5 | 0 / 0.25 | 1.5 | 1.75 | 1.63 |
| O-EM Environment Management | 0.5 / 1 | 0.25 / 0.5 | 0 / 0 | 0.75 | 1.5 | 1.13 |
| O-OM Operational Management | 0.5 / 0.25 | 0 / 0 | 0 / 0 | 0.5 | 0.25 | 0.38 |
Practice scores are shown to two decimals; exact values are multiples of 0.125 (for example G-PC = (1.5 + 0.75) / 2 = 1.125).
5.2 Business function summary
| Business function | Practice scores (exact) | Function score |
|---|---|---|
| Governance | 1.000, 1.125, 0.875 | 1.00 |
| Design | 0.625, 0.875, 1.125 | 0.88 |
| Implementation | 2.125, 1.875, 1.125 | 1.71 |
| Verification | 0.250, 0.375, 1.125 | 0.58 |
| Operations | 1.625, 1.125, 0.375 | 1.04 |
| Overall (mean of 15 practices) | Sum 15.625 / 15 | 1.04 |
Example reading: Corvid Commerce is strongest in Implementation, where pipeline automation is mature, and weakest in Verification, where design validation and requirements-based testing are largely ad hoc.
6. Target maturity
Example targets for the next 18 months.
| Practice | Current | Target | Gap | Rationale |
|---|---|---|---|---|
| G-SM Strategy and Metrics | 1.000 | 2.00 | 1.000 | Funding decisions need measured outcomes |
| G-PC Policy and Compliance | 1.125 | 1.50 | 0.375 | Map contract and CRA obligations to controls |
| G-EG Education and Guidance | 0.875 | 1.50 | 0.625 | Champions programme launching |
| D-TA Threat Assessment | 0.625 | 1.50 | 0.875 | Root cause of 2026 critical issues |
| D-SR Security Requirements | 0.875 | 1.50 | 0.625 | Requirements catalogue needed for SDK |
| D-SA Secure Architecture | 1.125 | 1.50 | 0.375 | Publish reference architectures |
| I-SB Secure Build | 2.125 | 2.50 | 0.375 | Protect pipeline and enforce gates |
| I-SD Secure Deployment | 1.875 | 2.25 | 0.375 | Verify artefact integrity at deploy |
| I-DM Defect Management | 1.125 | 1.75 | 0.625 | Enforce remediation timeframes |
| V-AA Architecture Assessment | 0.250 | 1.00 | 0.750 | Structured reviews for tier-1 services |
| V-RT Requirements-driven Testing | 0.375 | 1.00 | 0.625 | Test controls derived from requirements |
| V-ST Security Testing | 1.125 | 1.75 | 0.625 | Tune and integrate automated testing |
| O-IM Incident Management | 1.625 | 2.00 | 0.375 | Exercise response regularly |
| O-EM Environment Management | 1.125 | 1.75 | 0.625 | Hardening baselines with drift detection |
| O-OM Operational Management | 0.375 | 1.00 | 0.625 | Data classification and decommissioning |
| Overall | 1.04 | 1.63 | 0.59 | Sum of targets 24.5 / 15; sum of gaps 8.875 / 15 |
Target by business function (Example): Governance 1.67, Design 1.50, Implementation 2.17, Verification 1.25, Operations 1.58.
7. Findings
| Finding ID | Stream(s) | Type | Finding | Evidence | Impact |
|---|---|---|---|---|---|
| FND-001 (Example) | I-SB-A, I-SD-A | Strength | Builds and deployments are fully automated with security scans for all teams | EVD-010, EVD-014 | Strong base for adding enforcement |
| FND-002 (Example) | D-TA-B, V-AA-A | Gap | Threat models exist for tier-1 services but are not reviewed after design changes; no structured architecture validation | EVD-021 | Design flaws reach production; two 2026 criticals |
| FND-003 (Example) | V-RT-A, V-RT-B | Gap | Security controls are not tested from requirements; no abuse-case testing | Interviews 3, 7 | Broken access control found late by external testers |
| FND-004 (Example) | G-SM-B, I-DM-B | Gap | Security metrics are counted but have no targets or trend analysis | EVD-030 | Programme cannot show progress to leadership |
| FND-005 (Example) | O-OM-A, O-OM-B | Gap | No data classification; retired services keep credentials and data | EVD-044 | Data exposure and unmanaged attack surface |
| FND-006 (Example) | G-EG-B | Gap | Only 5 of 10 teams have a named security champion | Roster | Guidance does not reach half of the teams |
| FND-007 (Example) | D-SR-B | Gap | Supplier contracts lack security clauses for two key vendors | EVD-051 | Weak recourse after supplier incidents |
8. Improvement roadmap
8.1 Phases
| Phase | Window | Theme | Exit criteria |
|---|---|---|---|
| Phase 1 | [Example: Q1 to Q2] | Foundations: metrics, champions, threat model upkeep | G-SM-B L2 at "at least half"; champions in all teams |
| Phase 2 | [Example: Q3 to Q4] | Design assurance: architecture validation, requirements catalogue | V-AA-A L2 at "at least half"; catalogue in use |
| Phase 3 | [Example: Q5 to Q6] | Verification depth and operations hygiene | V-RT-A L2, O-OM-A L2 at "at least half" |
| Reassess | [Example: End of Q6] | Full reassessment with same method | Report against section 6 targets |
8.2 Roadmap items
| Item ID | Phase | Stream | Action | Expected change | Owner | Due |
|---|---|---|---|---|---|---|
| RM-001 (Example) | 1 | G-SM-B | Define 6 programme metrics with targets; quarterly report to CTO | L2: 0 to 1 | [@appsec-lead] | YYYY-MM-DD |
| RM-002 (Example) | 1 | G-EG-B | Launch Security Champions Program (security/security-champions-program) | L1: 0.5 to 1 | [@security-champions-lead] | YYYY-MM-DD |
| RM-003 (Example) | 1 | D-TA-B | Threat model review on each significant design change, using Threat Model (security/threat-model) | L2: 0.25 to 0.5 | [@appsec-lead] | YYYY-MM-DD |
| RM-004 (Example) | 1 | D-SR-B | Add security clauses at supplier renewal, using Supplier Security Assessment (compliance/supplier-security-assessment) | L1: 0.25 to 1; L2: 0 to 0.5 | [@procurement-lead] | YYYY-MM-DD |
| RM-005 (Example) | 2 | V-AA-A, V-AA-B | Structured architecture reviews for tier-1 services, using Security Design Review (security/security-review) | L1: 0.25 to 1; L2: 0 to 0.5 | [@security-architect] | YYYY-MM-DD |
| RM-006 (Example) | 2 | D-SR-A | Publish a security requirements catalogue mapped to tests | L2: 0.5 to 1 | [@appsec-lead] | YYYY-MM-DD |
| RM-007 (Example) | 2 | I-SB-A | Enforce pipeline gates and protect pipeline configuration, per CI/CD Pipeline Design (dev/ci-cd-pipeline-design) | L3: 0.5 to 1 | [@platform-lead] | YYYY-MM-DD |
| RM-008 (Example) | 3 | V-RT-A, V-RT-B | Automated control tests from the catalogue; abuse cases from threat models | L1 and L2 to 0.5 or higher | [@qa-lead] | YYYY-MM-DD |
| RM-009 (Example) | 3 | O-OM-A, O-OM-B | Data classification policy; decommissioning checklist | L1: to 1; L2: to 0.5 | [@data-protection-lead] | YYYY-MM-DD |
The chart uses Example dates; replace them with your plan.
9. Metrics and tracking
| Metric | Formula | Source | Example target |
|---|---|---|---|
| Overall SAMM score | Mean of 15 practice scores | This document | 1.63 at next assessment |
| Roadmap delivery | Roadmap items done by due date / items due | Roadmap tracker | 80% |
| Threat model coverage | Tier-1 services with a threat model reviewed in the last 12 months / tier-1 services | Threat model register | 100% |
| Security defects found before release | Security defects found in design, review and test / all security defects found | Defect tracker | Above 70% |
| Remediation within timeframe | Security defects fixed within agreed time / security defects closed | Defect tracker | 90% |
| Recurring defect classes | Defect categories appearing in 3 or more consecutive quarters | Defect trend report | Decreasing |
10. Governance and reassessment
- The CISO owns the SAMM programme and approves targets and the roadmap.
- The AppSec lead runs assessments, maintains this document and reports progress quarterly to the [engineering leadership forum].
- Practice owners are named per practice in the roadmap and own the actions for their streams.
- Reassess the full model every [12] months and at the end of each roadmap phase. A lightweight re-score of the streams touched by a phase is acceptable between full assessments; mark it as partial.
- Keep the method in section 3 unchanged between cycles. If you must change it, rescore the previous cycle with the new method before comparing.
- Check the SAMM site for new model releases before each cycle. If stream definitions change, record the change and its effect on comparability.
11. Mapping to other frameworks
| SAMM practice | NIST SSDF 1.1 practices (indicative) | Library template |
|---|---|---|
| G-SM Strategy and Metrics | PO.2.3, PO.4 | SSDF Practice Attestation (security/ssdf-practice-attestation) |
| G-PC Policy and Compliance | PO.1 | Secure Coding Standard (security/secure-coding-standard) |
| G-EG Education and Guidance | PO.2.1, PO.2.2 | Security Champions Program (security/security-champions-program) |
| D-TA Threat Assessment | PW.1.1 | Threat Model (security/threat-model) |
| D-SR Security Requirements | PO.1.2, PO.1.3, PW.1.2 | Supplier Security Assessment (compliance/supplier-security-assessment) |
| D-SA Secure Architecture | PW.1.3, PW.4 | Security Architecture (security/security-architecture) |
| I-SB Secure Build | PO.3, PS.1, PW.4.4, PW.6 | Software Supply Chain Security Assessment (security/supply-chain-security); SBOM and VEX Policy (security/sbom-vex-policy) |
| I-SD Secure Deployment | PO.5.1, PS.2, PS.3 | CI/CD Pipeline Design (dev/ci-cd-pipeline-design) |
| I-DM Defect Management | RV.2, RV.3 | PSIRT Vulnerability Handling (security/psirt-vulnerability-handling) |
| V-AA Architecture Assessment | PW.2.1 | Security Design Review (security/security-review) |
| V-RT Requirements-driven Testing | PW.8 | Security Design Review (security/security-review) |
| V-ST Security Testing | PW.7, PW.8, RV.1.2 | Secure Coding Standard (security/secure-coding-standard) |
| O-IM Incident Management | RV.1.1, RV.1.3 | Vulnerability Disclosure Policy (security/vulnerability-disclosure-policy) |
| O-EM Environment Management | PW.9 | Secure by Design Roadmap (security/secure-by-design-roadmap) |
| O-OM Operational Management | (no direct SSDF practice) | AI Bill of Materials (ai-data/ai-bom) for AI data assets |
The SSDF mapping above is this template's own indicative mapping at practice level. SP 800-218 also lists OWASP SAMM references for many tasks in its References column (for example "OWASPSAMM: PC1-A, PC1-B, PC2-A" for PO.1.1). Those references cite SAMM version 1.5 (2017), not SAMM v2, so the codes use the version 1.5 practice abbreviations and activity IDs. Compare with those references before reusing evidence, and translate them with the indicative crosswalk below.
| SAMM 1.5 code in SP 800-218 | SAMM 1.5 practice | Nearest SAMM v2 practice (indicative) | SSDF tasks citing it in SP 800-218 |
|---|---|---|---|
| SM | Strategy and Metrics | G-SM | PO.2.3 |
| PC | Policy and Compliance | G-PC | PO.1.1, PO.1.2, PO.3.3, PO.4.1, PO.4.2 |
| EG | Education and Guidance | G-EG | PO.2.2 |
| TA | Threat Assessment | D-TA | PW.1.1, PW.4.4 |
| SR | Security Requirements | D-SR | PO.1.2, PO.1.3, PW.4.4 |
| SA | Secure Architecture | D-SA | PO.1.2, PW.1.3, PW.4.1 |
| DR | Design Review | V-AA | PO.4.1, PW.1.1, PW.1.2, PW.2.1 |
| IR | Implementation Review | V-ST (stream B, expert review) | PO.1.2, PO.3.1, PO.4.1, PW.7.2 |
| ST | Security Testing | V-ST, V-RT | PO.3.1, PO.4.1, PW.8.2 |
| IM | Issue Management | I-DM, O-IM | RV.1.1, RV.1.3, RV.3.1, RV.3.2 |
| EH | Environment Hardening | O-EM | RV.1.1 |
| OE | Operational Enablement | O-OM, I-SD | PS.1.1, PS.2.1, PW.9.2 |
RV.3.4 cites SAMM without an activity code. When the SSDF moves to a new final version (SP 800-218r1 is a draft as of October 2026), check whether its references have been updated to SAMM v2 before relying on this table.
12. Glossary and references
12.1 Glossary
| Term | Meaning in this document |
|---|---|
| Business function | One of the five top-level areas of SAMM: Governance, Design, Implementation, Verification, Operations |
| Security practice | One of fifteen areas of activity, three per business function |
| Stream | One of two complementary lines of activity within a practice, labelled A and B |
| Maturity level | One of three levels per stream, from initial (1) to optimised (3) |
| Stream score | Sum of the answer values for levels 1 to 3 of a stream |
| Practice score | Mean of the stream A and stream B scores |
| Target | The practice score the organisation intends to reach by a date |
| Roadmap phase | A time-boxed group of improvement actions with exit criteria |
12.2 References
| Reference | Use |
|---|---|
| OWASP SAMM v2 model (owaspsamm.org/model) | Business functions, practices, streams and levels (section 2) |
| OWASP SAMM core repository, release v2.2.0, 6 July 2026 (github.com/owaspsamm/core) | Model identifiers and answer values (sections 2, 3.3) |
| OWASP SAMM getting started guidance (owaspsamm.org/docs/getting-started) | Improvement cycle steps (section 2) |
| OWASP SAMM Toolbox and assessment guidance (owaspsamm.org/assessment) | Official questionnaire and scoring tool |
| NIST SP 800-218, SSDF Version 1.1, February 2022 | Mapping and SAMM 1.5 reference crosswalk (section 11) |
SSDF Practice Attestation (security/ssdf-practice-attestation) | Task-level conformance view |
Secure by Design Roadmap (security/secure-by-design-roadmap) | Product-facing commitments that use SAMM results |
Standard and licence note
Structure aligned with the OWASP Software Assurance Maturity Model (SAMM) version 2, core release v2.2.0 (July 2026), by the OWASP Foundation and the SAMM project team, published at owaspsamm.org under the Creative Commons Attribution-ShareAlike 4.0 International licence (CC BY-SA 4.0). Business function, security practice and stream names and identifiers are taken from the SAMM model; the stream descriptions, assessment prompts, scoring narrative, worked examples and roadmap are original and do not reproduce the SAMM questionnaire. ShareAlike: if you redistribute material adapted from SAMM (for example the model table in section 2), attribute OWASP SAMM, link to the licence, indicate changes and license the adapted SAMM material under CC BY-SA 4.0. Check the current model and Toolbox at owaspsamm.org before each assessment, as stream definitions and answer sets may change. Corvid Commerce is a fictional company. Original text written for this collection. Template licence: MIT.
相关模板
Attack Tree Analysis Template
Attack tree for one attacker goal: AND/OR tree as list and Mermaid, leaf cost/skill/likelihood, path analysis, countermeasures
安全工程CIAM Solution Design Template (Passkeys, OIDC, FAPI 2.0)
Journeys and risk, proofing, passkeys and step-up, recovery, OAuth/FAPI profiles, consent and GDPR rights, B2B2C, fraud, scale, KPIs, migration
安全工程Cloud Security Posture Review Template (CSA CCM v4.1)
Periodic cloud posture review: scope, shared responsibility, CSPM findings by CCM v4.1 domain, identity, exposure, data, logging, drift, risks, actions, trend