Multi-cloud is no longer a strategy reserved for Fortune 500 companies. Organizations of all sizes run workloads across two or more cloud providers -- sometimes by design, sometimes by acquisition, sometimes because different teams made different choices before anyone thought to standardize.
From a supply chain security perspective, multi-cloud environments multiply nearly every risk vector. Each cloud provider has its own container registry, its own secrets management service, its own IAM model, and its own set of managed services with their own dependency chains. Managing security posture across all of them requires a deliberate, unified approach.
The Supply Chain Angle
When people think about Cloud Security Posture Management (CSPM), they typically think about misconfigured S3 buckets, overly permissive IAM roles, and unencrypted databases. These are real problems, but they miss the supply chain dimension entirely.
Your cloud infrastructure is itself a supply chain. The base AMIs and VM images you deploy are dependencies. The container images you pull from ECR, ACR, and GCR are dependencies. The Terraform modules you source from public registries are dependencies. The Lambda layers, Azure Functions extensions, and Cloud Functions libraries are dependencies. Each of these can be compromised, outdated, or misconfigured.
Multi-cloud makes this worse because you are managing parallel supply chains. Your AWS container images might come from ECR with vulnerability scanning enabled, while your Azure container images sit in ACR with no scanning configured. Your GCP Terraform modules might be pinned to specific versions, while your AWS modules use latest. Consistency is the first casualty of multi-cloud.
Shared Responsibility Model Across Providers
Each cloud provider defines a shared responsibility model, but the boundaries differ in subtle ways.
Container orchestration: AWS EKS, Azure AKS, and GCP GKE all manage the Kubernetes control plane, but their defaults for node security, network policies, and pod security standards vary. A security configuration that is secure on GKE might not be secure on EKS because of different default settings for node IAM roles.
Serverless runtimes: AWS Lambda, Azure Functions, and Google Cloud Functions each have different execution environments, different runtime support matrices, and different patching schedules. A vulnerability in the Node.js 18 runtime might be patched on AWS first, leaving your Azure Functions exposed for days or weeks longer.
Managed databases: The underlying engines might be the same (PostgreSQL, MySQL), but the cloud provider's patching cadence, default configurations, and audit logging capabilities differ. Your security posture for the "same" database can vary dramatically across providers.
Infrastructure as Code Supply Chain
Terraform, Pulumi, and CloudFormation templates are supply chain artifacts. They define your infrastructure, and they have their own dependencies.
Terraform modules from public registries are the npm packages of infrastructure. They are community-maintained, variably tested, and can introduce security misconfigurations or malicious resource definitions. In a multi-cloud environment, you are consuming modules from multiple ecosystems, each with different levels of community oversight.
Provider plugins are another dependency. Terraform's AWS provider, Azure provider, and GCP provider are all separate binaries downloaded during terraform init. Pin these to specific versions in your .terraform.lock.hcl file. An unpinned provider can introduce breaking changes or, in a supply chain attack scenario, malicious behavior.
State files contain sensitive information (resource IDs, sometimes passwords) and are a high-value target. In a multi-cloud setup, you might have state files in S3, Azure Blob Storage, and GCS. Ensure consistent encryption, access controls, and audit logging across all backends.
Container Image Security Across Registries
Most organizations use each cloud provider's native container registry: ECR for AWS, ACR for Azure, GCR/Artifact Registry for GCP. This creates parallel image supply chains that need parallel security controls.
Vulnerability Scanning
- ECR offers built-in scanning via Amazon Inspector (enhanced scanning) or Clair-based basic scanning
- ACR integrates with Microsoft Defender for Containers
- Artifact Registry integrates with Container Analysis (based on Grafeas)
These scanning tools use different vulnerability databases, different detection engines, and produce different results for the same image. An image that passes scanning on ECR might fail on ACR, or vice versa. For consistent security posture, consider running a third-party scanner (Trivy, Grype, Snyk Container) across all registries rather than relying on each provider's native tooling.
Image Signing and Verification
Sigstore/cosign works across all cloud providers, but the key management differs. You might use AWS KMS for signing images pushed to ECR, Azure Key Vault for ACR, and GCP KMS for Artifact Registry. Maintain a unified signing policy -- the same trust anchors, the same signature verification requirements -- even if the key management backends differ.
Base Image Standardization
If your AWS workloads use amazonlinux:2023 base images and your Azure workloads use mcr.microsoft.com/cbl-mariner, you have two different OS dependency trees to patch, monitor, and maintain SBOMs for. Standardizing on a single base image (or a small set) across clouds reduces this complexity. Distroless images or Chainguard images work across all providers and minimize the OS-level dependency surface.
IAM and Secrets Management
In a multi-cloud environment, secrets sprawl is inevitable. API keys for Cloud A end up stored in Cloud B's secrets manager. Service accounts for inter-cloud communication proliferate. Cross-cloud IAM trust relationships create complex attack paths.
Secrets rotation: AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager all support automatic rotation, but the configuration, rotation functions, and supported secret types differ. An unrotated secret in one cloud can compromise workloads in another.
Workload identity: Each cloud has its own workload identity mechanism (AWS IAM Roles for Service Accounts, Azure Workload Identity, GCP Workload Identity Federation). Avoid using long-lived credentials for cross-cloud access. Instead, use OIDC federation so that a workload in Cloud A can assume a role in Cloud B without storing static credentials.
Least privilege auditing: Tools like AWS IAM Access Analyzer, Azure AD Privileged Identity Management, and GCP IAM Recommender analyze IAM permissions within their own cloud. For cross-cloud visibility, you need a CSPM tool that aggregates IAM analysis across all providers.
Unified Policy Enforcement
Writing security policies once and enforcing them across three clouds is the goal. Reality is harder.
Open Policy Agent (OPA) and its Kubernetes-native variant Gatekeeper can enforce policies on Kubernetes manifests regardless of cloud provider. Write your pod security policies, network policies, and resource limits as Rego rules and apply them to EKS, AKS, and GKE uniformly.
Cloud-specific policy tools (AWS Config Rules, Azure Policy, GCP Organization Policies) are powerful within their own ecosystem but do not translate across providers. You end up maintaining three sets of policies that express the same intent in different languages.
Policy as code frameworks like Checkov, tfsec, and KICS can scan Terraform, CloudFormation, and ARM templates for misconfigurations. Run these in CI before infrastructure is deployed. They work across cloud providers because they analyze the IaC templates, not the live infrastructure.
Monitoring and Incident Response
When a supply chain incident occurs in a multi-cloud environment, you need correlated visibility across all providers. A compromised container image might be deployed on EKS and AKS simultaneously. A malicious Terraform module might have provisioned resources in both AWS and GCP.
Centralized logging: Ship CloudTrail, Azure Activity Log, and GCP Audit Logs to a single SIEM or log aggregation platform. Without centralized logs, correlating an attack across providers is nearly impossible.
Unified alerting: Set up alerts for supply chain-relevant events across all clouds: new container images deployed, IAM policy changes, secrets accessed by unexpected principals, infrastructure changes outside of CI/CD pipelines.
Incident response playbooks: Write playbooks that account for multi-cloud blast radius. If a container image is compromised, the playbook should include steps to check all registries, not just the one where the compromise was detected.
How Safeguard.sh Helps
Safeguard.sh provides unified supply chain visibility across multi-cloud environments. The platform ingests SBOMs from container images across ECR, ACR, and Artifact Registry, giving you a single view of your dependency landscape regardless of where workloads run. Vulnerability tracking spans all clouds, so you can see that the same vulnerable library exists in your AWS Lambda functions and your Azure Container Apps. Safeguard.sh normalizes security posture data across providers, letting you enforce consistent dependency policies and remediation SLAs without maintaining separate tooling for each cloud.