Bulk edit button on Vulnerable item table not working for selected VITs.

Gaurangi Joshi
Tera Contributor

Hi All,

Please help! Urgent!

 

Our client reported an issue of not being able to Close some VITs(32) by clicking on the Bulk edit button on the Vulnerable item table. 

The functionality is working for any other filter or selected VITs except those 32 VITs it's showing the "No record will be updated." message when there should be 32 records.

I tried with the "selected vulnerable item" option too but same result. 

 

GaurangiJoshi_0-1667889985813.png

 

Can anyone please help me understand why this is happening? And suggest a solution.

 

Thanks & Regards,

Gaurangi Joshi

 

 

1 ACCEPTED SOLUTION

 

Hi Gaurangi,

Vulnerable items are usually worked on through Remediation Tasks that group them together. Their states are loosely synchronized, and so it is always worth considering the status of remediation tasks that vulnerable items belong to:
https://docs.servicenow.com/bundle/tokyo-security-management/page/product/vulnerability-response/con...

 

However, in your case, now that you mention the assets are not present in Qualys, I have a guess as to what might be going on. I still recommend you open a ticket with support, as it will require significant detailed information to determine whether this is root cause.

First, so that you can see for yourself, this functionality is controlled by roughly 4 things:

  • UI Action: "Bulk Edit"
  • UI Page: "BulkVulnUpdateDialog"
  • Script Include: "VulnerabilityAsyncJobAJAX"
  • Script Include: "VulnerabilityAsyncJobUtil"

There are other script includes involved, but these are the ones involved in the count.

When the records to be updated are calculated, this is done by the "_getVICount" method in the "VulnerabilityAsyncJobUtil" Script include. This script include specifies a standard encoded query for Vulnerable Items which should always be excluded from Bulk Edits, which is applied on top of whatever query you specify. The purpose of this is to exclude Vulnerable Items for invalid CI's, or decommissioned CI's.

Chances are, the CI's you're referring to match those queries, and so are excluded from your update. I will reproduce the method script, which includes the encoded queries which you see in the variables excludeInvalidCIQuery and excludeCIDecommisionedQuery:

  /**
     * Returns Encoded Query for Excluding VIs, which are either invalid ci or CI decommisioned.
     */
    _getExcludeVIEncodedQuery: function() {
        var excludeInvalidCIQuery = 'src_ciISEMPTY^ORsrc_ci.cmdb_ciISEMPTY^ORsrc_ci.cmdb_ciSAMEAScmdb_ci^substateISEMPTY^ORsubstate!=7';
        var excludeCIDecommisionedQuery = 'substateISEMPTY^ORsubstate!=8^cmdb_ci.life_cycle_stage_statusISEMPTY^ORcmdb_ci.life_cycle_stage_status!=Retired';
        // appending exclude decommissioned ci, only when auto-close decommisioned CI is enabled
        return this.AUTO_CLOSE_CI_DECOMMISIONED ? excludeInvalidCIQuery + '^' + excludeCIDecommisionedQuery : excludeInvalidCIQuery;
    },

 

You can reconstruct these queries in your list filter, to check this, and assist in your support ticket. Please, no need to post any further CI details here.

If this is the root cause, then this is just expected behavior because to the status of these CI's. I recommend making use of the feature to Automatically close vulnerable items related to retired CIs to avoid this altogether.

Best,

Julian

View solution in original post

6 REPLIES 6

 

Hi Gaurangi,

Vulnerable items are usually worked on through Remediation Tasks that group them together. Their states are loosely synchronized, and so it is always worth considering the status of remediation tasks that vulnerable items belong to:
https://docs.servicenow.com/bundle/tokyo-security-management/page/product/vulnerability-response/con...

 

However, in your case, now that you mention the assets are not present in Qualys, I have a guess as to what might be going on. I still recommend you open a ticket with support, as it will require significant detailed information to determine whether this is root cause.

First, so that you can see for yourself, this functionality is controlled by roughly 4 things:

  • UI Action: "Bulk Edit"
  • UI Page: "BulkVulnUpdateDialog"
  • Script Include: "VulnerabilityAsyncJobAJAX"
  • Script Include: "VulnerabilityAsyncJobUtil"

There are other script includes involved, but these are the ones involved in the count.

When the records to be updated are calculated, this is done by the "_getVICount" method in the "VulnerabilityAsyncJobUtil" Script include. This script include specifies a standard encoded query for Vulnerable Items which should always be excluded from Bulk Edits, which is applied on top of whatever query you specify. The purpose of this is to exclude Vulnerable Items for invalid CI's, or decommissioned CI's.

Chances are, the CI's you're referring to match those queries, and so are excluded from your update. I will reproduce the method script, which includes the encoded queries which you see in the variables excludeInvalidCIQuery and excludeCIDecommisionedQuery:

  /**
     * Returns Encoded Query for Excluding VIs, which are either invalid ci or CI decommisioned.
     */
    _getExcludeVIEncodedQuery: function() {
        var excludeInvalidCIQuery = 'src_ciISEMPTY^ORsrc_ci.cmdb_ciISEMPTY^ORsrc_ci.cmdb_ciSAMEAScmdb_ci^substateISEMPTY^ORsubstate!=7';
        var excludeCIDecommisionedQuery = 'substateISEMPTY^ORsubstate!=8^cmdb_ci.life_cycle_stage_statusISEMPTY^ORcmdb_ci.life_cycle_stage_status!=Retired';
        // appending exclude decommissioned ci, only when auto-close decommisioned CI is enabled
        return this.AUTO_CLOSE_CI_DECOMMISIONED ? excludeInvalidCIQuery + '^' + excludeCIDecommisionedQuery : excludeInvalidCIQuery;
    },

 

You can reconstruct these queries in your list filter, to check this, and assist in your support ticket. Please, no need to post any further CI details here.

If this is the root cause, then this is just expected behavior because to the status of these CI's. I recommend making use of the feature to Automatically close vulnerable items related to retired CIs to avoid this altogether.

Best,

Julian

Alex Cox
ServiceNow Employee
ServiceNow Employee

More details would definitely help! That said, due to your urgency -  if you haven't already filed a support ticket I would suggest getting one created as they will be able to dive more deeply.

 

You can find the support portal here: support.servicenow.com