¿Cómo es un SDLC seguro, y qué actividades de seguridad ocurren en cada fase?
Respuesta breve
Un SDLC seguro integra la seguridad en cada fase en lugar de añadirla al final. Los requisitos incluyen casos de seguridad y de abuso, el diseño añade modelado de amenazas, el desarrollo usa codificación segura y SAST más escaneo de dependencias, las pruebas añaden DAST y pruebas de penetración, y operaciones añade monitorización, parcheo y respuesta a incidentes — desplazando la seguridad hacia la izquierda.
Un ciclo de vida de desarrollo de software (SDLC) seguro integra la seguridad como una actividad continua a lo largo de todo el proceso de desarrollo en lugar de una puerta al final. La idea central es el shift left: cuanto antes se encuentre un fallo, más barato y fácil es corregirlo — un fallo de diseño detectado en una pizarra cuesta casi nada; el mismo fallo encontrado en producción tras una brecha es enormemente costoso.
Seguridad en cada fase
- Requisitos: captura los requisitos de seguridad y cumplimiento junto a los funcionales, y escribe casos de abuso — ¿cómo podría alguien usar mal esta función? — no solo historias de usuario.
- Diseño: realiza modelado de amenazas (p. ej. STRIDE) para identificar cómo podría atacarse el sistema y diseña los controles desde el principio. Las decisiones de arquitectura como los límites de confianza y los flujos de autenticación son las más baratas de acertar aquí.
- Desarrollo: sigue estándares de codificación segura, ejecuta SAST (análisis estático) en el IDE y en CI, y usa SCA / escaneo de dependencias para detectar bibliotecas de terceros vulnerables — la mayoría de las apps modernas son en su mayor parte código de otros.
- Pruebas / QA: añade DAST (pruebas dinámicas contra la app en ejecución), fuzzing y pruebas de penetración dirigidas antes del lanzamiento.
- Despliegue: escanea la infraestructura como código y las imágenes de contenedor, gestiona los secretos correctamente y endurece la configuración de ejecución.
- Operaciones / mantenimiento: monitorización y registro continuos, parcheo oportuno y un plan de respuesta a incidentes probado para manejar lo que se cuela. Los hallazgos retroalimentan los requisitos.
Cómo hacerlo funcionar
Automatiza las comprobaciones en el pipeline CI/CD para que la seguridad sea retroalimentación rápida, no un cuello de botella manual. Usa puertas basadas en el riesgo — falla el build ante hallazgos críticos, advierte ante los menores — para que la seguridad habilite la entrega en lugar de bloquearla.
Qué buscan los entrevistadores
Una respuesta de nivel senior mapea actividades específicas a fases específicas (modelado de amenazas en diseño, SAST/SCA en desarrollo, DAST/pruebas de penetración en QA, monitorización en operaciones), explica por qué desplazar hacia la izquierda ahorra dinero, y muestra conciencia de integrar todo esto en el pipeline sin paralizar la entrega.
Posibles preguntas de seguimiento
- ¿Por qué corregir una vulnerabilidad es más barato cuanto antes se detecta?
- ¿Cuál es la diferencia entre SAST, DAST y SCA?
- ¿Cómo integras puertas de seguridad sin bloquear el pipeline?