How to locate vulnerable packages detected by Defender for Cloud that cannot be found in the source repository or UBI package list

12G-4164 185 Reputation points
2026-05-28T01:38:43.25+00:00

Note: This message was written with AI assistance.

We are using Microsoft Defender for Cloud to scan container images for vulnerabilities. Our container image is based on RHEL UBI and contains a Java WAR file.

We tried to identify the detected vulnerable packages by checking:

The source repository contents (WAR file contents)

However, some packages could not be found in either.

Is there a way to view the file path or layer information of detected packages in Defender for Cloud? Also, are there any best practices for identifying the current version and location of packages in a container image in order to update them for vulnerability remediation?

Microsoft Security | Microsoft Defender | Microsoft Defender for Cloud
0 comments
Answer accepted by question author
Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator
2026-05-28T03:06:07.3033333+00:00

Hey there! It sounds like you’re running Defender for Cloud’s agentless container scan on a RHEL UBI–based image (with a Java WAR inside) and you’re seeing CVEs for packages you can’t find in your WAR or in the UBI repo itself. Unfortunately Defender for Cloud’s portal UI doesn’t yet show you the exact file path or layer ID where it discovered each vulnerable package. Here’s how you can still track them down and then remediate:

  1. Use “View details” on the finding in Defender for Cloud
    • In the portal, go to Microsoft Defender for Cloud -> Recommendations -> “Azure registry container images should have vulnerabilities resolved” (or a similar Containers plan recommendation).
    • Find your image in the list and click the link on the vulnerability. You’ll get package name, detected version, fixed version and remediation guidance.
  2. Query the SBOM/installed-software via Cloud Security Explorer
    • In the Azure portal, go to Microsoft Defender for Cloud -> Cloud Security Explorer.
    • Filter Resource Type to “Containers” -> search for your registry/image.
    • Click View details -> Insights -> Has installed software. This pulls in the discovered SBOM and shows every package name + version. You can then match the CVE’s package & version back to where it lives in your image.
  3. Export raw scan results (JSON)
    • If you need more fields (like layer or diff metadata), export the assessment via: • A Defender for Cloud workbook that references the VulnerabilityAssessment findings • The Defender for Cloud REST API (see the “Exporting Azure Container Registry Vulnerability Assessment in Microsoft Defender for Cloud” guide)
    • The raw payload sometimes includes additional metadata you can parse.
  4. Generate your own SBOM / inspect layers locally
    • Tools like Syft, Trivy or dive let you inspect every layer and map files/packages to layer digests.
    • Run e.g. syft your-image:tag -o json to get a full bill of materials, including the file path inside the image.

Best practices for remediation

  • Bake SBOM generation into your CI/CD so you always know exactly which packages (and versions) were added by each Dockerfile layer.
  • Keep your UBI base image up-to-date (e.g. pull the latest UBI8 minimal).
  • For your WAR, use a dependency‐updater plugin (e.g. Maven versions plugin or Dependabot) to ensure libraries inside the WAR are current.
  • After updating your Dockerfile or rebuilding with new base images/deps, repush and wait ~24 hrs for the new scan cycle.

Reference Docs

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-28T01:39:09.13+00:00

    Defender for Cloud’s container vulnerability assessment now exposes detailed package metadata per finding, including the package path, type, installed version, and fixed version. This information can be used to locate packages that don’t appear in the source repository or base UBI package list.

    To view this information for a running AKS workload:

    1. Sign in to the Azure portal.
    2. Go to Kubernetes services → Clusters and select the relevant AKS cluster.
    3. Select Microsoft Defender for Cloud.
    4. Open the Vulnerabilities tab and select the relevant component (image/node pool).
    5. In the details pane for a specific vulnerability, review:
      • Package name and package type (OS vs language-specific).
      • Path (file path within the container filesystem where the package was found).
      • Installed version and fixed version.

    If expected vulnerabilities or packages don’t appear, verify that:

    • The image and package type are supported by Defender for Containers (for example, OS vs language-specific packages on Linux).
    • The environment is supported according to the Defender for Containers support matrix. For example, container images from nodes using AKS Ephemeral OS disks or Windows nodes can’t be scanned, and autoscale clusters might show partial results if nodes are down at scan time.

    Defender’s scanner works by pulling the image and running it in an isolated sandbox, then extracting a list of known vulnerabilities from OS and language-specific packages. The results are filtered and classified, and only images with issues generate recommendations. This means the package list in Defender might include:

    • OS packages from the UBI base plus any additional packages installed in later layers.
    • Language-specific packages (for example, Java dependencies inside the WAR or other application libraries) that won’t appear in the UBI RPM list.

    Best practices for locating and updating packages in the image for remediation:

    1. Use Defender’s vulnerability details to identify:
      • The exact package name and type.
      • The installed version and fixed version.
      • The path, which indicates whether the package is part of the base OS, an application dependency (for example, inside /opt, /app, or within the WAR), or another layer.
    2. Compare the path and package type with the Dockerfile or build pipeline:
      • OS packages typically map to yum/dnf installs in the Dockerfile.
      • Language-specific packages typically map to build-time dependency management (for example, Maven/Gradle for Java) and may be embedded in the WAR.
    3. Update the package:
      • For OS packages, rebuild the image with updated base UBI or explicit package updates to the fixed version.
      • For language-specific packages, update the dependency in the build configuration (for example, pom.xml), rebuild the WAR, and then rebuild the container image.
    4. Re-scan the updated image with Defender for Cloud to confirm that the vulnerability is resolved.

    If a package still cannot be mapped to either the source repository or the UBI list, use the path and package type from Defender’s detailed package information to inspect the image layers and filesystem directly (for example, by running the image locally and inspecting the path) to determine where it is introduced.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.