AI
Why a Maturity Model Beats an Ad Hoc Security Checklist
Organizations face two paths to better security: hardening build pipelines and production environments directly, or using DevOps practices to embed security into the delivery process. Neither path answers the harder question of what to do first. DSOMM provides structure, a five-dimension, five-level model that tells a team which security activities to tackle before moving up. A developer can assess their team’s maturity within their own area of influence. An enterprise security architect can use the same model to reshape the whole organization.
Three Assessment Styles, One Recommended
Pagel outlines three ways to assess a team’s security posture. Interview-based sessions with two people from the team give high-quality feedback. Interview workshops gather around ten people, provide a shortened version of DSOMM, and work best when attendees already know what static application security testing means. Questionnaires are the fallback when neither option is feasible, and quality tends to be poor: respondents fill them out based on how they feel or what they want to hide. Run assessments yearly or every two years, not more often.
SAMM for the Budget Conversation, DSOMM for the Team
SAMM and DSOMM serve different audiences. SAMM is written by security people for security people. Its structured output works well in a management conversation: here is where we are, here is the budget we need. DSOMM is written for developers and operations teams. Its heat map output shows gaps at level one before a team chases level two or three. Pagel says four customers have arrived with a completed SAMM assessment and asked what to do next. That is exactly where DSOMM takes over.
Planning Two Activities at a Time
Three-year security roadmaps don’t work. A single activity can take six months, and outcomes are hard to predict. Plan the next two activities, not a full year. Every new ongoing activity adds maintenance work: security champions meetings every two weeks, for example, consume calendar time permanently. Adding too many activities slows the whole program down. The security team should define the roadmap, not the product team. Product teams don’t know all available activities and can’t scale the explanation across many teams simultaneously.
Automating Security Metrics with Metrica
Manual questionnaires are the worst way to track whether security activities stay active over time. Metrica solves this by pulling data from existing systems. It reads Confluence to measure how frequently each application goes through threat modeling. It pulls vulnerability metrics from Defect Dojo. It queries the GitHub API to check whether branch protections are enabled in every repository. No one fills out a form. Pagel visualizes compliance as a time series: a team’s threat modeling score rises after a session and drops when the next one is overdue.
Notable Quotes
security people for security people Timo Pagel · ▶ Watch (10:29)
you can’t plan for the next three years Timo Pagel · ▶ Watch (14:15)
Key Takeaways
- DSOMM’s five-level heat map shows which level-one gaps to close before advancing.
- Interview workshops with ten trained participants outperform questionnaires for assessment quality.
- Security teams should own the roadmap; product teams lack the cross-team context to define it.
- Metrica replaces manual surveys by querying Confluence, Defect Dojo, and GitHub automatically.
- Plan only the next two security activities; each one can consume six months or more.
About the Speaker(s)
Timo Pagel has spent over twenty years in IT, starting as a system administrator and web developer before becoming involved in OWASP. He now works as an independent consultant advising organizations on DevOps security, operating as a strategist, hands-on implementer, and trainer with a focus on security program development.