El ciclo de vida de desarrollo seguro (SSDLC, por sus siglas en inglés) es la forma de construir software en la que la seguridad se planifica, se diseña, se programa, se prueba y se mantiene en cada fase, en lugar de revisarse al final. En esta guía explicamos cómo organizamos el SSDLC en Gesdata: nueve fases, puntos de decisión con evidencias y su relación con los controles de ISO/IEC 27002:2022 y con el Esquema Nacional de Seguridad.
Está pensada para responsables de desarrollo, de sistemas y de seguridad que necesitan algo más que una lista de buenas prácticas: un SSDLC que funcione en el día a día y que un auditor pueda seguir de principio a fin.
Qué es el ciclo de vida de desarrollo seguro y por qué importa
Un ciclo de vida de desarrollo seguro es un conjunto de actividades, responsables y evidencias que integra la seguridad en todas las etapas del software: desde que se decide construir una aplicación hasta que se retira. Se aplica al desarrollo propio, al encargado a proveedores, a las integraciones y APIs, a la infraestructura como código y a las librerías de terceros que se incorporan al producto.
La idea es sencilla: un fallo de diseño detectado al definir los requisitos se corrige en una reunión; el mismo fallo detectado en producción obliga a parchear, desplegar de nuevo y, a veces, a gestionar un incidente. Un SSDLC bien implantado reduce la superficie de ataque y evita que la seguridad dependa de una revisión de última hora.
Además, el desarrollo seguro de software ya no es solo una buena práctica técnica. Es un control de ISO 27001, una medida del ENS para los sistemas incluidos en su ámbito y, en el caso de datos personales, una forma de demostrar la protección de datos desde el diseño y por defecto que exige el artículo 25 del RGPD.
Qué controles de ISO 27002 regulan el desarrollo seguro
La norma ISO/IEC 27002:2022 agrupa la mayoría de los controles de desarrollo en el tema tecnológico (cláusula 8). Son los mismos controles del Anexo A de ISO 27001:2022, así que deben aparecer en la declaración de aplicabilidad de cualquier organización que desarrolle o encargue software.
Control
Qué pide en la práctica
Evidencia típica
5.8 Seguridad en la gestión de proyectos
Tratar la seguridad como parte del proyecto: riesgos, recursos y responsables
Plan del proyecto con actividades de seguridad
8.4 Acceso al código fuente
Limitar y registrar quién lee y modifica el código
Permisos del repositorio y registros de acceso
8.25 Ciclo de vida de desarrollo seguro
Reglas de desarrollo seguro aplicadas a todo el ciclo
Política y procedimiento aprobados
8.26 Requisitos de seguridad de las aplicaciones
Definir qué debe proteger cada aplicación
Registro de requisitos de seguridad
8.27 Arquitectura e ingeniería de sistemas seguros
Principios de diseño seguro documentados y aplicados
Decisiones de arquitectura y modelo de amenazas
8.28 Codificación segura
Normas de programación y revisión del código
Revisiones de código y análisis automáticos
8.29 Pruebas de seguridad en desarrollo y aceptación
Probar los controles antes de producción
Plan de pruebas e informes de resultados
8.30 Desarrollo externalizado
Exigir y supervisar la seguridad del proveedor
Cláusulas contractuales e informes de entrega
8.31 Separación de entornos
Desarrollo, pruebas y producción separados
Inventario y segmentación de entornos
8.32 Gestión de cambios
Cambios registrados, probados y autorizados
Solicitudes de cambio con pruebas asociadas
8.33 Información de prueba
Proteger los datos usados en las pruebas
Datos sintéticos o anonimizados, excepciones aprobadas
Junto a ellos, la gestión de vulnerabilidades técnicas (8.8) y la gestión de la configuración (8.9) cierran el círculo en la fase de operación. Si quieres repasar la estructura completa de la norma, tienes un resumen en nuestro artículo sobre ISO 27002.
El desarrollo seguro en el ENS y en otros marcos
El Esquema Nacional de Seguridad (Real Decreto 311/2022) dedica a las aplicaciones informáticas dos medidas del Anexo II: el desarrollo de aplicaciones (mp.sw.1) y su aceptación y puesta en servicio (mp.sw.2). Su exigencia depende de la categoría del sistema, pero el enfoque es el mismo que en ISO 27002: entornos separados, seguridad integrada en la metodología y pruebas antes de poner la aplicación en servicio.
Hay otros marcos que conviene conocer porque se usan como referencia técnica: el Secure Software Development Framework (SSDF) del NIST, cuya versión final vigente es la 1.1, y el estándar de verificación OWASP ASVS, cuya versión estable es la 5.0. Y si fabricas productos con elementos digitales, el Reglamento de Ciberresiliencia (UE) 2024/2847 ya obliga desde el 11 de septiembre de 2026 a notificar vulnerabilidades explotadas e incidentes graves, y el resto de sus obligaciones se aplicará a partir del 11 de diciembre de 2027.
Principios que sostienen un desarrollo seguro
Antes de hablar de las fases del SSDLC, conviene fijar los principios. Son los que resuelven las dudas que el procedimiento no prevé:
- Seguridad desde el diseño y por defecto: la seguridad entra con los requisitos y la configuración entregada es la más restrictiva posible.
- Mínimo privilegio: usuarios, procesos y servicios operan solo con los permisos que necesitan; nada de cuentas administrativas para servicios estándar.
- Defensa en profundidad: controles en varias capas (red, aplicación, datos e identidad), de modo que el fallo de uno no deje el sistema expuesto.
- Confianza cero: ningún usuario, servicio o componente es de confianza por estar en la red interna; toda comunicación relevante se autentica, se autoriza y, cuando procede, se cifra.
- Fallo seguro: ante un error, el sistema deniega el acceso o bloquea la operación.
- Segregación de funciones: quien desarrolla el código no lo despliega en producción.
Clasificar antes de construir: el nivel de criticidad
No todas las aplicaciones necesitan el mismo esfuerzo. Una utilidad interna sin datos personales no requiere el mismo análisis que un portal de clientes expuesto a Internet. Por eso el primer paso del SSDLC es inventariar la aplicación y clasificarla, junto con el responsable de seguridad, según tres criterios:
Criterio
1 punto
2 puntos
3 puntos
Datos tratados
Públicos o técnicos
Internos o personales no sensibles
Sensibles o regulados
Exposición
Red interna restringida
Acceso remoto controlado
Acceso desde Internet
Impacto si falla
Bajo, herramienta de apoyo
Medio, afecta a un proceso
Alto, afecta a procesos críticos o clientes
La suma va de 3 a 9 puntos. Un reparto coherente sería, por ejemplo, de 3 a 4 para el nivel básico, de 5 a 6 para el estándar y de 7 a 9 para el crítico. En caso de duda se asigna el nivel superior. Los requisitos son acumulativos: cada nivel incorpora los del anterior.
Nivel
Mínimos de seguridad orientativos
Básico
Revisión de código por pares y análisis de dependencias
Estándar
Además, análisis estático y dinámico automatizados y modelado de amenazas
Crítico
Además, modelado de amenazas completo y prueba de penetración externa antes del pase a producción
Las 9 fases del ciclo de vida de desarrollo seguro
El flujograma resume cómo trabajamos el ciclo de vida de desarrollo seguro. Cada fase responde a una pregunta, deja una evidencia y termina en un punto de decisión: si no se cumplen los controles, se corrige y se vuelve a validar.
1. Gobierno: ¿qué riesgo tiene?
La aplicación se da de alta en el inventario de activos y se clasifica con el método anterior. Esa clasificación determina qué controles y pruebas del SSDLC serán obligatorios. Sin inventario no hay forma de saber qué software tiene la organización ni quién responde de él.
2. Planificación: ¿cómo integramos la seguridad?
Se definen el alcance, los roles (propietario de la información, responsable del proyecto, arquitecto y responsable de seguridad) y un análisis preliminar de riesgos. El plan de seguridad del proyecto fija las actividades de cada fase, las pruebas previstas, las evidencias que se conservarán, el stack tecnológico y las herramientas que se integrarán en la cadena de construcción. Un control clave en este punto: los lenguajes y frameworks elegidos deben tener soporte activo y parches de seguridad disponibles.
3. Requisitos: ¿qué debe proteger el sistema?
En el ciclo de vida de desarrollo seguro, los requisitos de seguridad se escriben como los funcionales: concretos y verificables. Como mínimo cubren autenticación, autorización y sesiones; protección de datos sensibles (cifrado, enmascarado, conservación y borrado seguro); registro y trazabilidad; y disponibilidad. Cada requisito lleva su criterio de aceptación y el responsable de seguridad aprueba la versión inicial antes de pasar al diseño. Para las funciones críticas se añaden casos de abuso: cómo intentaría un atacante usar esa funcionalidad.
4. Diseño y arquitectura segura: ¿cómo cumplimos los requisitos?
Se dibujan los componentes, los flujos de datos y los límites de confianza (Internet, zona desmilitarizada, red interna, proveedor), y se decide en qué capa se aplica cada control. En las aplicaciones de nivel estándar y crítico se hace un modelado de amenazas, por ejemplo con la metodología STRIDE: suplantación, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Las contramedidas que salen del análisis vuelven a los requisitos y al backlog como tareas de desarrollo. Es un proceso iterativo, no un documento que se archiva.
5. Desarrollo y codificación segura: ¿cómo construimos los controles?
El desarrollo seguro de software empieza por una norma de codificación que el equipo aplica: validación de entradas en el servidor y con listas blancas, codificación de salidas según el contexto, consultas parametrizadas, control de acceso en cada operación del servidor, sesiones con identificadores aleatorios y cookies protegidas, y nada de criptografía casera. Cada cambio pasa por una revisión de otra persona y por análisis automáticos. Las dependencias se controlan con análisis de composición (SCA) y un inventario de componentes (SBOM). Y una regla sin excepciones: ningún secreto, clave o token dentro del código ni de su historial.
6. Pruebas de seguridad y aceptación: ¿funcionan los controles?
En el SSDLC, antes de ejecutar las pruebas se aprueba un plan proporcional al nivel de criticidad: análisis estático (SAST), análisis dinámico (DAST) en el entorno de pruebas, análisis de dependencias, análisis de vulnerabilidades de la infraestructura y, en las aplicaciones críticas, prueba de penetración. Las pruebas se hacen con datos sintéticos o anonimizados. Los hallazgos se corrigen y se vuelven a probar; si el defecto es de diseño, se vuelve a la fase de diseño.
7. Despliegue y paso a producción: ¿podemos ponerlo en servicio?
El pase exige una solicitud de cambio aprobada, un plan de marcha atrás probado, un entorno de destino bastionado y la comprobación criptográfica (hash o firma) de que el paquete que se despliega es exactamente el que se probó. El despliegue lo ejecuta el área de sistemas u operaciones, no el equipo de desarrollo. Siempre que sea viable se usan despliegues graduales (azul-verde o canario) y, al terminar, una batería mínima de comprobaciones.
8. Operación y mantenimiento: ¿sigue siendo seguro?
La aplicación se monitoriza, sus registros de seguridad se integran en el sistema de monitorización y los parches de sistema y librerías se aplican en los plazos acordados. Al menos una vez al año se revisa el perfil de riesgo y se repiten las pruebas periódicas. Cualquier cambio de código, configuración o arquitectura vuelve a la fase afectada del SSDLC y repite las pruebas y validaciones que correspondan.
9. Retirada: ¿cómo cerramos sin dejar exposición?
El ciclo de vida de desarrollo seguro también planifica el fin de vida: se decide qué datos y qué código hay que conservar y se protege ese archivo; se revocan cuentas, tokens, claves y certificados; se borran o anonimizan los datos según la política de conservación; y se desconectan servidores, integraciones y reglas de cortafuegos. Las evidencias de borrado y revocación cierran el ciclo.
Quality gates: cómo decidir GO o NO-GO
Un SSDLC sin puntos de decisión se queda en una lista de recomendaciones. Los quality gates son hitos en los que se comprueba un conjunto de controles y se decide si el proyecto avanza. En nuestro SSDLC trabajamos con cinco:
En cada gate del SSDLC, cada control se evalúa como conforme, no conforme o no aplicable, y se marca como bloqueante o no bloqueante:
- Un control bloqueante no conforme detiene el proyecto: se corrige y se pide una nueva validación.
- Un control no bloqueante no conforme permite avanzar, pero se registra como deuda técnica de seguridad con responsable y fecha de resolución.
- «No aplica» siempre se justifica. Una casilla vacía no acredita conformidad.
La validación final la firman, como mínimo, el jefe de proyecto, el responsable de desarrollo y el responsable de seguridad, y el resultado puede ser aprobado, denegado o aprobado con riesgo.
Excepciones y deuda técnica de seguridad
Como regla general, no se despliega en producción software con vulnerabilidades críticas o altas sin resolver. Si una necesidad de negocio impide corregirlas a tiempo, se abre una excepción formal: justificación, medidas compensatorias provisionales y aprobación escrita del responsable de seguridad. Toda excepción aprobada pasa al inventario de deuda técnica con fecha límite. Una excepción no es un GO automático: permite evaluar el pase con un riesgo conocido y aceptado.
Controles transversales: repositorios, CI/CD y cadena de suministro
Hay controles del SSDLC que no pertenecen a una sola fase porque protegen la «fábrica» del software. Son los que más se descuidan y los que un atacante busca primero:
- Repositorios de código: cuentas nominativas con autenticación multifactor, permisos diferenciados de lectura, escritura y administración, ramas principales protegidas y cambios solo a través de solicitudes revisadas por otra persona.
- Pipeline de CI/CD: se trata como infraestructura crítica. Los entornos de construcción son temporales y aislados, los secretos se leen de una bóveda en el momento de usarlos y cada ejecución queda registrada (quién la lanzó, qué versión del código y qué resultado).
- Artefactos inmutables y firmados: lo que se compila no se modifica. Si hay un fallo, se corrige el código y se genera un paquete nuevo.
- Contenedores: registro privado, imágenes base mínimas analizadas antes de entrar, escaneo continuo, ejecución sin usuario root y bloqueo del despliegue si hay vulnerabilidades críticas o altas sin mitigar.
- Puestos y herramientas de desarrollo: equipos autorizados y actualizados, copias locales protegidas y servicios externos de desarrollo, incluidos los asistentes de programación, solo si están autorizados para el tipo de código que van a ver.
- Desarrollo por terceros: cláusulas contractuales con requisitos de seguridad, plazos de corrección y derecho de auditoría; cada entrega acompañada de su informe de análisis y, preferiblemente, de un SBOM.
Entornos separados y datos de prueba
La separación de entornos es uno de los controles del desarrollo seguro de software más visibles en una auditoría. Desarrollo, pruebas o preproducción y producción residen en segmentos de red separados, con cortafuegos que deniegan por defecto y accesos distintos para cada perfil. Cada entorno se identifica claramente en consolas y herramientas para evitar el error clásico de ejecutar en producción lo que se creía una prueba. En producción no se instalan compiladores ni herramientas de desarrollo.
Con los datos, la regla es no usar datos personales reales fuera de producción. Se prefieren datos sintéticos o anonimizados de forma irreversible. Si algún caso exige datos reales, se documenta una excepción con autorización previa, controles equivalentes a los de producción y fecha de eliminación. Esta disciplina conecta directamente el control 8.33 de ISO 27002 con las obligaciones del RGPD.
Trazabilidad: el hilo que sigue el auditor
Lo que distingue un desarrollo seguro de software bien implantado no es la cantidad de documentos, sino que todos cuenten la misma historia. Un auditor tomará un requisito y querrá ver cómo se diseñó, qué amenazas se analizaron, dónde se programó la contramedida, qué prueba la verificó y quién validó el resultado.
Para sostener ese hilo, la documentación del SSDLC que solemos estructurar con nuestros clientes tiene cuatro niveles:
Nivel
Documento
Para qué sirve
Dirección
Política de desarrollo seguro
Principios, responsabilidades y compromiso de la dirección
Proceso
Procedimiento del ciclo de vida
Fases, roles, gates y gestión de excepciones
Técnico
Instrucciones técnicas
Arquitectura, codificación, entornos, CI/CD, pruebas, despliegue y modelado de amenazas
Evidencia
Registros
Clasificación, requisitos y diseño, amenazas, plan de pruebas, excepciones y validaciones
Un consejo práctico: integra requisitos y decisiones de diseño en un único registro, de modo que cada requisito quede vinculado a su solución y a su método de verificación. Es más fácil de mantener que dos documentos que se desincronizan.
Errores frecuentes al implantar un SSDLC
Al revisar la documentación del ciclo de vida de desarrollo seguro antes de una auditoría, estos son los fallos que conviene buscar:
- Escalas de criticidad que no cuadran. Umbrales que no cubren el rango real de puntuación o niveles cuya numeración se invierte entre documentos. El resultado es que nadie sabe qué pruebas son obligatorias.
- Una hoja de cálculo que decide sola. Una herramienta que solo cuenta los incumplimientos bloqueantes no comprueba que se hayan rellenado todos los controles ni que los «no aplica» estén justificados.
- Contradicciones entre documentos. Por ejemplo, la política prohíbe por completo los datos reales en pruebas y una instrucción técnica los permite con autorización, o una norma impide que el desarrollador despliegue y otra lo admite con revisión.
- Referencias cruzadas rotas. Registros que remiten a documentos renombrados o retirados.
- Modelado de amenazas como trámite. Un análisis que no modifica ni un requisito ni una tarea del backlog no ha servido para nada.
- Deuda técnica sin fecha. Una excepción sin plazo de cierre se convierte en un riesgo aceptado para siempre.
- La cadena de construcción fuera del alcance. Se protege la aplicación, pero no el repositorio ni el pipeline que la producen.
Cómo encaja el ciclo de vida de desarrollo seguro con ISO 27001, el ENS y el CISO
El ciclo de vida de desarrollo seguro no es un proyecto aislado: es una pieza del sistema de gestión. En una implantación de ISO 27001 aporta la evidencia de los controles 8.25 a 8.33 y alimenta el análisis de riesgos y la declaración de aplicabilidad. En una adecuación al ENS responde a las medidas de desarrollo y aceptación de aplicaciones, y se apoya en la gestión de la configuración segura de los entornos.
Y alguien tiene que gobernarlo. El responsable de seguridad aprueba los requisitos, valida las pruebas, firma las excepciones y puede detener un despliegue con riesgos críticos sin mitigar. Si la organización no tiene esa figura en plantilla, un CISO externo puede asumir ese papel en los quality gates y rendir cuentas ante la dirección. Explicamos el detalle en las funciones del CISO externo.
Preguntas frecuentes
¿Qué es el ciclo de vida de desarrollo seguro?
Es el proceso que integra la seguridad en todas las fases del software. Un SSDLC completo abarca gobierno, planificación, requisitos, diseño, codificación, pruebas, despliegue, operación y retirada. Cada fase tiene actividades, responsables y evidencias, y el avance se decide en puntos de control.
¿Qué diferencia hay entre SDLC y SSDLC?
El SDLC describe cómo se construye software (cascada, ágil, DevOps). El SSDLC añade a cualquiera de esos modelos las actividades de seguridad y los puntos de decisión. No sustituye la metodología del equipo: se integra en ella.
¿Es obligatorio el desarrollo seguro de software?
ISO 27001 es una norma voluntaria, pero una organización certificada debe aplicar o justificar la exclusión de los controles de desarrollo en su declaración de aplicabilidad. El ENS es obligatorio para el sector público y sus proveedores en el ámbito del sistema, e incluye medidas de desarrollo y aceptación de aplicaciones. El RGPD exige protección de datos desde el diseño, y el Reglamento de Ciberresiliencia impone obligaciones a los fabricantes de productos con elementos digitales.
¿Qué pasa si una organización no desarrolla, sino que contrata el software?
El control 8.30 de ISO 27002 sigue aplicando: hay que fijar requisitos de seguridad en el contrato, exigir evidencias en cada entrega (informes de análisis y, preferiblemente, SBOM) y reservarse el derecho a probar el software antes de aceptarlo.
¿Cuándo es necesario un pentest?
Depende de la criticidad asignada en el SSDLC. Como referencia, se exige antes del pase a producción en las aplicaciones críticas o muy expuestas (acceso desde Internet o datos sensibles) y se repite periódicamente. En los niveles inferiores suelen bastar los análisis automatizados y la revisión de código.
¿Se pueden usar datos reales en el entorno de pruebas?
La regla general es no. Se usan datos sintéticos o anonimizados. Si un caso concreto lo exige, se tramita una excepción con autorización previa, controles equivalentes a producción y fecha de borrado.
¿Quién debe aprobar el paso a producción?
En el SSDLC, como mínimo, el responsable del proyecto, el responsable de desarrollo y el responsable de seguridad, además del propietario del sistema desde el punto de vista de negocio y riesgo. El despliegue lo ejecuta sistemas u operaciones.
¿Quieres implantar un ciclo de vida de desarrollo seguro?
En Gesdata Consulting ayudamos a diseñar e implantar el SSDLC dentro del sistema de gestión: política, procedimiento, instrucciones técnicas, registros y quality gates adaptados a tu forma de desarrollar, y alineados con ISO 27001 y el ENS. Si lo necesitas, también asumimos el papel de responsable de seguridad en los puntos de decisión.
Solicitar una revisión del desarrollo seguro