Secure SDLC (SSDLC)

Definición

El Secure SDLC / SSDLC (Secure Software Development Life Cycle) es un enfoque para integrar seguridad en todas las fases del SDLC (planificación, diseño, implementación, pruebas, despliegue y operación), en lugar de “probar al final”.

Contexto

El RAW destaca dos ideas clave:

• Coste: corregir fallos tarde es mucho más caro que corregirlos en diseño/implementación.
• Riesgo: introducir seguridad temprano reduce drásticamente el riesgo empresarial (incidentes, downtime, multas y daño reputacional).
• Operación y cultura (DevOps/DevSecOps): el “Shift Left” y la automatización se operacionalizan como prácticas de DevOps y DevSecOps.
• Marco base del ciclo de vida: ver SDLC (Software Development Life Cycle).

Desarrollo (MIT-style)

Principio central: seguridad por diseño (y por defecto)

Un SSDLC efectivo se apoya en dos principios prácticos (aparecen en el RAW al hablar de metodologías):

• Seguridad por diseño: tratar la seguridad como atributo de calidad, no como “feature opcional”.
• Seguridad por defecto: mínimos privilegios y superficies de ataque reducidas como estado base.

Implementación: cómo empezar (postura de seguridad)

Antes de “meter herramientas”, el RAW recomienda empezar por posture:

• Análisis de brechas (gap analysis): qué políticas/actividades existen y qué tan efectivas son.
• Crear Software Security Initiatives (SSI) con objetivos realistas y métricas para medir éxito.
• Formalizar procesos (política → procedimiento) y hacer un despliegue con feedback (no “big bang”).
• Invertir en capacitación y en las herramientas adecuadas (y capacitar antes de integrarlas).

Procesos SSDLC: qué integrar y cuándo

El RAW lista procesos clave que deben entrar en el ciclo de vida (y no vivir “fuera” del desarrollo):

• Evaluación de riesgos (temprano, en planificación/requisitos): ver Risk Management.
• Modelado de amenazas (diseño, antes de codificar): ver Threat Modeling.
• Escaneo/Revisión de código (implementación): manual + automatizada.
• Evaluaciones de seguridad (operación/mantenimiento o pre-release, según madurez): VA + pentest.

1) Evaluación de riesgos (integrada al SDLC)

El RAW propone tratar la evaluación como parte del “security by design”:

• Asumir que el software será atacado y definir riesgo aceptable con stakeholders (trade-offs coste vs impacto).
• Considerar peor escenario, usuarios afectados y accesibilidad del objetivo (remoto vs local, requiere auth vs abierto).
• Elegir enfoque de evaluación:
  • Cualitativo: bandas (Bajo/Medio/Alto), p.ej. Risk = Severity x Likelihood.
  • Cuantitativo: valores numéricos y cálculo (incluye ejemplo con ARO y pérdida anual).

Relacionado: Risk Management.

2) Modelado de amenazas (fase de diseño)

El RAW remarca que el threat modeling:

• Se integra mejor antes de escribir código.
• Se alimenta de la evaluación de riesgos (activos/impacto) y prioriza mitigaciones.
• Puede apoyarse en metodologías como STRIDE, DREAD y PASTA (ver Threat Modeling).

3) Codificación segura: revisión y análisis

El RAW cubre:

• Revisión manual: análisis línea a línea, requiere comunicación con devs para entender intención y flujos.
• Revisión/escaneo automatizado: aprovecha técnicas estáticas/dinámicas para detectar fallos mientras se escribe código.

Concepto operativo: estático vs dinámico

• Estático: analiza el código sin ejecutar (base de SAST).
• Dinámico: observa la app ejecutándose (base de DAST; y parte de IAST/RASP).

4) Automatización AppSec (SAST/DAST/IAST/SCA/RASP) y dónde encaja

El RAW presenta herramientas típicas (AST) y una cronología de despliegue:

• SAST (Static Application Security Testing): “caja blanca” sobre código fuente, útil temprano (incluso antes de merge).
• SCA (Software Composition Analysis): analiza dependencias (vulns + licencias); clave por uso intensivo de OSS.
• DAST (Dynamic Application Security Testing): “caja negra”, simula ataques sobre app corriendo; suele ir más tarde (staging/preprod).
• IAST (Interactive AST): “caja gris”, instrumentación/agent durante pruebas; aporta señales y a veces línea de código.
• RASP (Runtime Application Self-Protection): protección/telemetría en runtime tras el lanzamiento; bloquea/alerta.

Detalle y ejemplos prácticos (AST, taint analysis, CI/IDE): SAST (Static Application Security Testing). Detalle y ejemplos prácticos (crawling/AJAX, auth, APIs, CI/CD): DAST (Dynamic Application Security Testing).

Elección de herramientas (idea del RAW):

• Se complementan; usar dos o más mejora cobertura.
• No convertir la seguridad en “bloqueo”: adaptar a cómo el equipo entrega (CI/CD) y acompañar con capacitación.

5) Evaluaciones de seguridad (VA vs Pentest)

Según el RAW:

• Evaluación de vulnerabilidades (VA): detecta posibles vulnerabilidades, normalmente con herramientas automatizadas; puede dar falsos positivos y no siempre valida explotabilidad.
• Pruebas de penetración (pentest): más profundo; valida/explota, cuantifica riesgo y demuestra impacto real (con autorización).

Relacionado: Vulnerability Management.

Metodologías SSDLC: marcos y madurez

El RAW menciona varias aproximaciones:

• Microsoft SDL: principios y prácticas obligatorias por fases.
• OWASP S‑SDLC: “puertas de calidad” de seguridad y enfoque ágil con sprints de seguridad.
• Software Security Touchpoints (mencionado en el RAW como ejemplo).
• Modelos de madurez para medir/planificar: OWASP SAMM y BSIMM.

Ejemplos

• Planificación/requisitos: si un usuario puede leer una entrada de blog, no necesariamente puede editarla o borrar campos (principio del RAW: requisitos de seguridad junto a funcionales).
• CI/CD: SAST + SCA en PR/merge; DAST/IAST en staging; pentest antes de go-live en releases críticas.

Pitfalls / Errores comunes

• “Comprar herramientas” sin procesos, métricas ni capacitación (genera ruido y rechazo).
• Hacer threat modeling tarde (cuando ya hay decisiones de arquitectura difíciles de revertir).
• Tratar VA como sustituto de pentest (y viceversa) sin entender objetivos/limitaciones.
• No definir criterios de “calidad de seguridad” (quality gates) ni ownership para findings.

Diagrama

flowchart LR
R[Requisitos] --> D[Diseño]
D --> I[Implementación]
I --> T[Pruebas]
T --> P[Preprod/Release]
P --> O[Operación]

R --> Rg[Riesgo]
D --> TM[Threat Modeling]
I --> SAST[SAST/SCA + Code Review]
T --> DAST[DAST/IAST]
O --> RASP[RASP + Monitoreo]
O --> VA[VA/Pentest]

Referencias

1. TryHackMe — Introducción a DevSecOps: https://tryhackme.com/room/introductiontodevsecops
2. ResearchGate — “Integrating Software Assurance into the SDLC”: https://www.researchgate.net/profile/Maurice-Dawson/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC/links/02e7e52114e5e1ba71000000/Integrating-Software-Assurance-into-the-Software-Development-Life-Cycle-SDLC.pdf?origin=publication_detail
3. OWASP — SAMM: https://owasp.org/www-project-samm/
4. Comparativa BSIMM vs SAMM (blog): https://owaspsamm.org/blog/2020/10/29/comparing-bsimm-and-samm/