Skip to main content
emnode
Compliance High severity MCSB DS-6

Microsoft Defender for Cloud · Azure Kubernetes Service

Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)" check?

Flags AKS workloads whose running container images carry known CVEs that Microsoft Defender Vulnerability Management has found and that have a published fix. Defender for Cloud builds an inventory of the images each pod is actually running, correlates it with MDVM scan data, and surfaces every image with an unresolved, fixable finding. The scope is the live runtime: it looks at what is executing in your clusters, not what merely sits in a registry, so the companion 'Container registry images' recommendation covers images at rest. The policy is audit-only (AuditIfNotExists); it reports the gap and does not block deployments or patch anything. It only evaluates images that Defender can scan, so it does not cover OS-level issues on the AKS nodes themselves, application logic flaws, or vulnerabilities with no vendor fix available.

Why does "Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)" matter?

A vulnerable image running in production is an exploitable image. Unlike a dormant registry artefact, a CVE in a running container is reachable by traffic right now, and container base images accumulate flaws quickly: an image built a few months ago routinely ships dozens of fixable CVEs in its OS packages and language runtimes. Defender ranks these by real exploitability and exposure, so a High finding usually means there is a known path to remote code execution or privilege escalation against a workload an attacker can already reach. The business consequence is a breached pod becoming a foothold for lateral movement across the cluster, data exfiltration from mounted secrets and volumes, or cryptomining on your compute. Resolving the findings shrinks the attack surface to the images you have deliberately accepted.

How do I fix "Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)"?

  1. Enable the scanning that powers this recommendation. Turn on the Defender for Containers plan (or Defender CSPM) on the subscription with both registry access and Kubernetes API access switched on, so Defender can map scanned images to running pods: az security pricing create --name Containers --tier Standard. Without it the recommendation has no data to evaluate.
  2. Fix the image, not the cluster. For each flagged image, rebuild from a patched base image or bump the vulnerable OS and language packages, then push the new tag to Azure Container Registry. Roll it out by updating the deployment to the new digest, for example az aks command invoke or your pipeline running kubectl set image deployment/<name> <container>=<acr>.azurecr.io/<repo>@sha256:<digest>, so every replica restarts on the fixed image.
  3. Stop the regression at the source. Wire a registry scan gate into CI so images with fixable High or Critical CVEs fail the build before they reach ACR, and assign the built-in audit policy across your subscriptions for ongoing visibility. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)'].name" -o tsv); az policy assignment create --name running-img-vulns --policy "$pid" --scope /subscriptions/<sub-id>.

Remediation script · bash

# Step 1: close coverage gaps. Enable the scanning plans on the subscription.
SUB="/subscriptions/00000000-0000-0000-0000-000000000000"

az security pricing create --name VirtualMachines --tier Standard
az security pricing create --name SqlServers       --tier Standard
az security pricing create --name Containers       --tier Standard

# Step 2: list the machines that still have no assessment solution attached.
az security assessment list \
  --query "[?metadata.displayName=='Machines should have a vulnerability assessment solution' && status.code=='Unhealthy'].resourceDetails.id" \
  -o tsv

# Step 3: ratchet it shut. Enforce that the plans stay enabled estate-wide,
# so no new subscription can become an unscanned blind spot. Assign the
# built-in initiative 'Configure Microsoft Defender for Cloud plans'
# (DeployIfNotExists), which turns the Servers, SQL and Containers plans
# back on wherever they are missing.
az policy assignment create \
  --name enable-defender-plans \
  --display-name "Configure Microsoft Defender for Cloud plans" \
  --policy-set-definition f08c57cd-dbd6-49a4-a85e-9ae77ac959b0 \
  --scope "$SUB" \
  --mi-system-assigned --location uksouth

Full walkthrough (console steps, edge cases and verification) in the lesson Run vulnerability assessment across Azure.

Is "Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)" a false positive?

A High finding can be one you have correctly chosen to accept: the vulnerable component is present but not reachable in your deployment, the vendor will not issue a fix, or a compensating control already neutralises it. That is a legitimate exception, not a reason to leave the recommendation noisy. Document the decision and suppress just that finding by creating an exemption on the resource (or a disable rule scoped by CVE or image digest) with a written justification, so the secure score reflects reality while the suppression stays auditable and reviewable later.