In October 2022, Microsoft folded Azure Security Center's container protections into a single, generally available product: Defender for Containers. For teams running Azure Kubernetes Service (AKS) clusters and pushing images through Azure Container Registry (ACR), that consolidation mattered — it meant one control plane for cluster hardening, runtime threat detection, and image vulnerability scanning instead of three disconnected tools. Defender for Containers now inspects millions of container images a day across Azure, watches Kubernetes API server activity for anomalous behavior, and applies Kubernetes data plane hardening recommendations pulled from CIS benchmarks. But "one product" doesn't mean "one job done." Its agentless scanning has blind spots, its alert taxonomy takes tuning, and its findings still need to land somewhere engineers actually act on them. Here's what Defender for Containers actually covers on AKS and ACR, what it misses, and where a supply chain security layer like Safeguard picks up the rest.
What Is Defender for Containers?
Defender for Containers is Microsoft's Defender for Cloud plan that bundles four capabilities: Kubernetes cluster hardening, Kubernetes data plane hardening, vulnerability assessment for container images, and runtime threat protection. It's sold per-plan under Defender for Cloud AKS coverage, billed per vCore-hour (roughly $7 per vCore per month as of Microsoft's current pricing tier, though Azure has iterated on this rate). Enabling it on a subscription auto-provisions the Defender sensor as a DaemonSet on AKS nodes, which is what gives Microsoft visibility into process activity, network connections, and file system changes inside running pods. Without that sensor, you get posture recommendations but not runtime alerts — a distinction teams frequently miss when they enable "Defender for Cloud" and assume containers are fully covered. The product only reaches its stated capability once the AKS extension, the ACR scanning integration, and Azure Policy add-on are all active together.
How Does Defender for Cloud Protect AKS Clusters at Runtime?
It protects AKS clusters by streaming control-plane and node-level telemetry into Microsoft's threat intelligence graph and flagging deviations in near real time. The Defender sensor DaemonSet monitors kubelet and container runtime events, while Azure's managed Kubernetes control plane logs (audit logs, API server logs) feed a separate detection layer that doesn't require the sensor at all. Together they generate alerts like "Digital currency mining container detected," "Executable running from a shared memory directory," or "Anomalous pod deployed from a suspicious image registry" — alerts documented in Microsoft's own reference list, which now includes more than 60 distinct AKS-specific detections. A concrete example: if an attacker exploits a misconfigured ingress to get shell access inside a pod and then pulls down a cryptominer binary from an external host, Defender for Containers correlates the outbound connection, the unexpected process spawn, and the write to a normally-empty tmpfs path into a single high-severity alert within minutes, rather than leaving a SOC analyst to piece it together from raw Kubernetes audit logs.
How Does Defender Vulnerability Assessment Work for ACR?
Defender vulnerability assessment for ACR scans every image pushed to a registry and rescans previously scanned images daily as new CVE data lands, using a Trivy-based (formerly Qualys-based) scanning engine that Microsoft operates as an agentless, registry-integrated service. When you push an image tagged myapp:1.4.2 to ACR, the scan typically completes within minutes and surfaces results in Defender for Cloud's recommendations blade, tagged with CVE IDs, CVSS scores, and — critically — whether a patched package version is available. As of Microsoft's 2023 engine migration, the assessment also flags OS-level and language-specific package vulnerabilities (npm, pip, Maven, NuGet) rather than just OS packages, which closes a gap that made earlier scans miss a large share of application-layer CVEs in practice. The catch: scanning is triggered by registry activity. Images sitting untouched in ACR for weeks don't get a fresh look until something re-triggers the pipeline, so a registry with a long tail of stale, rarely-redeployed images can quietly accumulate unpatched CVEs that never resurface in the dashboard.
What Container Security Posture Signals Does Azure Surface?
Azure surfaces container security posture through the Cloud Security Graph and attack path analysis inside Defender for Cloud, which maps how a vulnerable image, an overprivileged Kubernetes role, and internet-exposed ingress combine into an exploitable path — not just a flat list of findings. Posture recommendations cover things like "AKS clusters should have Azure Policy add-on installed," "Container registries should have vulnerability findings resolved," and "Privileged containers should be avoided," each mapped to CIS Kubernetes Benchmark controls and scored against your Microsoft Secure Score. This is where container security posture Azure tooling earns its keep for compliance-driven teams: auditors can point to a Secure Score trend line and a CIS mapping instead of a spreadsheet. The limitation is granularity — Secure Score aggregates posture across an entire subscription, so a single critical attack path (say, a public-facing pod with a root-capable container and a Kubernetes secret mounted as an environment variable) can get buried under dozens of lower-severity, unrelated recommendations unless a team actively triages by attack path rather than by score.
What Are the Coverage Gaps Teams Should Plan Around?
The biggest gap is that Defender for Containers assesses images in ACR and running workloads in AKS, but it doesn't govern what happens before an image reaches the registry — the CI pipeline, the base image selection, the dependency pinning, or the developer's local build. A CVE introduced in a base image at build time isn't caught until it's already pushed, scanned, and potentially deployed, which means the feedback loop back to the engineer who wrote the Dockerfile is slow and indirect. Second, agentless scanning means SBOM-level dependency data is coarser than what a dedicated software composition analysis tool produces, so teams doing SOC 2 or FedRAMP evidence collection often find Defender's output insufficient on its own for audit-grade provenance claims. Third, cost and alert volume scale with cluster size — subscriptions with dozens of AKS clusters can see thousands of low-priority recommendations that need suppression rules and workflow automation (via Azure Logic Apps or Sentinel) to stay actionable rather than becoming noise engineers learn to ignore.
How Safeguard Helps
Safeguard closes the gap between what Defender for Containers sees after deployment and what needs to be verified before an image ever reaches ACR. Instead of waiting for a registry scan to catch a vulnerable dependency, Safeguard enforces provenance and vulnerability checks at build time — validating base images, dependency manifests, and SBOMs against policy before a docker push succeeds, so the CVE that Defender would flag days later never lands in the registry in the first place. For teams that already lean on Defender vulnerability assessment ACR results for compliance evidence, Safeguard adds the build-time attestation and SBOM lineage that auditors ask for but agentless registry scanning can't fully reconstruct — who built the image, from what commit, with what dependencies, signed and verifiable. And where Defender's attack-path analysis surfaces a risky combination inside a running AKS cluster, Safeguard's policy engine can trace it back to the exact pipeline and pull request that introduced it, turning a Secure Score line item into an actionable, assignable fix. Used together, Defender for Containers watches runtime and registry state while Safeguard secures everything upstream of it — giving teams a continuous chain of custody from source code to running pod instead of two disconnected snapshots of risk.