Best Practice for Flagging Recurring False Positive VITs by QID + CI (Qualys Integration)

[RichardG8808753]

Hi all,

Looking for advice from the community on handling recurring false positives in Vulnerability Response/USEM.

Context:

• We're using ServiceNow Vulnerability Response / USEM (Australia Release) integrated with Qualys (Host Detection).
• Our team has identified certain QID + CI combinations that are confirmed false positives 
• These VITs keep reappearing or reopening on subsequent Qualys scan imports, creating noise for the remediation teams.
• Bulk load of currently approved false positives

What we're trying to achieve:

1. A repeatable way to flag specific QID + CI combinations as known false positives.
2. Prevent them from reopening or generating new VITs on future imports.
3. Maintain proper governance — approval, justification, evidence, and periodic review.
4. Ideally keep ServiceNow and Qualys aligned so the suppression is reflected on both sides.

Questions:

• What approach have you found works best — deferral with a False Positive substate, exception rules, closing at the Vulnerability Group level, or something else?
• How are you preventing re-opening on re-import from Qualys? Any specific integration properties or reconciliation settings we should look at?
• Are you pushing the false positive status back to Qualys, or managing it purely in ServiceNow?
• Any lessons learned around governance (approvals, expiration/review cadence, reporting)?

Happy to hear both OOB approaches and any customizations you've implemented. Please also mention which VR release you're on, as I know behavior has evolved across versions.

Thanks in advance!

Richard

[RichardG8808753]

Good morning All, 

I could really use some guidance on this and it is time sensitive. I would greatly appreciate any help you can give me.

Thank you.

[navyanowdev]

Hi Richard,
I am looking at the custom automation path, just like exception rule.
1. create a False positive rule (custom table) with condition like particular Vulnerability or set of assets
2. After the integration runs, a schedule job runs to automatically apply the false positive for all the vits falling under that condition
logic goes like identify the vits matching the criteria, update the state = closed and reason = false positive

(function executeFixScript() {

    var gr = new GlideRecord('sn_vul_vulnerable_item');
    gr.addEncodedQuery('sourceSTARTSWITHrapid7^vulnerability=2fa87a1247747adc4d82caef016d4316^state!=3');
    gr.query();

    var updated = 0;

    while (gr.next()) {
        gr.setValue('state', 3); // Closed
        gr.setValue('substate', 22); // False Positive
        gr.close_notes = "Closed as False Positive. The vulnerability finding is confirmed as false positive ";
        gr.work_notes = 'The "X.509 Certificate Subject CN Does Not Match the Entity Name" finding occurs when a vulnerability scanner connects to a TLS-enabled service by IP address while the certificate is issued to the server\'s DNS name/FQDN. For example, the scanner may connect to 10.x.x.x, while the certificate contains server_name.westernalliancebancorp.com in its Subject Alternative Name (SAN). Because the IP address being scanned does not match the identity contained in the certificate, the scanner reports a certificate-name mismatch.';
        gr.update();
        updated++;
    }

    gs.info('Fix Script completed. Updated ' + updated + ' Vulnerable Items.');

})();