Ciclo de vida de desarrollo seguro (SSDLC): cómo implantarlo en una empresa de software

Por Kike Gandia · Co-Fundador y CEO, OSCP · Última actualización: noviembre de 2026

Un ciclo de vida de desarrollo seguro, o SSDLC, es el conjunto de prácticas que meten la seguridad en cada fase del desarrollo en lugar de dejarla para una prueba al final. No exige un equipo de seguridad propio ni parar la entrega de funcionalidades: exige decidir qué se comprueba en cada fase, quién lo hace y qué evidencia queda. Esta guía explica las fases, qué automatizar, dónde encaja el pentest y qué marcos usar, pensando en una empresa de desarrollo pequeña o mediana.

Por qué importa ahora

Corregir un fallo de seguridad en producción cuesta mucho más que evitarlo en el diseño, y además ahora hay alguien que pregunta. Los clientes certificados en ISO 27001 tienen que supervisar el desarrollo que externalizan, los bancos y aseguradoras sujetos a DORA tienen que controlar a sus proveedores TIC y la Administración exige el Esquema Nacional de Seguridad, que incluye medidas específicas de desarrollo de aplicaciones (mp.sw.1) y de aceptación y puesta en servicio (mp.sw.2).

Un SSDLC documentado es la respuesta a todos ellos: en vez de improvisar cada cuestionario, enseñas un proceso.

Las fases y qué hacer en cada una

Fase	Qué se hace	Evidencia que queda
Requisitos	Requisitos de seguridad pactados con el cliente, por ejemplo un nivel de OWASP ASVS	Requisitos en el contrato o en las historias de usuario
Diseño	Modelado de amenazas de lo nuevo: datos sensibles, roles, integraciones	Diagrama y amenazas identificadas con su mitigación
Desarrollo	Guía de codificación segura, revisión de código entre pares, secretos fuera del repositorio	Pull requests revisadas y reglas del linter
Integración	Análisis estático (SAST), de dependencias (SCA) y de secretos en el pipeline	Resultados del pipeline y excepciones aprobadas
Pruebas	Pruebas dinámicas (DAST) y pentest antes de las versiones importantes	Informe de pentest y re-test
Despliegue y mantenimiento	Configuración segura, gestión de vulnerabilidades de dependencias y respuesta a incidentes	Inventario de componentes (SBOM) y registro de parches

No hace falta implantarlo todo a la vez. Lo más rentable al principio suele ser requisitos claros, revisión de código con una lista de comprobación y análisis de dependencias en el pipeline.

Qué automatizar y qué no

Las herramientas automáticas son buenas encontrando patrones conocidos y muy malas entendiendo el negocio:

Automatizar: análisis de dependencias con vulnerabilidades conocidas, detección de secretos, análisis estático de patrones peligrosos y escaneo dinámico básico en cada versión.
No automatizar: el modelado de amenazas, la revisión de la lógica de negocio y la validación de permisos entre roles y entre clientes. Un escáner no sabe que un usuario de una empresa no debería ver las facturas de otra.

El error habitual es meter un escáner en el pipeline, llenarlo de avisos y que el equipo aprenda a ignorarlos. Mejor pocas reglas que bloqueen de verdad que muchas que nadie lee.

Dónde entra el pentest

El pentest no sustituye al SSDLC: lo comprueba. Tiene sentido antes de la primera entrega, antes de cada versión con cambios importantes (un módulo de pagos, un rol nuevo, una integración) y, como mínimo, una vez al año sobre lo que está en producción.

En una empresa que entrega a clientes, el momento clave es antes de la entrega: el informe del pentest y el re-test son la evidencia más fácil de enseñar, y los hallazgos llegan cuando aún se pueden corregir sin rehacer el proyecto.

Qué marco seguir

Marco	Qué es	Para qué te sirve
NIST SSDF (SP 800-218)	Lista de prácticas de desarrollo seguro agrupadas en cuatro bloques	Ordenar el proceso y responder a clientes que lo citan
OWASP SAMM	Modelo de madurez con niveles por práctica	Medir dónde estás y planificar mejoras por fases
OWASP ASVS	Lista de requisitos verificables para aplicaciones, en tres niveles	Pactar con el cliente qué nivel de seguridad se entrega y probarlo
ISO 27001:2022, controles 8.25 a 8.29	Controles de desarrollo seguro del anexo A	Lo que preguntará el auditor si tú o tu cliente estáis certificados

Para una empresa pequeña, lo práctico es usar ASVS para los requisitos y las pruebas, y SSDF o SAMM para ordenar el proceso. Si hay una certificación ISO 27001 en juego, el proceso debe cubrir lo que piden sus controles.

Un SSDLC ágil, sin frenar los sprints

En un equipo que trabaja por sprints, el SSDLC se integra en lo que ya existe:

Definición de hecho: una historia no está terminada si no ha pasado la revisión de código y el pipeline sin avisos críticos.
Refinamiento: las historias que tocan autenticación, permisos, pagos o datos personales llevan una nota de amenazas.
Por versión, no por sprint: el pentest se planifica para las versiones importantes, no para cada sprint.
Una persona de referencia: no hace falta un equipo de seguridad; sí alguien del equipo que sea el punto de contacto y que mantenga la lista de comprobación.

FAQ

¿Qué diferencia hay entre SDLC y SSDLC?

El SDLC es el ciclo de vida de desarrollo de software: requisitos, diseño, desarrollo, pruebas, despliegue y mantenimiento. El SSDLC es ese mismo ciclo con actividades de seguridad en cada fase, en lugar de una revisión de seguridad al final.

¿Hace falta un equipo de seguridad para implantar un SSDLC?

No. En una empresa pequeña basta con una persona de referencia dentro del equipo, unas pocas reglas automáticas en el pipeline, revisión de código con una lista de comprobación y un pentest externo en las versiones importantes.

¿Qué herramientas necesito para empezar?

Un analizador de dependencias, un detector de secretos y un analizador estático integrados en el pipeline. Hay opciones de código abierto para los tres. Más importante que la herramienta es decidir qué avisos bloquean una versión y quién revisa las excepciones.

¿Un SSDLC me sirve para ISO 27001 o el ENS?

Sí, si está documentado y deja evidencia. ISO 27001:2022 dedica los controles 8.25 a 8.29 al desarrollo seguro, y el ENS tiene medidas específicas de desarrollo de aplicaciones (mp.sw.1) y de aceptación y puesta en servicio (mp.sw.2). El auditor querrá ver el proceso y pruebas de que se aplica.

¿Cada cuánto hay que hacer un pentest?

Antes de la primera entrega, antes de cada versión con cambios importantes y, como mínimo, una vez al año sobre lo que está en producción. Entre medias, las pruebas automáticas del pipeline cubren lo más repetitivo.