# Improve software assurance as a measured program with OWASP SAMM > OWASP SAMM organizes software assurance across governance, design, implementation, verification, and operations. Assess current practice, choose a justified target, and improve with observable evidence. - Canonical URL: https://update.dsesecurity.com/updates/owasp-samm-measured-software-assurance-program/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:47+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know OWASP SAMM organizes software assurance across governance, design, implementation, verification, and operations. Assess current practice, choose a justified target, and improve with observable evidence. ## Potentially affected Organizations that need to assess and improve software security practices across teams, products, acquired services, and the full development and operating lifecycle. ## DSE recommendation Use a consistent SAMM assessment scope and evidence standard, prioritize a small set of risk-linked improvements, assign owners and measures, and reassess outcomes instead of optimizing a maturity score alone. ## Article Bottom line: sustainable software assurance is a management system, not a collection of disconnected tools. Measure current practices across the lifecycle, choose improvements that address actual risk and delivery constraints, and verify that the new practices change observable work. ## Source fact: what OWASP SAMM organizes The official [OWASP SAMM model](https://owaspsamm.org/model/) defines five business functions and fifteen security practices for assessing and improving software security posture. The functions are Governance, Design, Implementation, Verification, and Operations. The practices cover areas such as strategy and metrics, policy, education, threat assessment, security requirements and architecture, secure build and deployment, defect management, assessment and testing, incident management, and environment and operational management. The model page identifies version 2.0 and describes SAMM as an OWASP community project. Its structured breadth supports reviewing how practices connect across a software lifecycle. ## What the source does not establish SAMM does not certify a product or guarantee secure software. A maturity score is not a direct measure of vulnerability count, exploitation likelihood, business loss, or customer assurance. Comparing scores is unreliable if organizations use different scope, evidence, interpretation, or assessor independence. The model also does not require every team to pursue the same target at the same time. Product criticality, delivery model, staffing, supplier role, technology, regulation, and threat exposure influence priority. ## Applicability questions - Which organization, portfolio, product, team, or lifecycle is in scope? - What evidence is required to distinguish an established practice from an aspiration or isolated example? - Which software risks and business objectives justify the target state? - Which upstream and downstream practices must change together for an improvement to work? - Who owns the improvement, how will progress be observed, and when will it be reassessed? ## DSE recommendation: improve the operating system, not the score The following steps are DSE recommendations based on the cited source. - Define assessment scope, model version, evidence rules, assessor roles, sampling, and date. Preserve the criteria so later assessments are comparable. - Collect evidence from policy, workflow, repositories, pipelines, defects, releases, incidents, interviews, and observed practice. Record uneven adoption rather than averaging it away. - Link findings to software and business risk. Choose a small number of improvements that remove a bottleneck or strengthen a weak lifecycle connection. - Give each improvement an owner, resources, milestones, leading indicator, outcome indicator, and evidence artifact. Include operational and supplier dependencies. - Pilot the practice with representative teams. Capture friction, exceptions, escaped defects, delivery effects, and operator feedback before scaling. - Reassess with the same scope and evidence standard. Report both improvement and regression without presenting maturity as a guarantee. ## Verification and evidence Retain the assessment basis, evidence samples, scoring rationale, gaps, risk linkage, improvement plan, ownership, pilot results, measures, exceptions, and reassessment. Confirm that a claimed improvement can be observed in recent work products and not only in a new policy document. ## Official references - [OWASP SAMM model](https://owaspsamm.org/model/) — OWASP Foundation; official living model page - [OWASP SAMM assessment guidance](https://owaspsamm.org/assessment/) — OWASP Foundation; official project guidance ## Primary reference - Name: OWASP Software Assurance Maturity Model - Authority: owaspsamm.org - URL: https://owaspsamm.org/model/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Improve software assurance as a measured program with OWASP SAMM,” DSE Security, https://update.dsesecurity.com/updates/owasp-samm-measured-software-assurance-program/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.