Improve software assurance as a measured program with OWASP SAMM

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 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.

1. Define assessment scope, model version, evidence rules, assessor roles, sampling, and date. Preserve the criteria so later assessments are comparable.
2. Collect evidence from policy, workflow, repositories, pipelines, defects, releases, incidents, interviews, and observed practice. Record uneven adoption rather than averaging it away.
3. Link findings to software and business risk. Choose a small number of improvements that remove a bottleneck or strengthen a weak lifecycle connection.
4. Give each improvement an owner, resources, milestones, leading indicator, outcome indicator, and evidence artifact. Include operational and supplier dependencies.
5. Pilot the practice with representative teams. Capture friction, exceptions, escaped defects, delivery effects, and operator feedback before scaling.
6. 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 — OWASP Foundation; official living model page
• OWASP SAMM assessment guidance — OWASP Foundation; official project guidance