Vulnerability Propagation for Container Posture Visibility

This topic describes how to establish a container vulnerability posture for your container images hosted on a public or private registry without a runtime scanner. Using vulnerability propagation, vulnerabilities detected in images are mapped to the running containers instantiated from those images.

This topic focuses on posture visibility. It does not replace runtime protection, drift detection, or behavioral monitoring.

Use Case

• No runtime scanner deployed
• Container images are hosted in a public or private registry
• Containers run across Kubernetes, Docker, or other container runtimes
• The goal is to understand risk exposure for running workloads

Outcome

• Posture derived from image findings
• Image vulnerabilities are discovered with image scanning
• Findings are propagated to the corresponding running containers
• Dashboards and reports show container-level risk posture

Pre-requisites

• Container Image Registry
  For example, ECR, ACR, GCR, Harbor, Artifactory, or DockerHub
• Image identifier strategy - tag and/or digest
• Inventory source for running containers
  For example, Kubernetes API, runtime inventory, CMDB
• Qualys Container Security access and permissions

How to view vulnerability details of a container without a runtime scanner?

In many environments, container instances are continuously created from prebuilt images stored in a registry. When runtime scanning is unavailable, a practical approach is to use image vulnerability results as the authoritative source of truth and map them to container instances that reference the same image identity.

Implementation Steps

1. Establish image identity (tag vs digest)
   Standardize how images are referenced across build, registry, and runtime.
   - Prefer immutable identifiers (digests) where possible.
   - If tags are used, define a promotion process (For example, app:1.2.3 → app:prod) and ensure runtime inventory captures the resolved digest.
2. Scan images on a defined cadence
   Configure image scanning for the registry and ensure coverage for base images and application images.
   Capture vulnerability findings (CVEs, affected packages, and severity) and keep the results up to date.
3. Collect running workload inventory
   Enumerate running containers (Kubernetes pods/containers, Docker containers, or other runtime tasks), including: image name, tag, digest, namespace/cluster, and workload metadata (labels, owner, environment).
4. Propagate vulnerabilities from images to containers
   Map running containers to their source images and associate each container instance with the image’s vulnerability set. The resulting container posture is derived from image findings and reflects risk exposure for what is currently running.
5. Report posture and operationalize remediation
   Use container posture views to prioritize remediation by severity and exploitability, then remediate via rebuild/redeploy: patch base images, bump dependencies, rebuild images, and roll out new workloads.

Validation Checklist

You can verify successful vulnerability propagation in your container images using the following points.

• Initial Validation
  At least one known image with a known CVE is scanned successfully.
  This confirms that Vulnerability propagation has worked correctly, and it displays vulnerability details.
• Inventory Correlation
  A workload running that image appears in inventory with the image tag or digest.
  This ensures the vulnerable image is:
  - Actually deployed
  - Visible in your system inventory
• Posture Validation
  Container posture reflects the image vulnerabilities (severity counts match).
  This validates consistency between:
  - Image scan results
  - Runtime security posture/dashboard
• Remediation Step 
  ??How can this step be a verification step??
  Rebuild the image with patched dependency and rescan.
  Apply the fix to verify the vulnerability is resolved.
• Deployment Validation
  Redeploy workload and confirm posture improves.
  This ensures:
  - Fixed image is actually deployed
  - Vulnerability counts decrease
• Operationalization
  Document cadence and ownership for ongoing operations. 
  Make the process repeatable, owned, and continuous
  See Operational Considerations.

Operational Considerations

• Freshness: posture accuracy depends on scan cadence and runtime inventory frequency.
• Identity mapping: digests reduce ambiguity; tags may require additional resolution logic.
• Ephemeral containers: short-lived workloads may appear/disappear between inventory polls.
• Multi-arch images: ensure findings align to the architecture actually running.

Limitations (What this does not cover)

• Runtime-only issues (in-memory injections, live drift, malicious processes).
• Configuration risk outside the image (RBAC, network policies, secrets exposure).
• New vulnerabilities discovered after the last scan until rescanned.