OWASP SAMM Scoped for Agile Teams

Table of Contents

Note: This article is a translation of the original version written in Spanish.

In many of my client engagements, collaboration is often limited to specific areas. This poses a challenge: how can we improve security without intervening in the entire software development lifecycle?

That’s when I came across an interesting project that needed improvement in security aspects within the development teams. In such cases, it’s best to follow security maturity standards and leverage assessment tools like OWASP SAMM. But as I started the project, I faced a roadblock: I needed a narrow focus limited to the development team — not the entire software development lifecycle or the broader DevSecOps domain.

So, for those unfamiliar or in a similar situation, here’s my experience and some recommendations regarding the OWASP SAMM Agile Guidance.

Context #

After reviewing different maturity models for DevSecOps that I typically rely on — like OWASP SAMM or DSOMM — I faced the dilemma that many areas of the full model were irrelevant in this specific context. That’s when I discovered a solution I hadn’t known about: OWASP SAMM Agile Guidance.

As its name suggests, OWASP SAMM Agile Guidance derives directly from OWASP SAMM and shares parts of its structure and documentation, which can be found in the same place.

To compare, I created the following chart based on OWASP SAMM v2 showing the Business Functions, associated Security Practices, and two Streams (A and B) per practice, each with three improvement objectives.

In the chart, practices and streams not considered in Agile Guidance are shown in grey.

OWASP SAMM Practices vs Agile Guidance — OWASP SAMM vs Agile Guidance

In short, OWASP SAMM Agile Guidance suggests that out of 5 business functions, only 3 remain:

Governance
Design
Verification

Only 6 of the original 15 practices are retained, and within those, just 8 streams are considered.

Security Practices in OWASP SAMM Agile Guidance — Image from https://owaspsamm.org/guidance/agile/

My Thoughts #

As I’ve said before, I’m not a fan of reinventing the wheel — so I was glad to find this option to build upon what already exists. That said, Agile Guidance differs from its “parent” (OWASP SAMM) in key ways, which I’ll summarize below.

Despite the drawbacks, I think it’s fantastic that this alternative exists.

Topics to discuss:

Scoped to Teams
Implementation Function Is Missing
Lack of Assessment Tools
Recommendations and pitfalls outside the model
OWASP SAMM levels oriented towards DevSecOps
Supporting security best practices

Scoped to Teams #

This is the reason I came to this model. OWASP SAMM is broad in terms of Application Security, which is generally the right approach. However, Agile Guidance is narrowly scoped to agile development teams, offering another maturity lens focused specifically on their context. This is important: for example, in the project I mentioned earlier, the challenge was to improve security posture without impacting delivery speed. OWASP SAMM Agile Guidance helped us identify key practices within the team’s scope — such as security awareness and requirement definition — without unnecessary changes outside the team’s domain, like operations.

Is it right NOT to evolve operations? Not really. Evolving operations is important too. However, in our specific goal, it didn’t make sense to focus on operational improvements that were already being handled by a dedicated team.

Implementation Function Is Missing #

Just as the Operations function is missing, so is Implementation. This was jarring at first when I realized it was gone. 😭

Implementation Streams — Business Function: Implementation

But after further reflection, I realized my expectation came from a delivery-focused mindset — concerned with tools, automation, and CI/CD flows in DevOps or DevSecOps environments.

OWASP SAMM Agile Guidance, on the other hand, doesn’t focus on the full technical lifecycle. It focuses on the agile team as a functional unit and how it can adopt security practices aligned with its way of working. From that angle, the removal of Implementation makes sense: its practices (like static analysis, automated tests, CI/CD tool integration, etc.) can be redistributed under Build, Verification, or Design, depending on how the team addresses them.

Put differently, this omission highlights a difference in focus: the traditional SAMM looks at the full software process; Agile Guidance focuses on what the agile team can control day-to-day.

Lack of Assessment Tools #

This was the most interesting part for me from the beginning: having a tool to assess the team’s current state and build a realistic, actionable roadmap.

In traditional SAMM, we have tools like the official spreadsheet or Docker-based web version for guided self-assessments, offering visual summaries of maturity per stream. These tools are vital for team discussions and prioritization.

