---
sourceDocument: Australia Security Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/security-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# Runtime exposure visibility for container images

# Runtime exposure visibility for container images {#ariaid-title1}

Release version: Australia  
Updated October 26, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Runtime exposure visibility for container images

This feature enhances container vulnerability management by removing the previous 16-cluster limit on container vulnerable items, allowing ServiceNow customers to track vulnerabilities for container images deployed across unlimited clusters.
It leverages three chained Wiz integrations that identify active images, map their cluster locations, and create container vulnerable items automatically.
Show full answer Show less  

## Key Features

* **Chained Integrations:** Three integrations run sequentially and automatically:
  * **Wiz Container Grouped Vulnerability Integration:** Runs daily to collect image Source IDs and data, storing it in the Discovered Items \[Container Images\] table.
  * **Wiz Container Deployment Context Integration:** Triggered by the first integration, maps images to clusters, namespaces, and services, and creates missing vulnerable items for new deployments.
  * **Wiz Container Vulnerability Integration:** Creates container vulnerable items for each vulnerable image across all deployment contexts based on the mapping data.
* **Container Vulnerable Item Granularity:** Vulnerable items are created based on configured granularity keys such as Registry, Namespace, Cluster, and Service. This configuration controls how findings are grouped and is accessible under Configure VI granularity. Existing customers retain their current key configurations, while new customers should set keys before first data import.
* **Automatic De-duplication:** The integrations ensure no duplicate vulnerable items are created, maintaining accurate and up-to-date vulnerability records.
* **Deactivation Option:** Customers not using clusters as a condition for vulnerable item creation can deactivate the chained integrations by setting the system property `snvulwiz.deploymentcontextgatewrites` to false. This retains existing behavior with the Wiz Container Vulnerability Integration only.

## Practical Benefits for ServiceNow Customers

* Enables comprehensive visibility of container image vulnerabilities across any number of clusters, enhancing risk management for containerized environments.
* Automates the mapping and creation of container vulnerable items, reducing manual effort and improving accuracy.
* Supports flexible configuration of vulnerability granularity keys to align with organizational requirements.
* Provides an option to disable enhanced integrations if cluster-based vulnerability mapping is not needed, preserving existing workflows.  
Chained Wiz integrations create container vulnerable items for images deployed across unlimited clusters, removing the previous 16-cluster limitation.

With the addition of two new container vulnerability integrations that are included with the Vulnerability Response Integration with Wiz, container vulnerable items for active images with vulnerabilities are no longer limited to a maximum of 16 clusters. Container vulnerable items are created for images deployed on any number of clusters
without limitation. Three chained integrations work together to identify active images, map them to their cluster locations, and create container vulnerable items. The integrations are activated by default and run automatically
in sequence. Duplicate container vulnerable items for images aren't created, and the \[sn_vul_container_image_relationship_mapping\] and \[sn_vul_container_image_vulnerable_item\] tables are updated appropriately.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-2}

Navigate to AllWiz Vulnerability IntegrationIntegrations to view the records for the following integrations.

## Chained container vulnerability response integrations {#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-section-1}

The integrations are run automatically in the following order.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-3}

Wiz Container Grouped Vulnerability Integration
:   Runs daily to gather Source IDs and other data for active images and stores the data on the Discovered Items \[Container Images\] \[sn_vul_container_image\] table. Every docker image has a unique Source ID based on the
    repository it is stored in. This integration imports the Source ID and stores it in the Source IDs column on the Discovered Items \[Container Images- sn_vul_container_image\] table.

Wiz Container Deployment Context Integration
:   Triggered by the successful completion of the first integration. Creates a relationship between an image and where it is stored on the \[sn_vul_container_image_relationship_mapping\] table. This table maps the docker
    image to cluster, Namespace and Services at their specific repository level. This Integration will also create missing Vulnerable Items if any new deployment comes for any image.

Wiz Container Vulnerability Integration
:   Creates container vulnerable items for the vulnerable image based on any of the clusters/namespace/service it is deployed on using the data from sn_vul_container_image_relationship_mapping.

## Container vulnerable item creation with granularity keys {#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-section-2}

Container vulnerable items are created based on what you have configured for container image granularity keys. Each third-party container vulnerability scanner integration has its
own record on the Configure Image Vulnerability Keys \[sn_vul_container_image_vulnerability_keys\] table. By default without any additional keys configured, a finding is created by combining the image repository,
vulnerability, and image data that is imported by a scanner product.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-4}

For existing customers, container vulnerable items with the integration chain are created based on what you've already configured for the Registry, Namespace, Cluster, and Service
keys. To view the configuration page, navigate to AllContainer Vulnerability ResponseAdministrationConfigure VI granularity.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-6}

These keys aren't editable unless there is no container vulnerability data in the instance, or unless you're a new customer. If you have none of the keys selected on the page, container vulnerable items are created by the
Container Vulnerability Integration as existing behavior.

For new customers, configure key granularity before you make your first data import with the integrations.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-8}

See [Configuring container image granularity keys for Container Vulnerability Response](https://www.servicenow.com/docs/oIxOZaLvuiu6iXiiNqyGqw "You can configure the keys that generate Container Vulnerability Response findings (container vulnerable items) to help you determine how and when they are created from imported container vulnerability data.") for more information about key granularity.

## Deactivating the chained integrations {#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-section-3}

The image runtime exposure feature with the enhanced imports is available to all customers who have entitlements to Container Vulnerability Response. The integrations are installed automatically and are activated by default. If you don't want to use this integration chain because you aren't using clusters as a
condition to create container vulnerable items, set the sn_vul_wiz.deployment_context_gate_writes system property to false. This setting deactivates the Wiz Container Grouped Vulnerability and Wiz Container Deployment Context integrations so that container vulnerable item creation remains based on your existing settings with the Wiz Container Vulnerability Integration integration and scanner imports.{#wiz-container-runtime-exposure-cvr__wiz-container-runtime-exposure-cvr-p-9}

To open the record, navigate to AllSystem PropertiesAll Propertiessn_vul_wiz.deployment_context_gate_writes.

*[\>]: and then