Ciclo de vida de desarrollo seguro (SSDLC): qué es y cómo se implanta

Qué es exactamente

Un ciclo de vida de desarrollo seguro no es una fase que se añade al final del proyecto. Es la idea de que en cada tramo del desarrollo hay un trabajo de seguridad que solo se puede hacer bien en ese tramo, y que hacerlo antes o después sale mal o no sale.

Cuando se diseña, la pregunta es qué puede salir mal en esta arquitectura. Cuando se escribe código, es si estamos metiendo fallos conocidos. Cuando se integra, es qué estamos arrastrando de terceros. Cuando se publica, es si alguien puede romperlo de verdad. Y cuando ya está en producción, es si nos enteraríamos.

Dicho de otra forma: el SSDLC no añade una puerta al final, reparte varias puertas pequeñas a lo largo del camino. Ese es todo el concepto, y el resto son detalles de implantación.

Por qué la revisión al final no basta

El modelo de revisar la seguridad justo antes de salir a producción tiene dos problemas, y ninguno de los dos se arregla revisando mejor.

• Lo que encuentras al final ya no es barato de cambiar. Un fallo de autorización que nace de cómo se modelaron los permisos no se arregla con un parche: se arregla tocando el modelo, y a esas alturas hay código, datos y otras funcionalidades encima. La conversación deja de ser técnica y pasa a ser de calendario.
• Llega cuando ya no hay margen para decir que no. Si el informe aparece la semana antes del lanzamiento, la presión juega en contra de arreglarlo. Los hallazgos se convierten en riesgos aceptados, no porque alguien lo haya decidido con criterio, sino porque no había hueco.

No hace falta ningún estudio para ver el mecanismo: cuanto más tarde aparece una decisión de diseño equivocada, más cosas se han construido encima. Aquí no vas a encontrar la cifra habitual de cuántas veces más caro sale arreglarlo en producción, porque esa cifra circula atribuida a trabajos que no hemos leído y este sitio no publica números que no puede sostener.

Qué se hace en cada fase

Este es el reparto, en el orden en que aparece el trabajo. Ninguna fase necesita empezar comprando nada.

• Requisitos. Escribir qué datos maneja el sistema, quién debe poder verlos y qué pasaría si se filtran. Es la única fase donde la seguridad se puede expresar como un requisito y no como un arreglo.
• Diseño. Aquí es donde encaja el modelado de amenazas: sentarse delante del diagrama y preguntar por dónde entraría alguien. Es la actividad con mejor relación entre esfuerzo y resultado de toda la lista, y es la que casi nadie hace.
• Desarrollo. Análisis estático del código propio con SAST, y control de que no se cuelan credenciales en el repositorio, que es de lo que trata la gestión de secretos. Como referencia común de qué buscar, el OWASP Top 10 sigue siendo el vocabulario compartido.
• Dependencias. Casi todo el código de una aplicación moderna es de otros. El análisis de composición dice qué estáis usando y con qué fallos conocidos, y un SBOM deja constancia de ello para poder responder rápido el día que salga algo. Esa es la superficie por donde ocurre un ataque a la cadena de suministro.
• Pruebas. Análisis dinámico con DAST sobre la aplicación en marcha, y pruebas manuales de la lógica de negocio, que es lo que ninguna herramienta entiende.
• Producción. Saber qué versión hay desplegada, poder parchearla rápido y tener registros suficientes para reconstruir qué pasó. Sin esto, todo lo anterior caduca solo.

Las herramientas no son el ciclo

El error más común al implantar esto es comprar tres herramientas, enchufarlas a la integración continua y dar el proyecto por hecho. Lo que ocurre después es predecible: la tubería empieza a emitir cientos de avisos, nadie tiene tiempo de clasificarlos, y en unas semanas el equipo aprende a ignorar la alerta o directamente la desactiva. La organización acaba peor que antes, porque ahora además cree que está cubierta.

SAST, DAST y SCA producen entradas, no decisiones. El ciclo es lo que hagáis con esas entradas: quién las mira, con qué criterio se decide que algo bloquea una entrega, y qué se hace con lo que se decide no arreglar. Un equipo con una hoja de cálculo y ese criterio claro está más seguro que uno con tres cuadros de mando y ninguno.

Si tenéis que elegir por dónde meter dinero, meterlo en reducir el ruido de lo que ya tenéis rinde más que añadir una herramienta más.

Dónde encaja un pentest, y dónde no

Conviene no confundir dos cosas que suenan parecidas. Un análisis de vulnerabilidades busca en anchura con herramientas y encuentra clases de fallo ya catalogadas. Un test de intrusión busca en profundidad, con una persona, y encuentra lo que resulta de encadenar dos cosas que por separado no eran nada, o de que la lógica de negocio permita algo que nadie pensó.

Esa segunda categoría es la que no automatiza nadie, y es donde suelen estar los hallazgos que de verdad importan: permisos que se pueden escalar, flujos que se pueden repetir, identificadores que se pueden adivinar. Si queréis el detalle de cómo es ese trabajo por dentro, está en qué es el pentesting, y por tipo de objetivo en cómo funciona un pentest de aplicación web y cómo funciona un pentest de API.

Dentro de un SSDLC, un pentest no sustituye a lo anterior: llega después y comprueba si lo anterior funcionó. Nosotros lo hacemos sobre aplicaciones web y sobre API, y el entregable es una prueba reproducible de cada hallazgo con lo que hay que hacer para cerrarlo, no una lista de avisos de un escáner.

Por dónde empezar si hoy no tenéis nada

Implantar el ciclo entero de golpe no funciona en ningún equipo real. Este orden sí, y las tres primeras cosas no cuestan licencia:

• Una sesión de modelado de amenazas sobre lo que ya tenéis en producción. Dos horas, el diagrama delante y la pregunta de por dónde entraría alguien. Suele producir la lista de deberes de los seis meses siguientes.
• Saber qué dependencias tenéis. Antes que analizar nada, tener el inventario. Muchos equipos descubren aquí que no sabían qué había desplegado.
• Sacar las credenciales del repositorio. Es el hallazgo más repetido y el más barato de cerrar.
• Después, y solo después, automatizar. Una herramienta cada vez, con alguien que se encargue de afinar su ruido antes de meter la siguiente.

Si en algún punto queréis que alguien de fuera mire lo que habéis montado y trate de romperlo, esa conversación la tenemos aquí.

Nota sobre este artículo

Este texto describe una práctica, no una norma concreta, y por eso no cita apartados numerados de ningún estándar: la numeración cambia entre revisiones y una cita de memoria envejece mal. Tampoco lleva estadísticas sobre el coste de arreglar fallos tarde, por el motivo explicado más arriba.

Publicado el 3 de agosto de 2026.