# 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 * use this page with [DevSecOps Playbook Domains, Priority, Difficulty, and Adoption Roadmap](/devsecops-cicd-and-supply-chain/index/devsecops-playbook-domains-priority-difficulty-and-adoption-roadmap.md) * use it with [Security Quality Gates and Release Blocking](/devsecops-cicd-and-supply-chain/index-1/security-quality-gates-and-release-blocking.md) * use it with [Product Security Maturity, Scale, and Business Translation](/metrics-audit-risk-evidence-and-compliance/index/product-security-maturity-metrics-and-business-translation.md) * use it with [Maturity Roadmaps and Transformation Plans](/strategy-governance-and-leadership/index/maturity-roadmaps-and-transformation-plans.md) ## Related pages * [BSIMM and OWASP SAMM — Overview, Value, and Comparison](/metrics-audit-risk-evidence-and-compliance/index-3/bsimm-and-owasp-samm-overview-value-and-comparison.md) * [OWASP SAMM Deep Dive — Business Functions, Practices, and Roadmapping](/metrics-audit-risk-evidence-and-compliance/index-3/owasp-samm-deep-dive-business-functions-practices-and-roadmapping.md) * [Using BSIMM and SAMM Together — Assessments, Roadmaps, and Quarterly Reviews](/metrics-audit-risk-evidence-and-compliance/index-3/using-bsimm-and-samm-together-for-assessments-roadmaps-and-quarterly-reviews.md) *** *Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/metrics-audit-risk-evidence-and-compliance/index-3/devsecops-assessment-framework-daf-and-dsomm-practical-positioning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.