PS Product SecurityKnowledge Base

🗺️ OWASP SAMM Deep Dive — Business Functions, Practices, and Roadmapping

Use this page when: you want a model that can drive a current-state assessment, a target-state definition, and a multi-quarter Product Security roadmap.

Why SAMM is so useful in Product Security management

SAMM is especially effective when a Product Security program has many moving parts and needs a practical answer to this question:

“What should we improve next, and how do we avoid maturing one area while neglecting the others?”

That is where SAMM shines.

It is broad enough to cover the full secure software lifecycle, but structured enough to let managers define staged improvement by practice.

SAMM structure at a glance

SAMM is built around five business functions, each containing three security practices.

Business function What it covers Practices
Governance Program direction, policy, enablement, and measurement Strategy & Metrics, Policy & Compliance, Education & Guidance
Design Risk-informed design and architecture choices Threat Assessment, Security Requirements, Secure Architecture
Implementation How security is built into day-to-day engineering and release work Secure Build, Secure Deployment, Defect Management
Verification How teams validate that software and design meet expectations Architecture Assessment, Requirements-Driven Testing, Security Testing
Operations How software remains secure in production Incident Management, Environment Management, Operational Management

Every practice has activities organized into streams and maturity levels. That makes SAMM easier to turn into a staged improvement program than many high-level models.

Business Function 1 — Governance

1. Strategy & Metrics

This practice covers how the program is planned, funded, and measured.

Manager use:

  • define success criteria;
  • choose outcome metrics;
  • ensure the roadmap reflects business priorities rather than scanner availability.

Typical evidence:

  • documented strategy;
  • risk-tiered product inventory;
  • review cadence and scorecards;
  • maturity targets by practice.

2. Policy & Compliance

This practice covers internal policy, obligations, and how expectations become operating rules.

Manager use:

  • turn secure-SDLC expectations into something repeatable;
  • define exception handling;
  • map program activities to compliance needs without letting compliance become the only goal.

Typical evidence:

  • secure development policy;
  • exception records;
  • required control gates for higher-risk releases;
  • policy-linked engineering standards.

3. Education & Guidance

This practice covers role-based training and usable guidance for teams.

Manager use:

  • scale the program through developer judgment instead of central review only;
  • support security champions;
  • reduce repeated review findings by teaching teams what “good” looks like.

Typical evidence:

  • role-based training plans;
  • secure coding and design guidance;
  • guided learning paths;
  • security office hours or champion forums.

Business Function 2 — Design

4. Threat Assessment

This practice is about identifying attacker paths, misuse cases, trust boundaries, and abuse opportunities.

Manager use:

  • decide where formal threat modeling is required;
  • differentiate lightweight versus deep assessment;
  • tie security work to product risk rather than ceremony.

5. Security Requirements

This practice ensures security requirements are explicit, testable, and tied to real product context.

Manager use:

  • define baseline requirements per product type;
  • avoid relying on tribal knowledge;
  • create stronger release criteria for sensitive services and data flows.

6. Secure Architecture

This practice covers the reuse of secure patterns and safer design defaults.

Manager use:

  • reduce one-off design mistakes;
  • create reusable patterns for authn, authz, tenancy, secrets, logging, and admin access;
  • increase consistency across product teams.

Business Function 3 — Implementation

7. Secure Build

This practice focuses on how software is built, assembled, and packaged safely.

Manager use:

  • improve CI hygiene;
  • define trust boundaries in pipelines;
  • establish quality gates and artifact integrity controls.

8. Secure Deployment

This practice focuses on how software is deployed into target environments safely.

Manager use:

  • define risk-tiered deployment controls;
  • control privileged changes;
  • align platform and application expectations.

9. Defect Management

This practice focuses on how security defects are triaged, prioritized, remediated, and learned from.

Manager use:

  • reduce unmanaged backlog;
  • separate exploitable issues from noise;
  • ensure findings become process improvements rather than only tickets.

Business Function 4 — Verification

10. Architecture Assessment

This practice validates design assumptions and architecture risks.

Manager use:

  • make design review evidence consistent;
  • ensure major system changes include appropriate review;
  • improve confidence in higher-risk product changes.

11. Requirements-Driven Testing

This practice ensures testing reflects the actual security requirements and risk profile.

Manager use:

  • prevent random or shallow testing;
  • tie verification effort to business impact and threat profile.

12. Security Testing

This practice covers the wider test family: static, dynamic, interactive, composition, and targeted security validation.

Manager use:

  • make tool choices more intentional;
  • avoid over-reliance on one scanner category;
  • connect testing to release decisions and real defect learning.

Business Function 5 — Operations

13. Incident Management

This practice covers readiness, detection support, containment, recovery, and learning.

Manager use:

  • define response expectations with engineering and platform teams;
  • ensure security incidents lead to stronger defaults and better architecture.

14. Environment Management

This practice covers configuration, patching, baseline management, and environmental hygiene.

Manager use:

  • reduce drift;
  • define ownership of runtime controls;
  • align platform baselines with product risk.

15. Operational Management

This practice covers secure operational processes over the lifetime of the software.

Manager use:

  • connect product security to reliability and long-lived service ownership;
  • ensure operational change does not silently erode security posture.

Why SAMM is especially strong for roadmaps

SAMM gives managers a clean way to do four things:

  1. assess current maturity by practice;
  2. set a target maturity by practice;
  3. sequence the change rather than trying to improve everything at once;
  4. show measurable progress over time.

That makes it ideal for:

  • annual planning;
  • quarterly progress reviews;
  • executive scorecards;
  • transformation roadmaps after a merger, reorg, or major platform change.

How to use SAMM in a Product Security program

Step 1 — assess honestly

Score current maturity by practice. Do not average away meaningful weakness.

Step 2 — set target states selectively

Not every product or business unit needs the same target maturity in the same timeframe.

Step 3 — build one roadmap per major capability cluster

Examples:

  • design and architecture maturity;
  • CI/CD and deployment maturity;
  • operational response maturity.

Step 4 — assign owners and evidence

A maturity target without owners and proof becomes presentationware.

Step 5 — review quarterly

Use progress reviews to decide whether the chosen maturity uplift is real, partial, or blocked by missing sponsorship.

Common SAMM mistakes

  • scoring every area with false precision;
  • forcing every practice to mature evenly;
  • treating maturity level as prestige instead of a business tool;
  • ignoring architecture and operations while over-investing in scanners;
  • forgetting that enablement and guidance are part of the model, not side work.

Official references

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.