PS Product SecurityKnowledge Base

🧭 DevSecOps Assessment Framework (DAF) and DSOMM — Practical Positioning

Bottom line: use DAF when you want a spreadsheet-first, assessment-and-roadmap artifact that practitioners can review together and turn into action; use DSOMM when you want a richer open maturity model with reusable dimensions, activities, and mappings. Neither replaces BSIMM or SAMM, but both are useful overlays for DevSecOps-specific maturity work.

Why this page exists

BSIMM and SAMM are strong models, but many teams want something closer to the day-to-day DevSecOps reality of:

  • CI/CD controls;
  • secrets handling;
  • signing and verification;
  • container and image checks;
  • evidence collection;
  • maturity scoring that can be used in workshops.

That is where DAF and DSOMM become useful.

What DAF appears to be good at

Publicly visible materials for Jet Security Team’s DevSecOps Assessment Framework (DAF) show it as an assessment-oriented framework distributed as a workbook-style artifact with heatmap and maturity-pyramid elements. Public updates in 2025 emphasized refreshed mappings, an English version for the international community, and support materials for secure-development process documentation.

This makes DAF especially useful when you need:

  • an assessment workshop artifact teams can discuss line by line;
  • a roadmap-oriented maturity conversation rather than only narrative guidance;
  • a bridge between engineering reality and formal mapping requirements.

What DSOMM is good at

The OWASP DevSecOps Maturity Model (DSOMM) is a more established open model. Public descriptions emphasize dimensions and activities for incremental DevSecOps improvement, mappings to other standards, and a GitOps-like approach to tracking implementation progress.

This makes DSOMM especially useful when you need:

  • an open reference model with reusable structure;
  • a public maturity language other teams may already know;
  • mapping support and iterative maturity tracking.

Practical positioning

Need Better starting point
Workshop-based assessment with a concrete planning artifact DAF
Open maturity model with public activity structure and mappings DSOMM
Broad software-security benchmarking BSIMM
Target-state secure-SDLC roadmap SAMM

A realistic combined pattern

A pragmatic pattern for Product Security or platform teams is:

  1. use SAMM to describe the target secure-SDLC state;
  2. use BSIMM to benchmark against what mature software-security initiatives do;
  3. use DAF or DSOMM to run a DevSecOps-focused workshop over pipelines, build systems, artifact trust, and operational controls;
  4. translate the result into a quarter-by-quarter improvement plan with owners and evidence.

Where this helps most

Platform engineering

A platform team can use DAF/DSOMM to evaluate whether the internal platform actually embeds:

  • secure defaults;
  • policy enforcement;
  • artifact trust controls;
  • secrets handling;
  • evidence generation.

CI/CD and release security

These models are especially useful when the question is not “do we own a scanner?” but rather:

  • where in the pipeline do controls exist;
  • how consistently are they enforced;
  • what is advisory versus blocking;
  • what evidence survives release review.

Security transformation

If your current state is still tool-by-tool and team-by-team, DAF/DSOMM can help create a more explicit maturity conversation around stages, responsibilities, and repeatability.

What not to do

  • do not treat DAF or DSOMM as a compliance certificate;
  • do not let a maturity score replace actual threat-model and incident data;
  • do not level up every activity uniformly; sequence the ones that reduce your most likely delivery and product risk first.

Suggested use with the rest of this KB

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