However, Agile Guidance offers no predefined or official tools for this context. This surprised me, given SAMM’s core purpose is iterative improvement — very much in line with agile thinking.

So I created a scoped-down version of the original spreadsheet tool, specifically tailored to measure the practices suggested in Agile Guidance.

Its main goal is to enable quick assessments by keeping only the practices that match the agile guide. This means scoring is adjusted to consider only the 8 remaining streams.

While making changes, I also updated the Phase 1 comparison to summarize current vs. proposed values for that phase.

This change felt valuable as I often use this summary format to present improvement goals.

Here’s the same section in its original version for reference:

Recommendations and pitfalls outside the model #

Beyond reconfiguring OWASP SAMM’s security practices from an agile lens, the guide includes something I find essential: a set of recommendations and common pitfalls not strictly part of the model but crucial for effective implementation in agile teams.

These go beyond formal practices. They offer extra context, practical advice, and common-sense reminders that often determine whether security becomes truly embedded in the team’s routine.

**Software development process and the flow of requirements** from the Agile Guide

What makes these recommendations valuable is their realism. They highlight day-to-day situations that arise when trying to improve security.

In my view, these tips and pitfalls bring SAMM’s agile approach to life. They bridge the gap between a structured model and a dynamic environment. Often, security adoption in an agile team hinges less on what you implement and more on how you communicate and adapt it to the team’s reality. This section helps do just that.

OWASP SAMM levels oriented towards DevSecOps #

Developing the Agile Guidance assessment tool helped me identify which streams from the original OWASP SAMM model remain relevant and which need adapting. For example, a centralized security portal is critical from a global perspective. But at a team level, what matters is whether the team knows about it, uses it, and leverages it day-to-day.

Also, it’s key to recognize that the Agile Guide’s recommendations and pitfalls aren’t part of the original OWASP SAMM. These additions make the traditional model truly useful in agile settings.

In short, assessments based on original SAMM levels should be complemented with the Agile Guide’s approach, incorporating the team’s context and working style. That’s how we can rethink SAMM for agile in DevSecOps-driven environments.

Supporting security best practices #

Though it may seem minor, having a reference model is essential to back and prioritize security practices objectively. This ensures that the roadmap isn’t just based on a consultant’s opinion but follows a structured approach validated by the community.

By relying on the model, we start from a point of consensus: it’s not just about “what seems right,” but about progressing with a framework built from collective experience. This adds legitimacy, avoids improvisation, and supports progressive, measurable improvements aligned with the team’s context.

Moreover, using a recognized model helps communicate and justify decisions across areas like management, product, or audit — strengthening organizational commitment to security.

Conclusion #

Unlike the full OWASP SAMM model, the Agile Guide skips some organizational practices and large-scale processes like Governance and global Metrics. Instead, it focuses on tactical practices that teams can adopt directly — like threat modeling, specifying security requirements, and engaging with security topics. This narrower focus allows for quick wins, identifying critical points, and prioritizing improvements without a full organizational transformation.

Therefore, this maturity model is well worth using when focusing solely on agile development teams. It highlights issues close to the teams, though some metrics (in my view) still feel more organizational than team-centered due to their SAMM-based origin.

Still, it’s key to understand that this guide doesn’t replace a comprehensive security strategy. Instead, it’s a valuable starting point for maturing security locally — at the team level — toward a more holistic DevSecOps vision from within the team itself.

Additional Notes #

I’m exploring how to apply this same logic of “scoped maturity” in other areas — for example, how CI/CD pipelines are designed and implemented securely. I’m not talking about security validations for components flowing through the pipeline, but about making the pipeline development itself security-aware. I’ve found some metrics already published, but I need to gather more before finalizing my framework.

I’m also considering sharing the adapted assessment version I created for the agile guide. Would you be interested in trying it out?

Finally, I’d love to hear how others are using OWASP SAMM or the agile guide in their teams. Do you have a quick way to measure your team’s maturity in security practices? Do you think it’s appropriate to assess a team individually?