DevSecOps integrates security decisions and evidence into software delivery rather than treating them as a final review. In a multicloud continuous integration and continuous delivery (CI/CD) pipeline, the central question is not which cloud runs the application. It is which component can change source, execute build code, publish an artifact, or call a provider deployment API. Those capabilities define the security boundary.
For this course, the provider context is AWS, Microsoft Azure, and Google Cloud. Each provider owns its own resource and identity boundary, while a central CI control plane coordinates pipeline definitions, job scheduling, approvals, and recorded results. This lesson establishes one bounded workload so later controls can be evaluated against concrete identities, artifacts, and deployment targets.
A security review of a multicloud pipeline cannot start until it is clear which parts are in scope, because a runner or a registry outside that scope can change a release without being reviewed. The pipeline boundary is the set of repositories, control-plane services, runners, identities, artifact stores, and deployment interfaces that participate in turning a change into a release. It begins when a repository change can influence pipeline behavior and extends through the provider API actions that create or modify the workload. Runtime requests to the deployed application are outside this boundary, although later evidence can connect a release to runtime behavior.
The central control plane, named ci-control, is not automatically inside AWS, Azure, or Google Cloud. Its runners execute the build and deployment jobs, then authenticate separately to AWS account dev, Azure subscription dev, and Google Cloud project orders-dev. A runner becomes part of a provider boundary only when it is self-hosted there. Its location changes network exposure and available identity mechanisms, but it does not remove the need for narrowly scoped provider authorization.
We can now trace which components cross each provider boundary.
A central pipeline reduces duplication only when its controls are consistently applied. Credential sprawl occurs when many jobs, repositories, or provider environments retain separate long-lived credentials with broad access. A leaked deployment credential can outlive the job that needed it, and a shared credential makes audit records unable to distinguish one pipeline run from another. Per-run, short-lived credentials limit both the usable lifetime and the affected deployment lane.
Scan controls can also drift. A vulnerability scan with one failure threshold in an AWS path and a different threshold in an Azure or Google Cloud path does not represent one security decision, even if every path uses the same scanner. The pipeline must record the evaluated artifact, rule set, result, and gate outcome. A successful job log proves that the job reported success during its recorded time window; by itself, it does not prove that all provider-side resources now match the intended state.
Cross-cloud copying adds another boundary. An image copied between registries can be replaced, incompletely copied, or promoted under a familiar tag. Tags identify a mutable reference, while a digest identifies the specific image content. The reusable rule is to authorize each provider action independently and carry evidence of the exact artifact across every handoff.
The running workload is orders-api, a service that listens on port 8080. Application source resides in orders-api-repo, while infrastructure declarations reside in orders-infra-repo. A build produces the fictional container image orders-api:1.0; infrastructure changes are evaluated as the Terraform stack orders-infra. Keeping source and infrastructure repositories distinct lets later controls assign different review, execution, and deployment permissions to each change type.
The image is promoted to aws-ecr/orders-api, azure-acr/ordersapi, and gcp-ar/orders-api, then deployed by provider-specific API actions into their named development boundaries. Promotion means copying the same verified image digest to each registry, not rebuilding from source for each cloud. Rebuilding would create separate artifacts whose contents and evidence could diverge despite sharing the orders-api:1.0 tag.
We can inspect the artifact and infrastructure paths that this workload makes explicit.