Parte: 11 — DevSecOps y seguridad del SDLC · Fuente: Agile Application Security (Bell, Brunton-Spall, Smith, Bird) y NIST SP 800-218 (SSDF) ⏱️ Duración estimada: 90 min · Nivel: Fundamentos
Entender qué es un ciclo de vida de desarrollo de software seguro (Secure SDLC), por qué mover la seguridad "hacia la izquierda" del ciclo reduce drásticamente el coste y el riesgo, y qué controles concretos corresponden a cada fase. Al terminar, el alumno sabrá dibujar el SDLC de su organización y ubicar en él las prácticas y herramientas de esta parte.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Fases del SDLC | Es el mapa donde ubicaremos todos los controles |
| 2 | Coste de remediación por fase | Justifica económicamente el shift-left |
| 3 | Shift-left vs shift-right | Complementarios: prevenir y también observar en producción |
| 4 | Controles por fase (gates) | Define qué se automatiza y dónde |
| 5 | OWASP SAMM / BSIMM | Modelos de madurez para medir progreso |
| 6 | NIST SSDF (800-218) | Marco de referencia reconocido y auditable |
| 7 | Roles y responsabilidad compartida | "Security is everyone's job", no solo de AppSec |
El ciclo de desarrollo seguro parte de una idea sencilla: una vulnerabilidad no aparece únicamente cuando una herramienta la detecta. Antes fue una decisión de requisitos, diseño, implementación, dependencia, configuración o despliegue. Por eso integrar seguridad significa crear evidencia y retroalimentación en cada una de esas decisiones. En requisitos se establecen propiedades verificables —por ejemplo, quién puede autorizar una transferencia—; en diseño se modelan fronteras de confianza; en código se revisan patrones peligrosos; en construcción se protege la procedencia del artefacto; y en operación se comprueba si las hipótesis siguen siendo válidas.
NIST SSDF no prescribe un pipeline único. Organiza prácticas de alto nivel en cuatro grupos: preparar a la organización, proteger el software, producir software bien asegurado y responder a vulnerabilidades. Esto permite integrarlo en Scrum, Kanban o un proceso regulado sin fingir que todos trabajan igual. El control apropiado depende del riesgo del producto: una biblioteca abierta, una API financiera y el firmware de un dispositivo médico no necesitan exactamente los mismos gates.
El diagrama es un ciclo, no una cinta que termina al desplegar. Shift-left acorta la distancia entre introducir y descubrir un defecto; shift-right devuelve evidencia de producción: comportamientos reales, rutas que las pruebas no cubrieron y controles que fallaron. Ninguno sustituye al otro. Una validación de autorización debe diseñarse y probarse antes de publicar, pero también observarse después para detectar abuso de cuentas legítimas.
Un gate es una decisión explícita: continuar, advertir o detener. Bloquear cada hallazgo desde el primer día suele producir evasión porque los analizadores emiten resultados con diferente confianza. Es preferible comenzar con una línea base, bloquear secretos confirmados y vulnerabilidades críticas nuevas, y asignar el resto con plazos y responsables. La regla debe incluir alcance, severidad, excepción temporal, evidencia exigida y fecha de revisión. Así el pipeline materializa una política en vez de convertirse en una colección opaca de herramientas.
Tampoco debe repetirse como ley universal que corregir en producción cuesta exactamente 100 veces más. La dirección del efecto es razonable —un defecto tardío puede exigir migraciones, coordinación y recuperación—, pero la proporción depende del sistema y del estudio. En esta clase el alumno calcula el coste de un caso propio: tiempo de ingeniería, interrupción, soporte, exposición y oportunidad. Esa estimación es defendible porque hace visibles sus supuestos.
Un equipo termina una API y descubre en DAST que cualquier usuario puede consultar pedidos ajenos cambiando un identificador. El escáner encontró el síntoma, pero la causa nació antes: los requisitos no definieron la propiedad «solo propietario o soporte autorizado», el diseño no ubicó la decisión de autorización y las pruebas solo cubrieron respuestas exitosas. El arreglo profesional no es añadir una expresión al escáner. Se documenta la propiedad, se centraliza la autorización, se agregan pruebas negativas y telemetría de denegaciones. Este cambio conecta requisitos, diseño, código, prueba y operación.
| Término | Significado en esta clase |
|---|---|
| Propiedad de seguridad | Condición verificable que debe mantenerse, incluso ante entradas hostiles. |
| Gate | Regla de decisión del flujo, con evidencia, umbral y tratamiento de excepciones. |
| Línea base | Estado aceptado y documentado desde el que se impide introducir deuda nueva. |
| Shift-left | Retroalimentar seguridad antes, sin prometer eliminar los fallos de producción. |
| Shift-right | Validar hipótesis mediante observación y respuesta durante la operación. |
Hay dominio cuando el alumno puede tomar un cambio concreto, rastrear dónde puede introducir riesgo, asignar controles preventivos y detectivos por fase, justificar qué resultados bloquean la entrega y explicar cómo la evidencia operacional vuelve al backlog. Enumerar herramientas sin ese razonamiento no demuestra comprensión del SDLC seguro.
Esta clase es conceptual/estratégica; el "laboratorio" es de diseño. Necesitarás:
🧪 Laboratorio ejecutable del programa:
devsecops-pipeline— recorre las ocho capas y termina moviéndolas apre-commity CI: el shift-left aplicado de principio a fin.
Ejercicio aplicado de diseño y evaluación (no ofensivo):
Produce un documento de una página con el mapa del SDLC de un proyecto real (o de ejemplo), con al menos un control automatizado por fase y una auto-evaluación SAMM de tres prácticas.
Criterio de aceptación: el documento (a) cubre todas las fases desde requisitos hasta operación, (b) asigna al menos un gate automatizable a cada fase, (c) incluye puntuación SAMM 0–3 de tres prácticas con justificación, y (d) prioriza 3 mejoras con criterio impacto/esfuerzo explícito.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| "Shift-left = comprar herramientas SAST" | Confundir herramienta con proceso. Empieza por el proceso y los gates, la herramienta viene después. |
| El pipeline se llena de falsos positivos y se ignora | No se afinó ni se definió qué rompe el build. Calibra severidades y empieza en modo "warning". |
| AppSec sigue siendo cuello de botella | No se delegó ownership al equipo de desarrollo. Forma champions (clase 248) y automatiza. |
| Se mide "número de vulnerabilidades" y sube | Métrica sin contexto de riesgo. Mide tiempo de remediación y densidad por exposición. |
| Todo el foco en shift-left, nada en producción | Falta observabilidad. Complementa con shift-right (logging, detección en runtime). |
❓ ¿Shift-left significa que los desarrolladores hacen todo el trabajo de seguridad? No. Significa que las herramientas y prácticas de seguridad están disponibles para ellos temprano y de forma automatizada, con AppSec como habilitador y guardián de estándares, no como ejecutor único.
❓ ¿Necesito madurar en SAMM antes de automatizar? No es secuencial estricto. SAMM te da un diagnóstico; puedes empezar a automatizar los gates de mayor valor mientras subes de nivel en paralelo.
❓ ¿Secure SDLC aplica a metodologías ágiles? Sí, y es donde más brilla. En ágil los controles se integran en cada iteración y en el pipeline, no en un "gate de seguridad" al final del proyecto.
❓ ¿SSDF y SAMM compiten? No. SSDF (NIST) es un marco de prácticas de referencia; SAMM es un modelo de madurez para medirte. Se complementan: SSDF dice "qué", SAMM dice "cuánto de maduro".
Clase 235 — Respuesta a incidentes en la nube