Vulnerabilities in cloud and containers

Why this matters

CS0-004 raised cloud content deliberately, and vulnerability management is where the change bites hardest. The traditional model — find a host, assess it, patch it, rescan — breaks against infrastructure that is rebuilt from a template several times a day and where the most damaging findings are settings rather than software.

The analytical skills transfer. The unit of work does not: you stop remediating machines and start remediating the definitions that produce them.

The lesson

Image scanning and the base-image problem

A container image is a stack of layers: a base image, then whatever was added. Everything inherits from the base, which means a vulnerability there propagates into every image built on it, and from there into every running container.

The consequence is leverage in both directions. One outdated base image can account for thousands of findings across hundreds of workloads; one base image update fixes them all. This is the clearest case of the root-cause grouping from lesson 20 — counting the findings gives a terrifying number, counting the fixes gives a manageable one.

What to scan for in an image:

• OS packages in the base layer.
• Application dependencies installed on top.
• Secrets committed into layers. A credential added and deleted in a later layer is still in the image, because layers are additive and the earlier one persists.
• Configuration: running as root, unnecessary setuid binaries, package managers and shells left in a production image.
• Provenance: where the base came from, and whether it is a tag you control.

Practices that matter:

• Pin by digest, not tag. latest and even 3.19 are mutable — the same tag can point at different content next week, so your scan result describes an image you may no longer be running.
• Use minimal bases where possible. Distroless and scratch images have less to be vulnerable, and no shell for an attacker to use.
• Rebuild regularly rather than patching running containers. A container patched in place is reverted by the next deployment, and you will find the same finding again — the recurring-finding pattern from lesson 20.

Registry, build-time and runtime findings

The same vulnerability means different things depending on where you found it, and the exam does test this distinction.

Build-time — scanning in the pipeline as the image is created. Cheapest to fix, because nothing is deployed and the developer is still working on it. This is where a policy gate belongs: fail the build on a critical finding.

Registry — scanning stored images. Catches images built before the gate existed and images that became vulnerable after they were built, because a new CVE was published against something already inside. Registry scanning is continuous re-evaluation of static content, and it is the reason an image that passed last month can fail today with nothing having changed.

Runtime — scanning what is actually running. This is the one that reflects reality, and it answers the question the others cannot: is this vulnerable image actually deployed anywhere, and where?

The prioritisation follows directly, and it is the useful part:

• A critical in an image in the registry but deployed nowhere is low urgency.
• The same critical running in production and internet-facing is urgent.
• A critical in an image used as a base by forty other images is a leverage point worth fixing before anything downstream.

Findings without deployment context produce the classic cloud failure — a backlog of thousands of criticals, most of which are not running anywhere, which teaches everyone to ignore the backlog.

Misconfiguration as the dominant cloud finding

The single most important idea in this lesson. In cloud environments, most incidents come from configuration, not from unpatched software.

The recurring categories:

• Storage exposed publicly: buckets and containers readable by anyone.
• Over-permissive identity: wildcard permissions, roles that can escalate themselves, long-lived access keys, users with privileges nobody reviewed.
• Network exposure: management ports open to the internet, security groups allowing everything from everywhere, databases with public endpoints.
• Encryption not enabled at rest or in transit, where the option existed and was not taken.
• Logging disabled, which is both a finding and the reason you will not be able to investigate the incident it enables.
• No MFA on privileged accounts, especially root or organisation owners.
• Public snapshots and images, which is how databases leak without anyone touching the database.

None of these has a CVE. None is found by a network vulnerability scanner. They are discovered by reading the configuration through the provider's API — posture management, in vendor terms — and they are typically both the highest impact and the cheapest to fix, which makes them the best return available in this whole domain.

Benchmarks give you a defensible baseline to measure against, and the practical approach is to assess continuously rather than periodically, because a misconfiguration introduced at 10am should not wait for a monthly scan.

Ephemeral workloads and reporting against them

Lesson 18 raised this for inventory; here it determines whether your numbers mean anything.

The problems, concretely:

• A finding on a container that no longer exists cannot be remediated and should not sit in a backlog implying it can.
• "Remediated" is ambiguous. Did someone fix the image, or did the container simply get replaced by an identical vulnerable one?
• Counts fluctuate with scale, not with security posture. Autoscaling doubles the workload count and doubles your findings, and nothing got worse.
• Mean time to remediate is distorted, because containers are replaced in minutes for reasons unrelated to security.

The fix is to change the unit of measurement:

• Report against images and templates, not instances. "Three images carry this critical" is stable and actionable; "412 containers are vulnerable" is noise that changes hourly.
• Track remediation at the source: the Dockerfile, the base image, the infrastructure-as-code template.
• Use deployment counts as an impact multiplier, not as the finding count.
• Measure age from first detection in the image, not from the container's birth.

Shared responsibility, concretely

Everyone can recite that responsibility is shared. The exam wants the specifics, because the boundary moves by service model.

• Infrastructure as a service — the provider secures the hardware, hypervisor and physical facility. You own the guest operating system, patching, configuration, network rules, identity and data. Closest to traditional, and most of Domain 2 applies unchanged.
• Platform as a service — the provider owns the operating system and runtime patching. You own your code, its dependencies, the service configuration, identity and data. Your vulnerability management shifts to application dependencies and configuration.
• Software as a service — the provider owns essentially the whole stack. You own configuration, identity, access and data — and this is where most SaaS incidents come from, not from provider vulnerabilities.
• Serverless — the provider owns the runtime; you own the function code, its dependencies, its permissions, and its triggers.

Two things are always yours, at every model, and they are worth memorising as a single sentence: identity and data. Who can access it, and what happens to it. No provider configuration will save an over-permissioned role or a publicly shared dataset.

The practical failure the model exists to prevent: assuming the provider handles something they do not. A managed database service patches the engine and does not stop you exposing it to the internet with a weak password. The provider's responsibility ends precisely where your configuration begins, and your vulnerability programme has to cover everything on your side of that line — including the parts that have no CVE attached.

Topics this lesson owns

• [x] Image scanning and the base-image problem
• [x] Registry, build-time and runtime findings
• [x] Misconfiguration as the dominant cloud finding
• [x] Ephemeral workloads and reporting against them
• [x] Shared responsibility, concretely