Escribir código seguro es una cultura
En muchas organizaciones, la seguridad del software sigue siendo una comprobación de última hora. Se ejecuta un pentest antes de producción, se añade algún análisis automático al pipeline de CI/CD y, con suerte, se revisa manualmente el código. Este enfoque suele traducirse en vulnerabilidades descubiertas cuando ya son costosas de corregir, retrasos en los proyectos y equipos de desarrollo que ven la seguridad como un obstáculo más que como una capacidad integrada en su trabajo diario.
El problema no suele ser falta de voluntad, sino falta de estructura. Entonces, ¿Cómo defines qué significa “desarrollo seguro” para tu organización? ¿Cómo mides si estás mejorando? ¿Por dónde empiezas sin paralizar la entrega de software?
OWASP, la referencia mundial en seguridad de aplicaciones, ofrece dos herramientas complementarias que responden a estas preguntas: el modelo de madurez OWASP SAMM (Software Assurance Maturity Model) para medir y planificar tu programa de seguridad, y la OWASP Secure Coding Practices Quick Reference Guide como checklist operativo para los equipos de desarrollo. En este artículo explicamos cómo usarlas juntas para construir una cultura de código seguro de forma progresiva y sostenible.
OWASP SAMM como guía para planificar la mejora de la seguridad
Antes de implementar prácticas de código seguro, necesitas saber dónde estás. OWASP SAMM es un marco abierto, evolutivo y orientado al riesgo que permite a cualquier organización, independientemente de su tamaño, tecnología o metodología de desarrollo, evaluar su postura de seguridad en el ciclo de vida del software y trazar una hoja de ruta de mejora realista.
Lo que diferencia a SAMM de otros marcos es su enfoque prescriptivo pero adaptable. No dice “haz seguridad” en abstracto: define actividades concretas, organizadas en tres niveles de madurez, que te permiten avanzar de forma incremental. No existe una receta única que funcione para todas las organizaciones, y SAMM está diseñado para ser adaptado a los riesgos específicos de cada una.
Las 5 funciones de negocio y sus 15 prácticas de seguridad
SAMM v2 se estructura en torno a 5 funciones de negocio, cada una con 3 prácticas de seguridad que cubren el ciclo de vida completo del software:
- Governance (Gobernanza). Se ocupa de la estrategia, las políticas y la formación. Incluye Strategy and Metrics (definir objetivos y medir el progreso del programa), Policy and Compliance (asegurar el cumplimiento normativo) y Education and Guidance (capacitar a los equipos). Si solo puedes empezar por un sitio, la formación y la estrategia son el cimiento de todo lo demás. Como señalan los contribuidores del proyecto SAMM, la educación y la cultura organizacional son las “reglas número 1 a 10” de cualquier programa de seguridad.
- Design (Diseño). La seguridad debe comenzar antes de escribir la primera línea de código. Incluye Threat Assessment (modelado de amenazas para identificar vectores de ataque), Security Requirements (requisitos de seguridad funcionales y no funcionales) y Secure Architecture (patrones arquitectónicos seguros). Por ejemplo, usar el framework STRIDE durante el modelado de amenazas permite evaluar sistemáticamente cómo el spoofing, la manipulación de datos o la revelación de información podrían afectar a la aplicación.
- Implementation (Implementación). El código y su despliegue. Incluye Secure Build (construcción segura, gestión de dependencias, análisis de composición de software), Secure Deployment (despliegue seguro, gestión de secretos, configuración de infraestructura) y Defect Management (gestión de defectos de seguridad con criterios de priorización y SLAs de remediación). Aquí es donde la Secure Coding Practices de OWASP cobra protagonismo como guía operativa.
- Verification (Verificación). Pruebas y validación. Incluye Architecture Assessment (revisión de la arquitectura contra requisitos de seguridad), Requirements-driven Testing (pruebas basadas en los requisitos definidos en la fase de diseño) y Security Testing (SAST, DAST, IAST, pentesting). La clave es que las pruebas sean sistemáticas, no puntuales.
- Operations (Operaciones). Lo que pasa después de producir el código. Incluye Incident Management (respuesta a incidentes de seguridad), Environment Management (hardening de entornos, gestión de parches) y Operational Management (monitorización continua, gestión de la cadena de suministro de software).
Puedes encontrar esta 5 funciones en el siguiente infográfico:
Los 3 niveles de madurez para avanzar sin agobiarte
Cada práctica se mide en una escala de 1 a 3. El nivel 1 representa las actividades iniciales y ad hoc, el nivel 2 las prácticas estructuradas y repetibles, y el nivel 3 la optimización continua alineada con los objetivos de negocio. La belleza del modelo es que no necesitas estar en nivel 3 en todo: debes priorizar en función del riesgo. Una startup con una API crítica puede necesitar un nivel 3 en Security Testing pero un nivel 1 en Policy and Compliance.
La hoja de ruta típica de implementación de SAMM sigue cinco pasos:
- Preparación (entender el contexto y los riesgos)
- Evaluación (medir el estado actual con el SAMM Toolbox)
- Definición de objetivos (establecer el nivel de madurez deseado por práctica)
- Planificación (diseñar iteraciones de mejora)
- Ejecución (implementar y medir).
El modelo está pensado para ciclos iterativos, no para una transformación big-bang.
OWASP Secure Coding Practices es el checklist que tus desarrolladores necesitan
Si SAMM es el mapa estratégico, la OWASP Secure Coding Practices Quick Reference Guide (SCP) es la brújula táctica para el día a día del equipo de desarrollo. Se trata de un checklist agnóstico de tecnología, con solo 17 páginas, que cubre 14 áreas críticas de prácticas de codificación segura. Su contenido ha sido migrado al OWASP Developer Guide para una mayor difusión, pero la estructura del checklist sigue siendo la referencia más directa y operativa.
Las 14 áreas del checklist de OWASP
- Validación de entrada (Input Validation): Toda validación debe ejecutarse en el lado del servidor, nunca solo en el cliente. Clasificar las fuentes de datos en confiables y no confiables. Usar listas de permitidos en lugar de listas de denegados. Validar tipo, longitud y rango de todos los datos de entrada.
- Codificación de salida (Output Encoding): Codificar contextualmente todos los datos devueltos al cliente desde fuentes no confiables. Sanitizar las salidas hacia SQL, XML, LDAP y comandos del sistema operativo.
- Autenticación y gestión de contraseñas: Centralizar la lógica de autenticación. Usar hashes criptográficos con salt para el almacenamiento de contraseñas. Implementar MFA para operaciones de alto valor. Los mensajes de error de autenticación nunca deben revelar qué parte de los datos fue incorrecta.
- Gestión de sesiones: Generar identificadores de sesión en el lado del servidor con algoritmos criptográficamente fuertes. Regenerar el identificador tras cada autenticación. Establecer timeouts de inactividad y no exponer identificadores en URLs ni logs.
- Control de acceso: Aplicar autorización en cada petición, no solo en la carga inicial de la página. Usar un componente centralizado para la verificación de permisos. Los controles de acceso deben fallar de forma segura (denegar por defecto).
- Prácticas criptográficas: Todas las funciones criptográficas deben ejecutarse en el servidor. Usar módulos conformes a FIPS 140-2 o equivalente. Establecer políticas de gestión del ciclo de vida de las claves.
- Manejo de errores y logging: No exponer información sensible en mensajes de error (trazas de pila, identificadores de sesión, detalles del sistema). Registrar todos los fallos de validación, intentos de autenticación y violaciones de control de acceso. Nunca almacenar datos sensibles en los logs.
- Protección de datos: Principio de mínimo privilegio. Cifrar toda información sensible almacenada, incluso en el servidor. Eliminar comentarios del código en producción que puedan revelar información sobre el backend.
- Seguridad en comunicaciones: TLS para toda transmisión de información sensible. Las conexiones fallidas no deben degradarse a conexiones no cifradas. Certificados válidos, con el dominio correcto y cadenas intermedias instaladas.
- Configuración del sistema: Servidores, frameworks y componentes en su última versión aprobada con todos los parches aplicados. Eliminar funcionalidad innecesaria, código de prueba y documentación del sistema antes de producir. Deshabilitar métodos HTTP innecesarios.
- Seguridad de base de datos: Consultas parametrizadas con tipado fuerte. Privilegio mínimo en las credenciales de conexión. Cadenas de conexión cifradas y almacenadas fuera del código fuente.
- Gestión de archivos: Validar los archivos subidos por cabecera, no por extensión. Deshabilitar privilegios de ejecución en directorios de subida. Nunca pasar datos del usuario directamente a funciones de inclusión dinámica.
- Gestión de memoria: Liberar correctamente la memoria cuando se producen errores. Validar límites de buffers en lenguajes que lo requieran.
- Prácticas generales de codificación: Usar código gestionado y probado cuando sea posible. Revisar bibliotecas de terceros antes de integrarlas. Implementar sistemas de control de cambios para gestionar modificaciones al código tanto en desarrollo como en producción.
Puedes encontrar esta checklist en el siguiente infográfico:
Métricas de desarrollo seguro para medir y cómo hacerlo según SAMM
Uno de los principios fundacionales de SAMM es que “medir es conocer”. Sin métricas, cualquier programa de seguridad opera a ciegas. SAMM dedica un stream completo a Measure and Improve dentro de la práctica Strategy and Metrics, con tres niveles de madurez que ofrecen una hoja de ruta clara para evolucionar tu sistema de medición.
Nivel 1: Métricas básicas de visibilidad
El objetivo es obtener visibilidad sobre lo que está ocurriendo. Definir métricas que ofrezcan una visión de la eficacia y eficiencia del programa de seguridad de aplicaciones. Ejemplos: número de vulnerabilidades críticas abiertas, porcentaje de proyectos con análisis de seguridad completado, tiempo medio de remediación de hallazgos, número de desarrolladores formados en seguridad.
Nivel 2: KPIs y objetivos cuantitativos
Establecer objetivos concretos y KPIs para medir la eficacia del programa. Ejemplos: “en 6 meses, el 100% de los proyectos críticos deberán pasar un análisis SAST antes de cada release”, “el tiempo medio de remediación de vulnerabilidades críticas será inferior a 15 días”, “el 80% del equipo de desarrollo habrá completado la formación de OWASP Top 10”.
Nivel 3: Métricas estratégicas que influyen en la dirección
Las métricas no solo reflejan la realidad, sino que alimentan la toma de decisiones. Se alinean con los indicadores organizacionales y el valor de los activos. Ejemplos: coste medio de remediación por fase del SDLC (para justificar la inversión en shift-left), correlación entre formación recibida y reducción de defectos, ratio de vulnerabilidades encontradas internamente versus por terceros o atacantes.
Métricas operativas que recomendamos desde nuestra experiencia
Más allá de SAMM, en nuestra práctica profesional hemos identificado métricas adicionales que resultan especialmente útiles para equipos que están comenzando:
Cobertura del checklist SCP:
Debes preguntarte ¿qué porcentaje de las 14 áreas del checklist de Secure Coding Practices tiene tu equipo integrado en sus estándares internos y revisiones de código?
Densidad de defectos de seguridad:
Número de vulnerabilidades por cada 1.000 líneas de código, segmentado por severidad. Permite comparar la evolución entre releases.
Tasa de recurrencia:
¿Con qué frecuencia reaparecen los mismos tipos de vulnerabilidades tras haberlas corregido? Una tasa alta indica un problema de formación, no de herramientas.
MTTR (Mean Time to Remediate):
Segmentado por criticidad. Establece SLAs de remediación diferenciados: críticas en 48 horas, altas en 7 días, medias en 30 días.
Ratio de detección interna vs. externa:
El porcentaje de vulnerabilidades que encontráis vosotros mismos versus las que descubren pentests externos, bug bounties o, peor aún, incidentes reales. Un programa maduro detecta la mayoría internamente.
Hoja de ruta práctica:
Cómo introducir el desarrollo seguro en la cultura de trabajo. El mayor reto no es técnico, es cultural. Aquí proponemos una hoja de ruta en 4 fases, inspirada en el enfoque iterativo de SAMM, que permite introducir prácticas de desarrollo seguro sin generar rechazo ni paralizar la entrega de software.
Fase 1: Cimientos (meses 1–3)
Objetivo: obtener visibilidad y generar conciencia sin imponer procesos pesados.
Realiza la evaluación SAMM inicial
Descarga el SAMM Toolbox (un Excel disponible gratuitamente en owaspsamm.org) y evalúa tu estado actual en las 15 prácticas. No busques perfección: el objetivo es obtener una foto realista. Involucra a responsables de desarrollo, operaciones y producto, no solo a seguridad.
Forma al equipo en lo básico
Organiza una sesión de 2–3 horas sobre OWASP Top 10 y las prácticas del SCP Checklist. No se trata de convertir a todos en expertos en seguridad, sino de que comprendan los riesgos más comunes y las prácticas que los mitigan. SAMM coloca Education and Guidance como la prioridad más alta de cualquier programa de seguridad: sin formación, el resto de las prácticas no tienen sobre qué sostenerse.
Integra un escáner SAST básico
Añade un análisis estático de seguridad al pipeline de CI/CD, configurado inicialmente en modo informativo (que reporte, no que bloquee). Herramientas como SonarQube, Semgrep o Checkmarx ofrecen planes de inicio gratuitos o asequibles. El objetivo es generar datos y visibilidad, no frenar entregas.
Identifica los “quick wins” del checklist SCP
Selecciona 3–4 prácticas del checklist que tu equipo aún no aplique y que tengan mayor impacto: validación de entrada del lado del servidor, codificación de salida y gestión de errores que no expongan información sensible suelen ser las más rentables.
Fase 2: Estructura (meses 3–6)
Objetivo: pasar de prácticas ad hoc a procesos repetibles.
Establece una política de desarrollo seguro
No tiene que ser un documento de 50 páginas. Un documento breve que defina las expectativas mínimas: qué controles son obligatorios, qué herramientas se usan, qué estándares se siguen (SCP Checklist como línea base) y qué formación es requerida.
Introduce el modelado de amenazas en proyectos nuevos
No hace falta un ejercicio exhaustivo en cada sprint. Empieza con sesiones de 30–60 minutos al inicio de cada proyecto o funcionalidad crítica, usando STRIDE o el enfoque que mejor se adapte a tu equipo. La clave es que los desarrolladores participen: cuando entienden las amenazas, escriben mejor código.
Implementa Security Champions
Identifica a un desarrollador por equipo que actúe como punto de referencia en seguridad. No necesita ser un experto: necesita curiosidad, formación continua y tiempo asignado para revisar código con perspectiva de seguridad. Este rol es el puente entre el equipo de seguridad (si existe) y el equipo de desarrollo.
Añade análisis de composición de software (SCA)
El código que escribes es solo una fracción de lo que se despliega. Herramientas como Dependabot, Snyk o OWASP Dependency-Check permiten identificar dependencias vulnerables antes de que lleguen a producción.
Integra user stories de seguridad
Añade historias de usuario de seguridad junto a las funcionales: “Como usuario, quiero que mi sesión expire tras 15 minutos de inactividad para que nadie pueda acceder a mi cuenta si dejo el equipo desatendido”. Esto normaliza la seguridad como un requisito más, no como un añadido.
Fase 3: Madurez (meses 6–12)
Objetivo: sistematizar, medir y demostrar mejora continua.
Activa el SAST en modo bloqueo para hallazgos críticos
Una vez que el equipo se ha acostumbrado al feedback del escáner, configura reglas que impidan mergear código con vulnerabilidades críticas. Hazlo gradual: primero solo críticas, luego altas.
Establece SLAs de remediación formales
Define plazos máximos de corrección según la severidad de la vulnerabilidad, alineados con la práctica de Defect Management de SAMM. Publica un dashboard que los haga visibles para todo el equipo.
Programa pentests periódicos
No como sustituto de las pruebas internas, sino como validación. Compara los hallazgos del pentest con los de tus herramientas internas: la diferencia te dice qué tan maduro es tu programa.
Implementa el dashboard de métricas SAMM
Centraliza las métricas definidas en la Fase 1 en un panel visible. Preséntalo periódicamente a dirección con la evolución de los KPIs. Esto es fundamental para justificar la inversión y mantener el apoyo ejecutivo.
Fase 4: Cultura (a partir del mes 12)
Objetivo: que la seguridad sea parte del ADN del equipo, no una imposición externa.
Automatiza todo lo automatizable
SAST, SCA, secrets scanning, IaC scanning, DAST en entornos de staging. Cuantas más comprobaciones se ejecuten sin intervención humana, más ancho de banda tiene el equipo para centrarse en las decisiones de diseño y las revisiones manuales de alto valor.
Crea guardrails, no barreras
En lugar de documentos de política que nadie lee, implementa salvaguardas técnicas que guíen al desarrollador hacia la opción segura por defecto: plantillas de proyecto con configuraciones seguras, bibliotecas internas de autenticación y cifrado ya validadas, linters con reglas de seguridad activadas.
Gamifica y reconoce
Reconoce públicamente a los equipos que mejoran sus métricas de seguridad. Organiza CTFs internos o retos de código seguro. La seguridad no puede vivir solo del miedo al incidente: necesita refuerzo positivo.
Repite la evaluación SAMM
Al menos una vez al año, vuelve a ejecutar la evaluación completa. Compara con la línea base inicial. Celebra los avances y recalibra los objetivos. El benchmark de SAMM te permite comparar tu madurez con otras organizaciones de tu sector.
Errores comunes que hemos visto y que debes evitar
1. Comprar herramientas antes de tener proceso
Un SAST sin criterios de triaje genera miles de alertas que nadie gestiona. Primero define qué es crítico para tu organización, luego elige la herramienta.
2. Intentar llegar a nivel 3 en todo desde el día uno
SAMM está diseñado para avances incrementales. Intentar una transformación completa de golpe genera fatiga, rechazo y abandono del programa.
3. Tratar la seguridad como responsabilidad exclusiva de un equipo
Si la seguridad es “cosa del equipo de seguridad”, los desarrolladores nunca la internalizarán. El modelo de Security Champions y la formación continua son imprescindibles.
4. No medir
Sin métricas no puedes demostrar mejora, y sin demostrar mejora no puedes justificar la inversión. El programa muere por inanición de apoyo ejecutivo.
5. Olvidar las dependencias
Tu código puede ser impecable, pero si una dependencia tiene una CVE crítica, estás expuesto. El SCA no es opcional en 2026.
El desarrollo seguro no es un destino, es un camino
No se consigue comprando una herramienta ni aprobando un pentest. Se construye con formación, con métricas, con procesos iterativos y, sobre todo, con la convicción de que la seguridad es una responsabilidad compartida por todo el equipo de desarrollo.
OWASP SAMM te da el marco estratégico para saber dónde estás y hacia dónde quieres ir. La OWASP Secure Coding Practices te da el checklist táctico para el día a día. Juntos, ofrecen una combinación potente: visión estratégica con acción operativa. Y lo mejor de todo: ambos son gratuitos, abiertos y mantenidos por una comunidad global de profesionales de seguridad.
Empieza pequeño. Mide. Itera. Y poco a poco, el código seguro dejará de ser un objetivo lejano para convertirse en la forma natural de trabajar de tu equipo.
En OneCyber ayudamos a las organizaciones a convertir estos principios en procesos reales y medibles. Desde la evaluación de madurez con OWASP SAMM hasta la implantación de prácticas de desarrollo seguro, Security Champions, revisiones de arquitectura y programas de mejora continua, nuestro objetivo es integrar la seguridad en cada fase del ciclo de vida del software sin comprometer la velocidad de entrega. Porque la seguridad más efectiva no es la que se añade al final, sino la que forma parte del diseño, el desarrollo y la operación desde el primer día.
