Cada vez que una empresa decide mantener su propia plataforma de integración continua en lugar de delegarla en un proveedor externo, gana algo. Gana control, personalización e independencia de terceros. Lo que no suele hacer es decidir con la misma claridad quién asume, día a día, la responsabilidad operativa que ese control exige.
Seguridad en CI/CD: quién debe asumir la responsabilidad operativa
He visto equipos que llevan meses celebrando tiempos de entrega más rápidos y despliegues automatizados sin haber definido quién protege los agentes, quién custodia las credenciales, quién puede reconstruir una versión si algo falla.
El problema aparece cuando el servidor que ejecuta estos procesos se ve comprometido. En ese momento, la velocidad de despliegue pasa a un segundo plano y la cuestión crítica es otra: quién puede garantizar que lo que está en producción corresponde realmente con lo que se ha construido y validado.
Ahí es donde surge el verdadero riesgo de mantener el control de una plataforma de CI/CD sin haber definido claramente quién responde por su seguridad. Administrar la infraestructura no implica necesariamente asumir el riesgo operativo asociado a ella, aunque muchas organizaciones sigan tratando ambas responsabilidades como si fueran la misma.
Existen señales para verlo:
- Nadie sabe con certeza quién tiene acceso administrativo a los agentes de build.
- Las credenciales de despliegue llevan más de un año sin rotarse.
- No existe un procedimiento documentado para reconstruir una versión de forma independiente del sistema que la generó.
- Los cambios de configuración de la plataforma no dejan registro de quién los hizo ni cuándo.
- Nadie ha probado nunca, ni en un simulacro, si se puede verificar que un artefacto desplegado coincide con el código fuente.
- La conversación sobre quién es responsable de la plataforma solo ha ocurrido de forma informal, nunca como decisión de gobierno.
El fallo no aparece en el momento del compromiso. Aparece cuando la organización decide operar su propia plataforma de CI/CD y da por hecho que el mismo equipo que la usa para entregar rápido también la protege, sin comprobarlo que es cierto.
Sostener infraestructura propia no es solo mantenerla funcionando; es asumir que, si alguien la compromete, tienes forma de demostrarlo y de reconstruir lo que hacía antes del incidente. Cuando esa responsabilidad no está asignada explícitamente, nadie la ejerce hasta que ya es tarde.
El impacto en negocio
Primero, pierdes la capacidad de responder con datos ante un cliente, un auditor o un regulador que pregunte qué versión exacta está en producción y desde cuándo.
Segundo, cualquier certificación o proceso de venta que dependa de demostrar integridad de tu cadena de entrega se convierte en un riesgo comercial, no solo técnico.
Tercero, el coste de reconstruir confianza interna —la de tu propio equipo en su propio sistema— es más lento de recuperar que el de restaurar un servidor.
Para evitarlo revisa estas señales:
- Si nadie puede nombrar, sin consultar nada, quién es responsable de proteger la plataforma de CI/CD, interviene esta semana.
- Si las credenciales de despliegue llevan más de seis meses sin rotarse, interviene esta semana.
- Si no existe un procedimiento probado para reconstruir una versión de forma independiente, interviene este mes.
- Si nunca se ha simulado un compromiso de la plataforma, interviene este trimestre.
El estado real debe poder resumirse en una línea: qué controles existen hoy sobre la plataforma y quién los ejerce. El origen del problema suele estar en que, al asumir el control directo de la infraestructura, la responsabilidad operativa no se asignó de forma explícita.
A partir de ahí, existen tres opciones: mantener el modelo on-premise y formalizar la responsabilidad mediante un propietario definido, procedimientos documentados y auditorías periódicas; migrar a un servicio gestionado que transfiera al proveedor parte de esa responsabilidad operativa; o adoptar un modelo híbrido, estableciendo con claridad qué componentes permanecen bajo control interno y cuáles se externalizan.
La elección debe basarse en el riesgo que quiera asumir la organización y en la madurez operativa real del equipo, no en la que se presupone.
La decisión clave es identificar, con nombre y apellido, quién asume la responsabilidad operativa de la plataforma. El siguiente paso es designar a esa persona y fijar la fecha de la primera auditoría de accesos, permisos y credenciales.
Además, cualquier decisión de mantener infraestructura propia debería ir acompañada desde el primer día de un responsable operativo claramente identificado: no un equipo, sino una persona. Las revisiones de accesos, permisos y rotación de credenciales deben planificarse con la misma disciplina que los despliegues. También conviene simular, al menos una vez al año, un compromiso completo de la plataforma para comprobar si la organización sería capaz de reconstruir y desplegar una versión fiable sin depender de ella.
Si ahora estás trabajando sin un dueño claro de la responsabilidad operativa de tu plataforma de CI/CD. Lo que vas a evitar esta semana es esa ambigüedad: asigna el nombre, define el procedimiento de auditoría, ponle fecha. El coste real de no actuar no es solo el próximo incidente —es no poder demostrar nada cuando ocurra.
Por eso, esta semana te propongo que:
- Nombra, por escrito, quién es responsable de proteger tu plataforma de CI/CD.
- Audita cuándo se rotaron por última vez las credenciales de despliegue.
- Pregúntate si podrías reconstruir, hoy mismo, una versión sin depender del sistema que la construyó.
Si no tienes respuesta a la tercera, ya sabes por dónde empezar.