Cloud & Supply-Chain Security

Moving to the cloud does not outsource your security — it splits it. Every major provider publishes a shared responsibility model drawing the line between what they secure and what you secure. The provider handles security of the cloud: physical data centers, hardware, the hypervisor, the core network. You handle security in the cloud: your data, your access controls, your configurations, and — depending on the service model — the operating system and application.

Where the line sits depends on the model:

The recurring disaster is misreading this line — assuming the provider "has security covered" when the exposed part was always yours. Note that in every model, your data, your identities, and your configuration remain your responsibility. That is exactly where most cloud breaches occur.

Ask incident responders what actually causes cloud breaches and you won't hear about exotic zero-days. You'll hear misconfiguration. Storage buckets set to public. Over-permissive IAM roles that grant far more than needed. Security groups left open to the entire internet. Logging switched off. Default credentials never changed. Industry analyses consistently attribute the large majority of cloud security failures to customer-side misconfiguration, not provider compromise.

Cloud IAM is the epicenter. In the cloud, identity is the perimeter (as we saw in Module 1) — and the temptation to attach broad, wildcard permissions "to make it work" is enormous. An over-privileged role attached to an internet-facing workload is a gift to any attacker who compromises it: they inherit everything that role can do.

Modern cloud runs on containers, so a specialist needs the mental model. A container packages an application with its dependencies into an isolated process that shares the host's kernel. Crucially, that's lighter but weaker isolation than a virtual machine — containers isolate processes, not the kernel, so a kernel escape breaks the boundary. Containers are built from images pulled from registries, which means you inherit whatever vulnerabilities and secrets those images carry.

Kubernetes (K8s) orchestrates containers at scale: it schedules pods (groups of containers) onto nodes, all coordinated by a control plane centered on the API server. It's powerful and correspondingly easy to misconfigure. Common failure modes:

• Vulnerable or unverified images pulled straight into production.
• Over-privileged pods (running as root, or with privileged containers) that ease a breakout.
• Exposed API servers, dashboards, or kubelets reachable from the internet.
• Secrets stored in plaintext manifests or environment variables.

The defenses mirror everything else: scan images, enforce least privilege with role-based access and pod security standards, segment the network, and keep the control plane off the public internet.

You do not ship only your code. A modern application is mostly other people's code — open-source libraries, their transitive dependencies, base images, build tools, and vendor updates. Every one of those is a path in. Supply-chain attacks target that trust.

Two incidents defined the modern era. In December 2020, the SolarWinds SUNBURST attack was disclosed: state-linked actors (attributed to Russia's SVR) had compromised SolarWinds' build pipeline and planted a backdoor in signed updates of its Orion product. Roughly 18,000 organizations downloaded the trojanized update, and a subset — including US government agencies — were further exploited. The malicious code arrived signed and trusted, straight through the update channel.

A year later, in December 2021, came Log4Shell — CVE-2021-44228, a critical remote-code-execution flaw (CVSS 10.0) in Apache Log4j, a logging library buried as a transitive dependency in a staggering share of Java software. Overnight, organizations discovered they were vulnerable through components they didn't know they used. And in 2021, researcher Alex Birsan demonstrated dependency confusion: publishing public packages with the same names as companies' private internal packages, tricking build systems into pulling the attacker's version.

If your risk is "I don't know what's in my software," the answer starts with an inventory. A Software Bill of Materials (SBOM) is a formal, machine-readable list of every component in an application — direct and transitive — in a standard format like SPDX or CycloneDX. When the next Log4Shell drops, an SBOM turns "we'll spend three weeks grep-ing every codebase" into a query. The push for SBOMs accelerated sharply after the US executive order on cybersecurity (EO 14028) in 2021 made them an expectation for federal software.

Inventory tells you what you have; signing and provenance tell you it's authentic. Projects like Sigstore (with its cosign tool) make it practical to cryptographically sign artifacts and verify them before deployment, so an unsigned or tampered image gets rejected. The SLSA framework (Supply-chain Levels for Software Artifacts) defines graduated levels of build integrity — proving an artifact really came from your build system and wasn't swapped en route, which is precisely the gap SolarWinds exploited.