OWASP SAMM (Software Assurance Maturity Model) es un marco abierto para medir qué tan maduro es el programa de seguridad de software de una organización, en cinco funciones de negocio y 15 prácticas de seguridad, cada una evaluada en tres niveles. Califica a la organización, no a una aplicación.
Por qué importa esa distinción: en el benchmark 2026 de Fluid Attacks, el mejor scanner del mercado detectó el 22,7% de las vulnerabilidades de las aplicaciones evaluadas, mientras que los pentesters identificaron el 89,6%. Dos empresas pueden tener el mismo scanner y estar en extremos opuestos de la escala de madurez, porque el puntaje depende de con qué consistencia se hace el trabajo, no de qué se compró.
Esta página cubre qué mide SAMM, cómo funcionan sus niveles de madurez, en qué se diferencia de ASVS y del OWASP Top 10, y qué hace falta para subir un nivel.
¿Qué es OWASP SAMM?
SAMM ordena la seguridad del software en cinco funciones de negocio —Governance, Design, Implementation, Verification y Operations— y divide cada una en tres prácticas de seguridad, para un total de 15. Cada práctica se puntúa por separado, así que el resultado no es una nota única sino un perfil: qué partes del programa son sólidas y cuáles están improvisadas.
Esa estructura es lo que hace de SAMM un modelo de madurez y no una lista de chequeo. Es abierto, neutral frente a proveedores, y prescriptivo sobre qué medir mientras se mantiene deliberadamente silencioso sobre qué herramientas comprar. Fluid Attacks mapea sus propios requisitos de seguridad a los dominios de OWASP SAMM en una base de datos pública, de modo que un equipo puede rastrear una meta de madurez hasta el requisito concreto a nivel de código que la satisface.
¿Qué es OWASP?
El Open Worldwide Application Security Project es una fundación sin ánimo de lucro que publica recursos gratuitos, construidos por la comunidad, para la seguridad del software. Sus proyectos más conocidos son el OWASP Top Ten, un ranking de los riesgos más críticos en aplicaciones web, y el OWASP ASVS, un catálogo de requisitos técnicos de verificación.
SAMM se ubica en otra altura que los dos. El Top Ten te dice qué sale mal con más frecuencia. ASVS te dice qué debe cumplir una aplicación determinada. SAMM te dice qué tan buena es tu organización para lograr cualquiera de las dos cosas, de forma consistente y en el tiempo.
¿Por qué es importante OWASP SAMM?
Porque la seguridad de las aplicaciones se ha vuelto más difícil más rápido de lo que han madurado la mayoría de los programas. En el State of Attacks 2026 de Fluid Attacks, que cubre sistemas evaluados entre el 1 de enero y el 31 de diciembre de 2025, el 70 % de los sistemas evaluados tenía al menos una vulnerabilidad de severidad alta o crítica, frente al 53,3 % en 2024.
La remediación mejoró en el mismo periodo, hasta una tasa del 62,2 %, es decir, 21,2 puntos porcentuales por encima de 2024. Que las dos cosas sean ciertas a la vez es el argumento a favor de un modelo de madurez: los equipos que miden su programa lo mejoran, y los que dependen de esfuerzos aislados quedan rezagados frente a su propia superficie de ataque.
La otra razón es que comprar herramientas no sube la madurez por sí solo. En el mismo reporte, las pruebas manuales encontraron el 87 % de las vulnerabilidades de severidad crítica mientras que las herramientas automatizadas encontraron el 13 %, y las vulnerabilidades halladas por herramientas promediaron 15,5 unidades CVSSF frente a 93,2 de las halladas por pentesters. Un programa que puntúa bien en herramientas y mal en la práctica de verificación va a seguir perdiéndose los hallazgos que más importan.
SAMM también se complementa de forma natural con guías prescriptivas. NIST SP 800-218, el Secure Software Development Framework publicado en 2022, enumera las prácticas que un equipo debería ejecutar; SAMM mide con qué consistencia el equipo las ejecuta realmente. Uno es la lista de chequeo, el otro es el tablero de puntajes.
OWASP SAMM v2: funciones de negocio y prácticas de seguridad
SAMM v2 reemplazó los tres dominios de la v1.0 por las cinco funciones de negocio de arriba, y reformuló cada una de las 15 prácticas en torno a actividades que un equipo puede evidenciar, no a intenciones que puede declarar. La versión importa cuando comparas mapeos: el material construido sobre la v1.0 sigue aplicando, pero sus etiquetas son distintas.
El marco viene con un modelo de madurez que describe cada práctica, una SAMM Toolbox para ejecutar la evaluación y un SAMM Benchmark para comparar resultados contra otras organizaciones.
Función de negocio | Qué cubre | Prácticas de seguridad |
Governance | Cómo se dirige y se mide la seguridad | Strategy & Metrics · Policy & Compliance · Education & Guidance |
Design | Cómo entra la seguridad al producto antes de que exista el código | Threat Assessment · Security Requirements · Security Architecture |
Implementation | Cómo se construye el software y cómo se gestionan los defectos | Secure Build · Secure Deployment · Defect Management |
Verification | Cómo se comprueba el resultado | Architecture Assessment · Requirements-driven Testing · Security Testing |
Operations | Cómo el sistema en producción se mantiene defendible | Incident Management · Environment Management · Operational Management |
SAMM, ASVS y el OWASP Top 10 no son alternativas
Los equipos suelen preguntar cuál de los tres adoptar. Responden preguntas distintas y la mayoría de los programas maduros usa los tres.
OWASP SAMM | OWASP ASVS | OWASP Top 10 | |
Pregunta que responde | ¿Qué tan maduro es nuestro programa de seguridad? | ¿Esta aplicación cumple sus requisitos de seguridad? | ¿Qué sale mal con más frecuencia? |
Unidad de medida | Nivel de madurez por práctica (1–3) | Requisito de verificación, cumple o no cumple | Categoría de riesgo, ordenada por ranking |
Alcance | La organización | Una aplicación | La industria |
Uso típico | Planear una hoja de ruta, justificar la inversión | Definir un contrato o un plan de pruebas | Priorizar formación y concientización |
Mapeo de Fluid Attacks |
El Top 10 también es un blanco móvil que vale la pena seguir. Su edición 2025 analizó 589 CWE, frente a unos 400 en 2021, y puso Software Supply Chain Failures en el tercer puesto: una categoría que apenas figuraba dos ediciones atrás.
Niveles de madurez de OWASP SAMM
Cada una de las 15 prácticas de seguridad se puntúa en tres niveles de madurez, y un nivel 0 implícito significa que la práctica no existe. Los niveles describen consistencia, no esfuerzo.
Nivel | Cómo se ve | Cómo lo reconoces |
1 | Ad hoc. La práctica ocurre, impulsada por individuos | Dos equipos lo hacen distinto y nadie se da cuenta |
2 | Definida y repetible. La práctica está documentada y se aplica en todos los equipos | Un equipo nuevo puede seguirla sin preguntarle a nadie |
3 | Medida y optimizada. La práctica está instrumentada y mejora con sus propios datos | Puedes mostrar la tendencia, no solo la política |
El salto del 2 al 3 es donde se estanca la mayoría de los programas, porque exige datos que la organización no ha venido recolectando. Esa es la brecha que abordan las secciones restantes de este artículo.
OWASP SAMM en Fluid Attacks
Fluid Attacks evalúa únicamente los sistemas que un cliente autoriza de forma explícita, dentro de un alcance acordado, y reporta cada hallazgo al equipo del propio cliente a través de su plataforma. Nada de lo descrito aquí se ejecuta sobre sistemas de terceros.
SAMM es un marco al que Fluid Attacks se mapea, no un producto que vende. El valor práctico está en la instrumentación: los controles que SAMM te pide demostrar son aquellos para los que un programa de pruebas de seguridad produce evidencia.
El mapeo publicado cubre los dominios de la v1.0
El mapeo público de SAMM de Fluid Attacks está construido sobre SAMM v1.0 y organiza 23 requisitos de seguridad en tres dominios: Security Architecture (6), Security Testing (9) y Operational Management (8). En la v2 esos dominios se reagruparon —Security Architecture dentro de Design, Security Testing dentro de Verification, Operational Management dentro de Operations—, así que los requisitos siguen aplicando; lo que cambió fueron las etiquetas. Cada entrada abre una página completa de requisito, como la de verificar componentes de terceros.
Cómo se ve cada función de negocio en la práctica
Función de negocio | Cómo la instrumenta Fluid Attacks | Evidencia |
Governance | Métricas de exposición al riesgo en la plataforma; una base de requisitos pública; su propia casa certificada | 23 requisitos mapeados a dominios SAMM; ISO/IEC 27001 y 27701, SOC 2 y SOC 3, validación PCI DSS |
Design | Requisitos de seguridad con criterios de aceptación por entrada | Una página pública por requisito, cada una con su justificación y sus referencias |
Implementation | SAST, SCA y CSPM en el pipeline, más un CI Gate que rompe el build. Para el triaje: severidad VLAI, EPSS, Signals de explotación e indicador de Reachability Capability | Los sistemas que usan el CI Gate alcanzaron una tasa de remediación del 72,2 % frente al 58 % sin él |
Verification | DAST y MAST junto con pruebas de penetración manuales y revisión segura de código | Las pruebas manuales encontraron el 87 % de las vulnerabilidades de severidad crítica; las herramientas, el 13 % |
Operations | Reataques verificados y gestión de vulnerabilidades en un solo lugar | Tasa de remediación global del 62,2 % al cierre de 2025; 63,8 % en severidad crítica |
En la fila de Implementation, las señales de triaje están documentadas en el changelog de la plataforma y la base de datos: cada vulnerabilidad de la base de datos muestra ahora una calificación de severidad VLAI que complementa CVSS y EPSS, la actividad de explotación en el mundo real se etiqueta como Signals, y la página de detalle de la vulnerabilidad incluye una sección de Reachability Capability con tres estados: soportado, no soportado e imposible.
El modelo original fue escrito por Pravir Chandra in 2009. Fuente de la imagen: OWASP SAMM.
Verificación puntual frente a verificación continua
La práctica de Security Testing es donde más pesan los niveles de madurez, porque la diferencia entre el nivel 1 y el nivel 3 no es qué herramienta ejecutas, sino con qué frecuencia la ejecutas y cuánto del resultado es humano.
Medida | Puntual, impulsada por herramientas | Continua, herramientas más humanos |
Proporción de vulnerabilidades de severidad crítica encontradas | 13 % (herramientas automatizadas) | 87 % (pruebas manuales) |
CVSSF promedio por hallazgo | 15,5 | 93,2 |
Tasa de detección en un benchmark de 36 herramientas | 22,7 % (el mejor scanner) | 89,6 % (pentesters) |
Tasa de remediación | 58 % sin CI Gate | 72,2 % con CI Gate |
Mediana de tiempo de remediación | 32 días | 21 días |
Las cifras de detección vienen del State of Attacks 2026; la fila del benchmark viene de un benchmark de 36 herramientas de terceros publicado en febrero de 2026, en el que el mejor scanner detectó el 22,7 % de las vulnerabilidades mientras que los pentesters identificaron el 89,6 %.
Un puntaje perfecto en un banco de pruebas no es un nivel de madurez
Hay una contradicción útil en esas cifras. En 2021, el scanner de Fluid Attacks alcanzó un puntaje máximo de precisión de 100 en el OWASP Benchmark, con 100 % de verdaderos positivos y cero falsos positivos. Cinco años después, en un benchmark ejecutado contra 1.076 vulnerabilidades reales, el mejor scanner del mercado —cualquier scanner— encontró el 22,7 % de ellas.
Los dos resultados son correctos. El OWASP Benchmark es un banco de pruebas sintético en Java con respuestas conocidas, y sacar 100 en él demuestra que un scanner hace con precisión lo que los scanners hacen.
▶️ Video: el resultado del OWASP Benchmark, explicado por el equipo que lo ejecutó.
Las aplicaciones reales contienen fallas de lógica de negocio, autorización rota y condiciones encadenadas que ningún banco de pruebas codifica y que ningún scanner está construido para razonar. Por eso exactamente SAMM puntúa la práctica de Verification según cómo prueba la organización, no según qué herramientas tiene: un equipo puede comprar el scanner más preciso del mundo y seguir en el nivel 1.
La plataforma compara la tasa de remediación de una organización con la de los mejores, los promedio y los peores de la cohorte: el equivalente operativo del SAMM Benchmark, aplicado a hallazgos en lugar de a respuestas de autoevaluación.
Governance es la práctica que decide todas las demás
Strategy & Metrics aparece primera en SAMM por una razón. La guía de Fluid Attacks sobre cómo implementar DevSecOps convierte la gobernanza en la precondición y no en el papeleo: una empresa tiene que monitorear sus procedimientos, medir su desempeño, nombrar sus obstáculos y fallas, y mejorar a partir del feedback.
Las métricas que un equipo acumula a medida que madura su práctica de DevSecOps son las que vuelven defendibles las decisiones de gobernanza, en lugar de intuitivas. Es el mismo argumento que hace SAMM cuando pone Strategy & Metrics por delante de toda práctica técnica.
Cómo alcanzar un nivel de madurez alto
Ejecuta una evaluación, elige las dos o tres prácticas con la brecha más amplia e instruméntalas para que la siguiente evaluación sea medida y no estimada. La propia Toolbox de SAMM te da el cuestionario; el trabajo es todo lo que viene después.
Tres pasos cargan con la mayor parte del peso.
Evalúa con honestidad. Una autoevaluación que puntúa todas las prácticas en nivel 2 es un ejercicio de puntaje, no un diagnóstico. Donde no tienes datos, la respuesta es nivel 1.
Cierra primero la brecha de Verification. Es la práctica con el efecto más directo sobre las demás y la más fácil de instrumentar, mediante pruebas de seguridad que combinen escaneo de vulnerabilidades con pruebas de penetración como servicio. El análisis de Fluid Attacks sobre las pruebas de penetración continuas deja clara la limitación: una evaluación puntual te da una línea base que vale la pena comparar con la siguiente, pero no dice nada sobre si el sistema resistió los ataques dirigidos contra él en el intervalo. Un nivel de madurez que depende de una foto anual es un nivel de madurez que no puedes evidenciar once meses al año.
Haz que el nivel 3 sea medible. El nivel 3 significa mejorar la práctica con sus propios datos, lo que exige una línea de tendencia lo bastante larga para leerse. Las obligaciones de cumplimiento suelen ser lo que financia este paso, y se apoyan en la misma evidencia: mira el cumplimiento que exige pruebas de penetración para entender contra qué estándares puede producir evidencia un programa de pruebas.
Conclusiones
OWASP SAMM es útil porque separa dos preguntas que las organizaciones tienden a mezclar: si una aplicación es segura, y si la organización es buena haciendo aplicaciones seguras. La segunda es la que determina la primera, el trimestre que viene y el siguiente.
El marco no te va a decir qué scanner comprar, y eso es una virtud. Lo que sí hace es exponer para cuáles de las 15 prácticas no puedes producir evidencia, que casi siempre es el punto de partida honesto. En 2025 la proporción de sistemas que cargaba al menos una vulnerabilidad alta o crítica subió al 70 %, así que la brecha entre una práctica documentada y una práctica medida no es una distinción académica.
Preguntas frecuentes
¿Qué diferencia hay entre OWASP SAMM y OWASP ASVS?
SAMM mide qué tan maduras son las prácticas de seguridad de una organización; ASVS enumera los requisitos técnicos de verificación que debe cumplir una aplicación específica. SAMM puntúa el programa, ASVS prueba el producto. Un equipo puede puntuar nivel 3 en Verification precisamente porque ejecuta de forma consistente pruebas guiadas por ASVS.
¿OWASP SAMM es lo mismo que BSIMM?
No. Los dos miden la madurez de la seguridad del software, pero SAMM es prescriptivo y abierto: define las prácticas que una organización debería ejecutar y las puntúa. BSIMM es descriptivo y comercial: reporta lo que hace un conjunto de empresas observadas, y tú te comparas contra esa muestra. SAMM te dice cómo se ve lo bueno; BSIMM te dice cómo se ve lo común.
¿Cuántos niveles de madurez tiene OWASP SAMM?
Tres por cada práctica de seguridad, más un nivel 0 implícito cuando la práctica no existe. El nivel 1 es ad hoc, el nivel 2 es definido y repetible, el nivel 3 es medido y optimizado. Como las 15 prácticas se puntúan por separado, una organización termina con un perfil de madurez y no con un solo número.
¿Cuánto tiempo toma subir de nivel de madurez en SAMM?
Depende de tu punto de partida y de si tu pipeline ya impone controles de seguridad. El State of Attacks 2026 de Fluid Attacks encontró que los sistemas que usan un CI Gate alcanzaron una tasa de remediación del 72,2 % frente al 58 % sin él, y redujeron la mediana de tiempo de remediación de 32 a 21 días: el tipo de mejora instrumentada de la que un puntaje de nivel 3 exige evidencia.
¿OWASP SAMM aplica solo a grandes empresas?
No. Aplica a cualquier organización que desarrolle su propio software. El esfuerzo de evaluación escala con el tamaño del equipo, y los equipos pequeños suelen moverse más rápido entre niveles porque hay menos procesos que cambiar. Lo que no escala hacia abajo es la necesidad de evidencia.
¿Fluid Attacks usa OWASP SAMM?
Sí. Fluid Attacks mapea sus requisitos de seguridad a los dominios de SAMM en una base de datos pública. El mapeo cubre 23 requisitos y cada uno abre una página completa de requisito, de modo que una meta de madurez puede rastrearse hasta el control concreto que la satisface.
Convierte el puntaje en evidencia
Las pruebas continuas le dan a tu práctica de Verification los datos con los que un nivel 3 tiene que respaldarse. Prueba gratuita · Contáctanos.
