Cloud Supply Chain Security & Third-Party Risk Management

The Extended Cloud Supply Chain

In traditional IT, the software supply chain ended at the application binary. In cloud environments, the supply chain includes:

Component	Supply Chain Risk	Example Incident
OS base images	Unpatched CVEs, backdoored images	Multiple malicious Docker Hub images with crypto miners
Third-party libraries	Dependency confusion, typosquatting	event-stream npm package backdoor (2018)
Infrastructure-as-Code modules	Malicious Terraform module execution	Attackers publishing malicious modules to Terraform Registry
CI/CD pipeline integrations	GitHub Actions, Jenkins plugins with malicious behaviour	Codecov bash uploader tampered (2021)
SaaS integrations	OAuth tokens with excessive scope	Third-party app stores data beyond stated purpose
Cloud provider services	Provider's own software supply chain	SolarWinds SUNBURST (2020): software update mechanism

The SolarWinds Attack: A Cloud Supply Chain Case Study

In December 2020, it was discovered that the SolarWinds Orion network monitoring platform — used by 18,000+ organisations including US government agencies — had been compromised during the software build process. A malicious DLL (SUNBURST) was inserted into the legitimate build pipeline and signed with SolarWinds' code signing certificate.

Cloud-specific impacts:

• Attackers used SUNBURST to steal SAML token signing certificates from Microsoft Active Directory Federation Services
• These certificates allowed forging SAML assertions for any Azure AD user without their credentials
• The attacker could authenticate to Microsoft 365 as any user in the organisation without knowing their password
• The attack was detected months after initial compromise

Lesson for cloud security: Signing certificates — whether for code, SAML, or TLS — are crown jewels. Compromise of a signing certificate bypasses all authentication controls.

Container Image Supply Chain

Container images are layered filesystems. Most production container images start from a public base image (ubuntu:22.04, python:3.12, node:20-alpine). Any vulnerability in the base image is present in every image built from it.

Secure container image pipeline:

Developer commits code
      ↓
CI pipeline pulls base image
      ↓
Scan base image (Trivy / Grype) → Block on Critical/High CVEs
      ↓
Build application layer
      ↓
Scan final image
      ↓
Sign image (cosign / Notary v2)
      ↓
Push to private registry (ECR, ACR, GAR) with OCI signing
      ↓
Admission controller (OPA Gatekeeper / Kyverno) verifies signature before deploy
      ↓
Runtime monitoring (Falco) alerts on unexpected syscalls

Key principle: Never pull and run an image that has not been scanned and signed by your pipeline. The latest tag on Docker Hub is a high-risk tag — it changes silently.

Dependency Confusion and Typosquatting

In a dependency confusion attack, an attacker publishes a malicious package to a public registry (npm, PyPI) with the same name as an internal private package. Package managers that check public registries before private ones install the attacker's version.

Mitigation:

• For npm: use a .npmrc with @scope:registry=https://internal-registry and registry=https://registry.npmjs.org scoped to your namespace
• For pip: use --index-url pointing to your private repository; disable --extra-index-url
• For Terraform: pin module versions and use terraform_wrapper or a private module registry

Typosquatting (e.g., publishing requets instead of requests) exploits developer typos. Use pip-audit, npm audit, and Dependabot to catch known-bad packages.

CI/CD Pipeline Security

The CI/CD pipeline has root-equivalent access to your cloud environment. It can deploy code, modify infrastructure, and read secrets. This makes it a high-value target.

CI/CD Risk	Control
Secrets in environment variables	Use cloud-native secrets (AWS SSM, Vault); never store in CI config
Pipeline runs on shared runners	Use self-hosted runners for sensitive operations; harden the runner OS
PR triggers CI that accesses production	Gate production deploys on branch protection and manual approval
Third-party GitHub Actions with broad permissions	Pin Actions to SHA not tag; use permissions: read-all by default
OIDC not configured (long-lived access keys used)	Replace with OIDC; rotate any remaining keys every 90 days

Third-Party SaaS Integration Risk

Every SaaS application connected to your cloud environment via OAuth expands your attack surface. When an employee connects their Slack workspace to a third-party app that requests files:read and admin.users:read, that app can access all Slack files and user data.

Control approach:

• Maintain an approved SaaS integration list
• Require security review before approving new OAuth integrations
• Use CASB (Cloud Access Security Broker) to detect and control SaaS connections
• For critical SaaS (Salesforce, Workday, GitHub Enterprise), enforce SSO through corporate IdP — do not allow direct password login