DevSecOps integra las decisiones y evidencias de seguridad en la entrega de software, en lugar de tratarlas como una revisión final. En una canalización de integración continua y entrega continua (CI/CD) multinube, la cuestión central no es qué nube ejecuta la aplicación, sino qué componente puede modificar el código fuente, ejecutar código de compilación, publicar un artefacto o invocar una API de despliegue del proveedor. Esas capacidades definen el límite de seguridad.
Para este curso, el contexto de proveedores incluye AWS, Microsoft Azure y Google Cloud. Cada proveedor gestiona sus propios límites de recursos e identidad, mientras que un plano de control de CI central coordina las definiciones de la canalización, la programación de tareas, las aprobaciones y el registro de resultados. Esta lección establece una carga de trabajo delimitada para que, posteriormente, los controles puedan evaluarse frente a identidades, artefactos y destinos de despliegue concretos.
Una revisión de seguridad de una canalización multinube no puede comenzar hasta que esté claro qué elementos están dentro del alcance, ya que un runner o un registro fuera de dicho alcance podría modificar una versión de lanzamiento sin pasar por una revisión. El límite de la canalización comprende el conjunto de repositorios, servicios del plano de control, runners, identidades, almacenes de artefactos e interfaces de despliegue que intervienen en la transformación de un cambio en una versión de lanzamiento. Este límite comienza cuando un cambio en el repositorio puede influir en el comportamiento de la canalización y se extiende hasta las acciones de la API del proveedor que crean o modifican la carga de trabajo. Las solicitudes en tiempo de ejecución dirigidas a la aplicación desplegada quedan fuera de este límite, aunque posteriormente se puedan vincular evidencias de la versión de lanzamiento con el comportamiento en tiempo de ejecución.
El plano de control central, denominado ci-control, no reside automáticamente dentro de AWS, Azure o Google Cloud. Sus runners ejecutan las tareas de compilación y despliegue, y posteriormente se autentican de forma independiente en la cuenta dev de AWS, la suscripción dev de Azure y el proyecto orders-dev de Google Cloud. Un runner pasa a formar parte del límite de un proveedor únicamente cuando está alojado en él. Su ubicación modifica la exposición a la red y los mecanismos de identidad disponibles, pero no elimina la necesidad de contar con una autorización del proveedor de alcance restringido.
Ahora podemos rastrear qué componentes atraviesan el límite de cada proveedor.
Una canalización (pipeline) centralizada solo reduce la duplicación si sus controles se aplican de manera coherente. La proliferación de credenciales ocurre cuando numerosos trabajos, repositorios o entornos de proveedores conservan credenciales independientes de larga duración y con amplios permisos de acceso. Una credencial de despliegue filtrada puede permanecer activa más allá del trabajo que la requirió, y el uso de una credencial compartida impide que los registros de auditoría distingan entre distintas ejecuciones de la canalización. El uso de credenciales de corta duración, específicas para cada ejecución, limita tanto el tiempo de validez como el alcance del despliegue afectado.
Los controles de escaneo también pueden sufrir desviaciones. Un escaneo de vulnerabilidades con un umbral de fallo en una ruta de AWS y un umbral distinto en una ruta de Azure o Google Cloud no constituye una decisión de seguridad unificada, aunque todas las rutas utilicen la misma herramienta de escaneo. La canalización debe registrar el artefacto evaluado, el conjunto de reglas aplicado, el resultado del análisis y el veredicto del punto de control (gate). El registro de un trabajo exitoso confirma que dicho trabajo informó un resultado positivo durante su ventana de tiempo registrada; sin embargo, por sí solo, no garantiza que todos los recursos en el entorno del proveedor coincidan con el estado deseado.
La copia de recursos entre nubes añade otro límite operativo. Una imagen copiada entre registros puede ser reemplazada, copiarse de forma incompleta o promoverse bajo una etiqueta ya existente. Las etiquetas identifican una referencia mutable, mientras que el digest (huella digital) identifica el contenido específico de la imagen. La regla reutilizable consiste en autorizar cada acción del proveedor de forma independiente y mantener la trazabilidad del artefacto exacto en cada etapa de transferencia.
La carga de trabajo en ejecución es orders-api, un servicio que escucha en el puerto 8080. El código fuente de la aplicación reside en orders-api-repo, mientras que las definiciones de infraestructura se encuentran en orders-infra-repo. El proceso de compilación genera la imagen de contenedor ficticia orders-api:1.0; los cambios en la infraestructura se evalúan mediante la pila de Terraform orders-infra. Mantener separados los repositorios de código fuente y de infraestructura permite que los controles posteriores asignen permisos distintos de revisión, ejecución y despliegue a cada tipo de cambio.
La imagen se promueve a aws-ecr/orders-api, azure-acr/ordersapi y gcp-ar/orders-api, para luego desplegarse mediante acciones de API específicas de cada proveedor en sus respectivos entornos de desarrollo. La promoción implica copiar el mismo digest de imagen verificado a cada registro, en lugar de recompilar el código fuente para cada nube. La recompilación generaría artefactos distintos cuyos contenidos y evidencias podrían divergir, a pesar de compartir la misma etiqueta orders-api:1.0.
Podemos examinar las rutas del artefacto y de la infraestructura que esta carga de trabajo hace explícitas.