Configuring container image granularity keys for Container Vulnerability Response
Summarize
Summary of Configuring container image granularity keys for Container Vulnerability Response
ServiceNow’s Container Vulnerability Response (CVR) application allows customers to configure keys that determine how container vulnerability findings (CVITs) are generated from imported vulnerability scanner data. These granularity keys control the level of detail in findings, enabling you to assign and view vulnerabilities by image repository, cluster, namespace, or service depending on your container environment and scanner integration.
Show less
Each third-party scanner integration has a unique record for configuring these keys in the Configure Image Vulnerability Keys table within your ServiceNow AI Platform instance. Adjusting these keys before importing vulnerability data helps tailor the vulnerability management process to your operational structure and remediation needs.
Key Features
- Granularity Levels: Findings can be created at different granularities based on combinations of image repository, vulnerability, cluster, namespace, and service.
- Environment Support:
- AWS ECS: Configure findings by cluster and/or service. Selecting cluster generates one finding per cluster; selecting both cluster and service creates findings per unique cluster-service pair.
- AWS EKS: Supports three-level granularity with cluster, namespace, and service keys. Selecting all three creates the most granular findings.
- Data Sources: You can choose between Scanner Information and Discovery Information as the source for cluster, namespace, and service data. Discovery Information relies on ServiceNow Discovery and is the default. This choice affects how findings are matched and generated.
- Scheduled Jobs: When using Discovery Information, a daily scheduled job (Populate image relationships) runs to pre-import cluster and service data. Scanner integrations should be scheduled to run after this job completes to ensure data consistency.
- Historical Data Scope: The system property snvulcontainer.imagerelationshipmappingmonths controls how many months back the scanner integration searches for image updates, defaulting to 3 months.
- Data Model Changes: Recent versions updated table columns on Container Vulnerable Item records to distinguish between scanner and discovery data sources for cluster, namespace, and service attributes, improving clarity and data handling.
Practical Application for ServiceNow Customers
- To customize vulnerability findings granularity, navigate to All > Container Vulnerability Response > Administration > Configure VI Granularity and update the relevant keys for your scanner integration before importing data.
- Choose granularity keys based on your container environment (ECS or EKS) and how detailed you want ownership and remediation assignments to be (e.g., service level for finer control).
- Select the appropriate data source (Scanner or Discovery) for environment metadata, considering that Discovery requires scheduling coordination.
- Understand that configuring granularity keys impacts how vulnerabilities are grouped, displayed, and managed within your CVR application, enabling more precise tracking and remediation aligned with your operational structure.
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 .
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
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:
|
| 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.
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.
- 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.
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
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.