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.
\nThe official OWASP SAMM 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.
\nThe 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.
\nSAMM 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.
\nThe 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.
\nThe following steps are DSE recommendations based on the cited source.
\nRetain 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.
\n