¿Cómo integrarías la gobernanza de la seguridad en el SDLC en lugar de añadirla al final?
Respuesta breve
Integra la seguridad en cada fase del SDLC en lugar de probar al final: los requisitos incluyen requisitos de seguridad y privacidad, el diseño incluye modelado de amenazas, el desarrollo sigue normas de codificación segura con SAST, las pruebas añaden DAST y revisiones, y el lanzamiento requiere aprobación, todo gobernado por la política, la separación de funciones y el control de cambios. Corregir los fallos pronto es drásticamente más barato que tras el lanzamiento.
Esta pregunta se sitúa en la intersección de los dominios de seguridad del desarrollo de software y de gobernanza. Los entrevistadores quieren ver que tratas la seguridad como una actividad de ciclo de vida gestionada, no como un control puntual, y que sabes plantearla en términos de negocio y de proceso.
Seguridad en cada fase
La gobernanza significa una actividad de seguridad definida y un control en cada etapa del SDLC:
- Requisitos — capturar requisitos explícitos de seguridad y privacidad junto a los funcionales (autenticación, tratamiento de datos, necesidades regulatorias).
- Diseño — realizar modelado de amenazas (p. ej. STRIDE) para encontrar fallos arquitectónicos antes de que exista código alguno, cuando son más baratos de corregir.
- Desarrollo — imponer normas de codificación segura y ejecutar SAST en el pipeline.
- Pruebas — añadir DAST, análisis de dependencias y revisión de código centrada en la seguridad.
- Despliegue — exigir una aprobación de seguridad y verificar una configuración endurecida.
- Operación / mantenimiento — parchear, monitorizar y realimentar los hallazgos hacia los requisitos.
Por qué el shift left compensa
El argumento económico es central: el coste de corregir un fallo aumenta marcadamente cuanto más tarde se encuentra. Un fallo de diseño detectado en el modelado de amenazas cuesta una conversación; el mismo fallo detectado en producción puede significar un incidente, parcheo de emergencia y daño reputacional. El «shift left» es la gobernanza que optimiza coste y riesgo a la vez.
Los controles de gobernanza en torno al SDLC
La disciplina de proceso importa tanto como las herramientas: la separación de funciones para que quien escribe el código no lo lleve unilateralmente a producción, la gestión de cambios para que los lanzamientos se revisen y sean reversibles, y la gestión de la configuración para que los entornos sean conocidos y consistentes. Estos controles previenen tanto los errores honestos como la inserción maliciosa.
Qué buscan los entrevistadores
Un mapeo fase por fase de las actividades de seguridad con el modelado de amenazas situado en el diseño, el argumento de coste del shift left, y las envolturas de gobernanza — separación de funciones, gestión de cambios y de configuración — que hacen que el desarrollo seguro sea repetible en lugar de depender de heroicidades individuales.
Posibles preguntas de seguimiento
- ¿Qué es el modelado de amenazas y a qué fase pertenece?
- ¿Por qué importa la separación de funciones entre los desarrolladores y el despliegue en producción?
- ¿Cómo apoyan la gestión de cambios y la gestión de la configuración los lanzamientos seguros?