Integrating multiple Qualys sources into Configuration Compliance

[WeiY]

We are ingesting Qualys test results from multiple Qualys instance... let's refer to them as Qualys A and Qualys B. Each Qualys instance has different policies and ingesting test results from each instance results in policies being recorded in the sn_vulc_policy table.

When ingesting, I noticed that the source is “Qualys” whether I'm ingesting from Qualys A or Qualys B and there is no way to tell which policies came from which source. So I dug deeper into the code and found that the source is being hardcoded as "Qualys" no matter how many instances we are ingesting from.

This can be seen in the following 4 Script Includes within the Qualys Integration for Security Operations scope which are referenced when ingesting policies and when querying test results for those policies.

• PolicyStream

• PolicyListStream

• QualysPCResultsIntegration

• QualysPCPolicyDetailsIntegration

In order to differentiate the policies for each instance for ingestion, all existing policies in the sn_vulc_policy table are marked as inactive (_markInactive function in PolicyListStream Script Include) if they are not in the _receivedPolicy array which is populated by the _handlePolicy function in the same Script Include.

This means that active Qualys A policies will be marked as inactive while Qualys B policies and test results are being ingested (and vice versa). It also means that Qualys A and Qualys B ingestions cannot be done at the same time. They need to be done sequentially since each ingestion loops through the sn_vulc_policy table for all active policies to use in the query for test results.

We are running reports based on the sn_vulc_policy table and need to know which policies are active and inactive as well as which remediation tasks are linked to inactive policies. However, because the policies from Qualys A are set to inactive during ingestions of Qualys B (and vice versa), we can't accurately run these reports.

Is there a way to differentiate these policies that are coming in from Qualys A and Qualys B and to keep active ones from Qualys A active while ingesting from Qualys B?

[msd93]

Any solution for this @weiy as I have a similar requirement 

[BhavaniYamsani]

 

Hi  ,  
ServiceNow Configuration Compliance supports multiple Qualys Cloud Platform deployments within a single ServiceNow instance. However, when policies from one deployment are marked inactive during another deployment's ingestion, the issue needs to be addressed at the integration and policy lifecycle level.

The following steps use the available out-of-box (OOB) functionality before considering any customization.

Step 1: Check the installed Qualys integration version

Navigate to All → System Applications → All Available Applications → Installed and identify the installed version of Qualys Integration for Security Operations and Configuration Compliance.

The 2026 release notes describe updates to the Qualys PC Policies and PC Policies Detail integrations, as well as the introduction of a Comprehensive PCRS integration. Review the applicable release notes and upgrade to a compatible version containing the relevant improvements where available.

Reference: Qualys Integration for Security Operations release notes

Step 2: Verify that both Qualys deployments have separate integration configurations

Navigate to:

All → Qualys Vulnerability Integration → Administration → Integration Instances

Verify that Qualys A and Qualys B are configured as separate integration instances with their respective connection details and credentials.

ServiceNow documents support for multiple Qualys deployments, with data from those deployments consolidated into a single instance.

Reference: Qualys integration with Configuration Compliance

Step 3: Review the newer PCRS integrations

In the 2026 releases, ServiceNow introduced updates to the Qualys Policy Compliance Reporting Service (PCRS) integrations, including support for newer Qualys APIs.

Starting with Qualys Integration for Security Operations v12.21.0 and Unified Security Exposure Management v30.3.0, the posture_api_version integration instance parameter can be configured to use API version 2.0 or 5.0.

Navigate to:

All → Qualys Vulnerability Integration → Administration → Integration Instances

Open the relevant integration instance and review the Integration Instance Parameters tab.

For the newer PCRS integrations, configure the required gateway_url and, where applicable, posture_api_version and pcrs_page_size parameters.

Reference: Configure PCRS

Important: The newer PCRS integrations are inactive out of the box. Activating them deactivates the corresponding PC Results integrations. Evaluate the existing integration configuration and dependencies before switching ingestion paths.

Step 4: Verify the execution order

For the PCRS integration path, ServiceNow documents the dependency between the PCRS Policy Host Integration and the PCRS Test Results Integration.

When running the integrations manually, follow the documented execution order and ensure that policy data is available before test results are processed.

Reference: Components installed with Qualys Integration for Security Operations

Step 5: Validate policy activation and reporting

After validating the configuration, execute the integrations in a sub-production environment and verify the following:

• Policies from Qualys A remain active when Qualys B is ingested, unless those policies have legitimately been deactivated in Qualys A.

• Policies from Qualys B remain active when Qualys A is ingested.

• Test results are associated with the correct policies.

• Reports correctly reflect policy activation status and linked remediation tasks.

Conclusion

The recommended OOB approach is to verify the installed integration version, maintain separate integration configurations for each Qualys deployment, and evaluate the newer PCRS integrations where appropriate.

The published documentation confirms multiple-deployment support and newer PCRS integration capabilities. However, it does not explicitly document a configuration parameter that scopes the legacy _markInactive() method to a particular Qualys deployment.

If the same cross-instance deactivation continues with the supported integration configuration, the issue cannot be resolved merely by changing the generic source = Qualys value. A correction to the policy lifecycle logic would be necessary to ensure that one deployment does not deactivate policies belonging to another.

  - Please let us know how you have solved the issue mentioned by you.

If this answer helps, please mark it as helpful. 

Thankyou
Yamsani Bhavani - ServiceNow - SecOps, GRC, Custom Applications, Now Assist