En la mayoría de las organizaciones la seguridad sigue siendo una puerta al final del camino: un equipo construye un producto durante semanas y luego choca con una auditoría previa a la publicación que puede retrasarlo todo varios sprints. Para un CISO o un responsable de seguridad eso es un conflicto diario, porque cuanto más tarde detectas una vulnerabilidad, más caro sale arreglarla. DevSecOps invierte el orden: la seguridad deja de ser una comprobación a posteriori y pasa a ser una propiedad del propio proceso de entrega.
Por nuestra experiencia, lo difícil no es comprar otro escáner, sino tejer los controles en el ritmo del equipo para que no frenen a nadie. Hemos entregado en sistemas sensibles desde el punto de vista de la seguridad y en dominios de alta exigencia, incluido el sector bancario, donde el cumplimiento y la protección de datos no son opcionales. Llevamos esa competencia a los equipos de entrega cubriendo los roles que suelen faltar: ingenieros DevSecOps, especialistas en identidad y arquitectos de seguridad.
¿Por qué la seguridad tiene que estar integrada en todo el ciclo de entrega?
Porque las amenazas no esperan al día de la publicación. Una librería vulnerable entra en el repositorio en el momento en que un desarrollador añade la dependencia, no en el momento de la auditoría. Si el único control es una revisión al final, el equipo se pasa un sprint entero construyendo sobre terreno inestable, y cada arreglo significa rehacer código que ya estaba terminado.
Integrar la seguridad en todo el ciclo cambia la economía del error. Una vulnerabilidad detectada en una pull request le cuesta unos minutos a un desarrollador; esa misma vulnerabilidad encontrada en producción es un incidente, un informe al regulador y horas extra para todo el equipo. DevSecOps no añade una etapa, reparte el control entre muchos puntos de comprobación pequeños a lo largo del camino - desde el commit, pasando por la build, hasta el despliegue. La seguridad deja entonces de competir con la fecha límite y empieza a protegerla.
¿Cómo se gestionan la identidad y los accesos (IAM) en el ciclo de entrega?
La gestión de identidades es la base, porque la mayoría de los incidentes graves empiezan por accesos excesivos o comprometidos. En la práctica vigilamos unas cuantas cosas:
- mínimo privilegio para personas y para servicios, nada de cuentas con acceso total guardadas «por si acaso»,
- identidades de máquina (service accounts, workload identity) tratadas con la misma seriedad que las humanas,
- credenciales de vida corta y rotación en lugar de claves estáticas pegadas de forma permanente,
- autenticación central (SSO, MFA) con un rastro de auditoría claro de quién tuvo acceso y cuándo.
Un IAM bien estructurado hace que incluso un intento de phishing exitoso no abra todo el entorno a un atacante, sino solo una porción estrecha y limitada en el tiempo.
¿Cómo se escanean dependencias y vulnerabilidades antes de que lleguen a producción?
Una aplicación moderna es en buena parte código de otros, así que controlar las dependencias importa tanto como controlar el propio. Conectamos varias capas de escaneo al pipeline:
- SCA (Software Composition Analysis) para detectar librerías open source vulnerables,
- SAST para el análisis estático del propio código frente a fallos de seguridad habituales,
- DAST para probar la aplicación en ejecución desde la perspectiva de un atacante,
- escaneo de contenedores e IaC en busca de CVE conocidos y configuraciones incorrectas.
Lo que cuenta no es el escaneo en sí, sino los umbrales que paran la build ante hallazgos críticos, más un tratamiento sensato de los menos urgentes para que el equipo no se ahogue en ruido de alertas.
¿Cómo se gestionan los secretos en los pipelines CI/CD?
Los secretos son el punto donde la teoría se separa más a menudo de la práctica. Contraseñas, tokens y claves de API acaban pegados en variables de entorno, en ficheros de configuración y, en el peor caso, directamente en el repositorio, desde donde viven para siempre en el historial de git. Cada secreto así es una llave lista para cualquier atacante que llegue al código.
Por eso sacamos los secretos del código a un almacén dedicado (como Vault o un gestor de secretos en la nube) y los exponemos al pipeline solo durante el tiempo que dura un job concreto. Encima añadimos escaneo del repositorio en busca de credenciales filtradas y rotación automática, para que incluso un token expuesto pierda su valor rápido. Es una capa poco vistosa de DevSecOps, pero sobre ella se apoya la credibilidad de todo lo demás.
¿Cómo se hace una revisión de seguridad de los pipelines CI/CD?
El propio pipeline suele ser el sistema con más privilegios de la empresa, porque tiene acceso al código, a los secretos y a producción. Por eso lo tratamos como un objetivo de ataque y comprobamos:
- los permisos de runners y agentes y el aislamiento de unas builds respecto a otras,
- la integridad de los artefactos - firma y verificación de lo que realmente desplegamos,
- la procedencia de las dependencias y registros de confianza en vez de descargar «de cualquier sitio»,
- la separación de funciones, para que una sola persona no pueda llevar un cambio a producción en silencio.
Una revisión así cierra el camino que los atacantes prefieren cada vez más: en lugar de atacar la aplicación, atacan la forma en que se construye.
¿Qué es shift-left y cómo se construye una cultura de seguridad?
Shift-left significa acercar los controles de seguridad lo máximo posible al momento en que se escribe el código - al IDE, a la pull request, a la primera build. La idea es que un desarrollador se entere de una vulnerabilidad mientras todavía recuerda qué escribió y por qué, y no tres semanas después, a través de otro equipo.
Las herramientas, sin embargo, son solo la mitad de la ecuación. La otra mitad es una cultura en la que la seguridad es responsabilidad compartida y no el departamento de otro. La construimos en pasos pequeños: pautas claras en las pull requests, security champions dentro de los equipos, retrospectivas cortas y sin culpables tras los incidentes. La tecnología atrapa los errores conocidos, pero son las personas quienes deciden si la seguridad se toma en serio o solo se marca en una casilla.
¿Qué competencias DevSecOps aportamos?
Formamos el equipo alrededor del hueco real en la organización del cliente, no alrededor de un catálogo prefabricado. Lo más habitual es que cubramos estos roles:
- un ingeniero DevSecOps que conecta escaneo, secretos y umbrales de seguridad al CI/CD,
- un especialista en IAM / identidad que pone orden en los accesos de personas y servicios,
- un arquitecto de seguridad que fija el modelo de amenazas y los estándares para los equipos,
- un ingeniero de plataforma / cloud que endurece los entornos de ejecución y la infraestructura como código.
Este montaje refuerza a un equipo existente justo donde le faltan manos o conocimiento, sin levantar desde cero un departamento de seguridad aparte.
Software a medida o refuerzo de equipo - ¿qué encaja con DevSecOps?
Depende de si estás construyendo algo nuevo o endureciendo un proceso existente. Para un producto nuevo funciona bien un proyecto de software a medida, con la seguridad como requisito desde el primer día de arquitectura. Para un ciclo de entrega maduro necesitas más a menudo refuerzo de equipo o un equipo dedicado - gente que entra en tus pipelines y eleva su resiliencia sin reorganizar toda la empresa. Expusimos las diferencias entre estos enfoques en nuestro artículo sobre modelos de colaboración en TI.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con experiencia real en sistemas sensibles desde el punto de vista de la seguridad:
- aportamos competencia construida, entre otros, en proyectos para el sector bancario, donde la protección de datos y el cumplimiento son una restricción dura,
- verificamos las competencias antes de empezar y formamos el equipo alrededor del hueco concreto, no «por si acaso»,
- tejemos la seguridad por todo el ciclo - desde IAM y secretos hasta el escaneo y la revisión del pipeline,
- trabajamos en una zona horaria cercana, así que nuestros especialistas entran en tus revisiones de código y en tu ritmo de trabajo sin una larga puesta en marcha.
Lo más habitual es que lo hagamos como refuerzo de equipo, cuando hay que cerrar rápido un hueco de DevSecOps, o como software a medida, cuando diseñamos la seguridad desde la base.
¿Por dónde empezar con DevSecOps?
Empieza por mapear un único flujo, el más importante: del commit a producción, marcando dónde hoy no hay ningún control. Eso revela los huecos más baratos de cerrar - normalmente secretos en el código y falta de escaneo de dependencias - y señala qué roles necesitas primero. No lo hagas todo a la vez; integra un control, confirma que no frena al equipo y añade el siguiente.
¿Quieres integrar DevSecOps en tu ciclo de entrega? Hablemos - ajustamos los especialistas y la secuencia de pasos a tu proceso.