Secure SDLC

El Secure SDLC integra la seguridad en todo el ciclo de vida del desarrollo, en vez de dejarla como una auditoría al final. El principio es el shift-left: cuanto antes se encuentra un fallo, más barato es corregirlo —un bug de diseño en producción cuesta órdenes de magnitud más que en la fase de requisitos.

Por qué shift-left

Coste de corregir un fallo:   requisitos < diseño < código < test < PRODUCCIÓN
# encontrar un fallo en diseño (threat modeling) es mucho más barato que un incidente en prod
# DevSecOps = "seguridad como responsabilidad de todos, automatizada en el pipeline"

Seguridad por fase

Requisitos   requisitos de seguridad y abuso (abuse cases), privacidad por diseño (RGPD)
Diseño       threat modeling (dso-threatmodel), decisiones de arquitectura seguras
Desarrollo   secure coding, linters, pre-commit hooks, SAST en el IDE/PR (dso-sast)
Build/CI     SAST, SCA (dso-deps), secretos (dso-secrets), IaC scan (dso-iac)
Test         DAST, pruebas de seguridad, fuzzing; pentest antes de release
Deploy       hardening, firma de artefactos, políticas de admisión (dso-cicd, dso-k8ssec)
Operación    monitorización, gestión de vulns (def-vulnmgmt), respuesta (dfir)

Marcos de referencia

OWASP SAMM     modelo de madurez para evaluar/mejorar el programa de AppSec
BSIMM          benchmark de prácticas reales de la industria
NIST SSDF (800-218)  prácticas de desarrollo seguro
OWASP ASVS     requisitos de verificación de seguridad de aplicaciones (checklist)

Automatización en el pipeline (gates)

- SAST/SCA/secrets/IaC como pasos del CI que FALLAN el build ante hallazgos críticos
- equilibrio: gates que no ahoguen (falsos positivos) ni dejen pasar lo crítico
- resultados en el PR (feedback rápido al dev) y en un panel de postura (AppSec)
- excepciones gestionadas y con caducidad, no "ignorar para siempre"

Cultura y campeones

- Security Champions: un dev por equipo con foco de seguridad -> escala el programa
- formación en secure coding; retro de incidentes -> mejoras de proceso
- "paved road": plantillas/librerías seguras por defecto que facilitan hacerlo bien

Blue Team / AppSec

Automatizar controles en el pipeline (SAST/SCA/secrets/IaC) con gates proporcionados al riesgo.
Empezar por el threat modeling en diseño (Threat modeling en diseño): lo más barato de corregir.
Medir madurez con SAMM/ASVS y priorizar por riesgo, no por volumen de hallazgos.
Cerrar el bucle con gestión de vulnerabilidades (Gestión de vulnerabilidades) y respuesta (dfir).

CVEs y casos reales

Equifax (2017): un fallo de dependencia (Struts) no gestionado en el SDLC → brecha masiva.
SolarWinds (2020): comprometer el build/CI (Seguridad en CI/CD) para inyectar en el producto cambió el foco hacia la seguridad de la cadena de suministro.
Log4Shell (2021): la falta de SBOM/SCA (Dependencias & SCA) determinó la capacidad de respuesta.

Checklist de prueba

Requisitos de seguridad y abuse cases definidos
Threat modeling en diseño (Threat modeling en diseño)
SAST/SCA/secrets/IaC automatizados en el CI con gates
DAST/pentest antes de release
Firma de artefactos y políticas de despliegue (Seguridad en CI/CD)
Monitorización y gestión de vulns en operación (Gestión de vulnerabilidades)
Madurez medida (SAMM/ASVS) y Security Champions
Excepciones gestionadas con caducidad