--- title: Configuring container image granularity keys for Container Vulnerability Response description: 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. locale: en-US canonical_url: https://www.servicenow.com/docs/r/australia/security-management/container-vulnerability-response/cvr-configuring-findings-key-granularity.html release: australia product: Container Vulnerability Response classification: container-vulnerability-response topic_type: concept last_updated: "2026-04-01" reading_time_minutes: 5 breadcrumb: [Configure, Container Vulnerability Response, Unified Security Exposure Management, Security Operations] --- # Configuring container image granularity keys for Container Vulnerability Response 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. ## Overview of Container image vulnerability keys and how they generate findings When container images are scanned for vulnerabilities, a granularity feature controls how findings \(container vulnerable items or CVITs\) are created based on keys that you can configure for the Container Vulnerability Response application. Each third-party container vulnerability scanner integration has its own record on the Configure Image Vulnerability Keys \[sn\_vul\_container\_image\_vulnerability\_keys\] table in your ServiceNow AI Platform instance. By default, a finding \(CVIT\) is created by combining the image repository, vulnerability, and image data imported by a scanner product. Key granularity can help you view and assign findings at a more granular level by service. Role required: sn\_vul\_container.configure\_vi\_granularity Terms used for key granularity: - **Vulnerability** Imported CVE/CWE Common Vulnerabilities Exposures, Common Weakness Enumeration and other third-party vulnerability data that is used to create findings \(CVITs\) in your instance. - **CVIT** A container vulnerable item \(also referred to as a finding\), which is generated by default using Image, Image repository, and Vulnerability data for its key configuration. - **Cluster** Imported data about a group of machines or working nodes that run containerized applications. - **Namespace** Imported unique names of resources to isolate them within a single cluster. - **Service** Containers of application dependencies that let you manage and deploy containerized applications. In this context for key granularity and configuration: - Elastic Container Service \(ECS\) environment- Cluster and Service are options for key configuration. - Elastic Kubernetes Service \(EKS\) environment - Namespace, Cluster, and Service are options for key configuration. Each product key has a unique record on the list. The following key configuration hierarchies for the ECS and EKS environments share the same granularity configuration located at **All** > **Container Vulnerability Response** > **Administration** > **Configure VI Granularity**. If you want to configure the key granularity, you must make your changes and update the record before importing data with your third-party integrations. ## AWS ECS \(Elastic Container Service\) ECS environments are organized into clusters and services, where one cluster can contain multiple services. - Clusters - Services \[Omitted image "mmasset0021775-ecs-hierarchy.svg"\] Alt text: Hierarchy relationship between clusters and services If you set the key granularity so it is set to add the Cluster component \(Cluster check box selected on the Configure Image Vulnerability Keys VI Granularity record\), one finding \(CVIT\) is created per cluster. If you select the **Cluster** and **Service** options for the key, a finding \(CVIT\) is created for every unique cluster/service combination, enabling remediation ownership to be assigned at a more granular level by service. For example, say your environment has two clusters, Cluster 1 and Cluster 2, and four services: Service 1, Service 2, Service 3, and Service 4. The CVITs created by you key selections are shown in the following table. Cluster and service data can be sourced from either the scanner payload \(**Scanner Information**\) or ServiceNow Discovery \(**Discovery Information**\). This option can affect how CVITs are created, depending on your key selections.
Data source Cluster check box selected Service check box selected CVITs created
Scanner Information x   Two CVITs are created, one for each Cluster, Cluster 1 and Cluster 2.
Scanner Information x x Multiple CVITS \(4\) are created to support two Clusters and four services:- Cluster 1/Service1 - Cluster 1/Service 2 - Cluster 2/Service 3 - Cluster 2/Service 4
Discovery **Note:** If Discovery is selected as the data source, the source of truth for clusters and services comes from ServiceNow Discovery — not the scanner payload. x   One CVIT is created for Cluster 3. If Discovery only finds Cluster 3 for this image, only one CVIT is generated regardless of what the scanner knows.
By default, **Discovery Information** is selected. If you want **Discovery Information** as the data source for the key, the \[Populate image relationships\] scheduled job runs daily to pre-import cluster and service details, and you must schedule your third-party integration runs to start at least four hours after this scheduled job is successfully completed to make sure that the pre-import data is available. This job is activated by default daily, but you must set the schedule for it before your scheduled third-party integration imports. **Note:** For new customers only starting with version x.xx. The \[sn\_vul\_container.image\_relationship\_mapping\_months\] system property defines how many months back \(1-12\) your third-party scanner integration searches for container image updates when processing relationship mappings. This data is used to filter images by the \[sys\_updated\_on\] field. The default setting is three months \(90 days\). Unless you change this value, after you configure your scanner integration import, relationship mapping is created for images which are scanned in the last 90 days by default and present in discovered container images. ## Data population Before ECS was supported with version 30.3 \(USEM\)-compatible and v2.18 \(Core\), there were two sets of columns on the Container Vulnerable Item \[sn\_vul\_container\_image\_vulnerable\_item\] table for populated data: - Image namespace and Image clusters columns are displayed if the **Scanner Information** data source is selected for the key configuration. - Kubernetes Namespaces, Kubernetes Clusters, and Kubernetes Services if the **Discovery Information** data source is selected for the key configuration. Starting with version versions 30.3 and 2.18, the following columns on the Container Vulnerable Item \[sn\_vul\_container\_image\_vulnerable\_item\] table have been renamed to match the data sources: - Cluster \(Scanner\) Namespace \(scanner\), and Service \(scanner\) if the **Scanner Information** data source is selected for the key configuration. - Cluster \(Discovery\), Namespace \(Discovery\) and Service \(Discovery\) if the **Discovery Information** data source is selected for the key configuration. **Note:** On the CMDB Docker container image record on the Discovered Container Image \[sn\_vul\_container\_image\] table, only **Scanner Information** is directly populated with the column names listed above. You can view discovery-based data \(cluster/namespace/service\) by opening the Docker image record on the Discovered Container Image record. On this record, view the related items/relations section for the data populated by **Discovery Information**. ## AWS EKS \(Elastic Kubernetes Service\) On the Configure Image Vulnerability Keys records, there are three additional keys you can add to the default key for EKS environments: - Namespace - Registry - Service \[Omitted image "mmasset0021754-eks-hierarchy.svg"\] Alt text: Hierarchy relationship for cluster namespace and services EKS environments have a three-level hierarchy: clusters/namespaces/services. If you select all three levels \(cluster + namespace + service\) findings are generated with the most supported granularity. The option to select the Data source as **Scanner Information** or **Discovery Information** is supported for EKS. As an example, say you have Cluster 1, Namespace 1, and two services, Service 1 and Service 2. If you select all three levels, two CVITs are created for the most supported granularity, one for each service. If, on the other hand, you select Cluster 1 and Namespace 1 for this example, one CVIT is created for one Namespace. - **[Configure container image granularity keys for Container Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/cvr-configure-key-granularity.md)** Configure the keys that generate Container Vulnerability Response findings. **Parent Topic:**[Configuring Container Vulnerability Response](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/container-vulnerability-response/configure-cvr.md)