¿Qué estaba mal?
Nada dramático, y ahí está la cuestión. La seguridad se revisaba a mano al final de cada versión. Los hallazgos llegaban cuando el código ya estaba terminado, así que las versiones esperaban, y el mismo retrabajo volvía sprint tras sprint. El retraso era solo la parte visible. Debajo, los hallazgos de auditoría se acumulaban, el código antiguo arrastraba una deuda que nadie tenía tiempo de pagar, los componentes de terceros entraban en producción sin revisar, y un equipo de seguridad pequeño iba permanentemente por detrás. Todos hacían su trabajo. El trabajo estaba en el lugar equivocado. Las marcas rojas son las puertas de salida. Los puntos bajo el camino son donde se mide cada fase.
¿Qué hice?
Empecé por las personas, no por las herramientas. Un directivo aceptó patrocinar el cambio, un foro DevSecOps empezó a reunirse, y cada equipo de desarrollo nombró a un referente de seguridad, alguien que llevara las preguntas en ambas direcciones. Solo entonces tracé la hoja de ruta: guías, estándares y las herramientas que se conectarían al pipeline, medida con el OWASP DevSecOps Maturity Model. La meta era clara. Nivel 2 en todo en doce meses, y nivel 3 en las dos áreas que más importan, construcción y despliegue, prueba y verificación.
El año se dividió en cuatro fases, cada una con una puerta que había que cruzar para salir. Los tres primeros meses fueron la base: una evaluación, una política, y análisis de código y dependencias en una o dos aplicaciones piloto, no más. De los meses tres a seis, la automatización: controles de política, detección de secretos, pruebas dinámicas. De los meses seis a doce, la expansión: plantillas de pipeline para que los equipos nuevos empezaran seguros, análisis de infraestructura y contenedores. Después del mes doce viene la optimización, que nunca termina: monitorización en ejecución y una mirada trimestral a los números.
Cada paso del ciclo recibió su control. Modelado de amenazas al planificar. Detección de secretos al programar. Análisis de código, dependencias y lista de componentes al compilar. Pruebas dinámicas al probar. Artefactos firmados y un control de política al publicar. Análisis de infraestructura y contenedores, con una bóveda para los secretos, al desplegar. Monitorización en operación. Y como las herramientas sin dueño se degradan, reescribí las reglas de responsabilidad como una RACI para política, operación del pipeline, corrección y triaje, alineada con NIST SSDF, OWASP SAMM e ISO/IEC 27001:2022, para que la evidencia que pide un auditor se acumule sola.
¿Qué cambió?
La seguridad dejó de ser un evento y se convirtió en un hábito. Cuatro números dicen si el hábito se mantiene, cada uno con una línea base tomada en la primera fase: cuánto tarda en corregirse un fallo crítico, la proporción de hallazgos detectados antes de producción, cuántas aplicaciones pasan por un pipeline seguro y cuánto dura una publicación. Cada control se pilotó primero, luego se automatizó, y solo se convirtió en una barrera de publicación cuando los equipos confiaron en él. Ese orden impidió que arraigaran los dos riesgos que hunden estos programas: la resistencia de los desarrolladores y la fatiga de alertas.