Splitting Wiz Container Vulnerability Ingestion

[BradW0930243930]

Overview

Vulnerability Response Integration with Wiz supports multiple integration instances against the same Wiz tenant. Each instance has its own configuration, its own copy of the Wiz integrations, and its own schedule and run history. This example is about splitting the integrations by severity. By creating an additional instance and assigning a different container severity filter to each instance, you can split container vulnerability ingestion into separate lanes by Wiz severity.

This article explains how the instance model works, when a severity split is the right approach, how to configure it, and what to consider before enabling it in production.

Applies to

• Vulnerability Response Integration with Wiz (sn_vul_wiz), ServiceNow Store application
• Container Vulnerability Response
• Behavior described in this article was validated on application version 32.0.5. Confirm behavior on your installed version before implementing.

How Wiz integration instances work

Three components determine what each Wiz integration pulls and how it behaves:

• Integration instance (sn_sec_int_impl): the container for a set of Wiz integrations and their stored settings. Each instance keeps its own settings in sn_sec_int_impl_config.
• Configuration record (sn_vul_wiz_configuration): the form where you enter Wiz credentials and filters. Its Integration instance field determines which instance the settings are saved to when you click Save and test.
• Integrations (sn_vul_int_fw_integration): the scheduled jobs that pull data from Wiz, such as Wiz Container Vulnerability Integration. Each integration belongs to one instance and reads that instance’s stored settings every time it runs.

When a new integration instance is created, the platform automatically copies all Wiz integrations to it. The new instance does not get a configuration record automatically, and the Configuration menu item in the Wiz application always opens the original instance’s configuration record. The configuration record for an additional instance must be created manually.

Settings take effect only when you click Save and test. Clicking Save updates the configuration record but does not push the values to the instance’s stored settings, so the integrations continue to use the previous values.

When to use this approach

A severity split is appropriate when you need container findings of different severities to be ingested on separate schedules or in separate runs, for example to control run volume or to pull high-severity findings more frequently.

Consider these alternatives first:

• Different handling by severity. If the goal is different assignment, SLAs, or notifications by severity, keep a single integration and route container vulnerable items using assignment and remediation rules. This avoids the considerations described later in this article.
• Excluding severities entirely. If the goal is to stop ingesting certain severities, set the severity filter on the existing configuration record. No additional instance is needed.

Prerequisites

• Complete this configuration in a sub-production instance first.
• The user performing the configuration needs both the admin role and sn_vul_wiz.configure_integration. The admin role alone does not grant create or write access to Wiz configuration records.
• Set the application scope to Vulnerability Response Integration with Wiz. The Save and test button only appears in this scope.
• Plan the severity split. Available Wiz severity values are CRITICAL, HIGH, MEDIUM, LOW, and NONE. Each value should be assigned to only one configuration record.
• Have the Wiz service account details available: Auth URL, API URL, Client ID, and Client Secret. All instances can use the same service account.

Procedure

Step 1: Create the additional integration instance

1. Navigate to sn_sec_int_impl.list and click New.
2. Complete the form:
   • Name: a unique, descriptive name (for example, "Vulnerability Response Integration with Wiz - HIGH")
   • Integration: Vulnerability Response Integration with Wiz
   • Active: true
3. Click Submit.

The platform automatically copies all Wiz integrations to the new instance.

Step 2: Create the configuration record for the new instance

1. Navigate to sn_vul_wiz_configuration.list and click New.
2. Set Integration instance to the instance created in Step 1.
3. Enter the Wiz connection details: Auth URL, API URL, Client ID, and Client Secret.
4. On the Resource Type Configuration tab, select at least one resource type. The integration does not run without this value.
5. In the Container Vulnerability Configuration section, set the vulnerabilities severity filter to the severities this instance should ingest.
6. Click Save and test and confirm the message "Credentials saved and validated successfully."

Step 3: Set the severity filter on the existing configuration record

1. On sn_vul_wiz_configuration.list, open the record for the original instance.
2. Set the vulnerabilities severity filter to the remaining severities. Do not repeat any value assigned to the new instance.
3. Click Save and test.

Each sn_vul_wiz_configuration record must have a different severity filter. An empty filter ingests all severities and overlaps with every other instance.

Step 4: Deactivate the additional integrations on the new instance

1. Navigate to sn_vul_int_fw_integration.list.
2. Filter Instance = the instance created in Step 1.
3. Set Active = false on every record except Wiz Container Vulnerability Integration.
4. Open Wiz Container Vulnerability Integration and change Time so it does not run at the same time as the container integration on the original instance.

Deactivating these integrations prevents host vulnerabilities, assets, issues, and test results from being ingested twice.

Step 5: Verify the configuration

1. Navigate to sn_sec_int_impl_config.list.
2. Filter Configuration.Name = cv_vendor_severity and group by Implementation.
3. Confirm each instance shows its own severity values with no overlap. These are the values the integrations use at runtime.
4. Run each Wiz Container Vulnerability Integration on demand, one at a time, and confirm each run completes successfully.

The first run on the new instance retrieves all current findings that match its filter, so expect it to take longer than later runs.

Considerations

• Records are not shared between integration instances. Each integration instance keeps its own container vulnerable items. For example, if Wiz changes a finding from HIGH to MEDIUM, the MEDIUM instance creates a new item, and the HIGH instance’s container vulnerable item stops updating. That item must be closed manually unless CVIT auto-close (sn_vul_container_image_auto_close_config) is enabled.
• Filter is based on Wiz vendor severity. The severity displayed on a container vulnerable item can be derived from Wiz weighted severity when available, so it may not always match the instance the item was ingested through.
• Additional supporting records. Each instance creates its own discovered container image records and Wiz project records. Both instances still resolve to the same CMDB configuration items.
• Finding all Wiz configuration records. The out-of-box Configuration module opens only the original record. Use sn_vul_wiz_configuration.list, or add a new module to the Wiz application menu in the navigator that lists all sn_vul_wiz_configuration records, restricted to the sn_vul_wiz.configure_integration role. Leave the out-of-box Configuration module as is or deactivate it once the new module is in place.
• Wiz API usage. Each instance calls the Wiz API independently. Consider this for large Wiz tenants.

Maintenance

• To change an instance’s severity filter, open its record on sn_vul_wiz_configuration.list, update the filter, and click Save and test.
• After each Wiz application upgrade, repeat Step 5. Upgrades update the original instance’s integration definitions. If the release notes mention changes to the container integration, delete and recreate the additional instance (Steps 1 through 4) so it picks up the updated definitions.

Summary

Severity is split at the integration instance level. Each instance needs its own configuration record, a unique severity filter applied with Save and test, and only the container integration active on any additional instance. Validate in sub-production, confirm the stored values per instance, and monitor for duplicate container vulnerable items after enabling the split.