Generate Report on VITs part of multiple Remediation Tasks VULs

navyanowdev
Tera Contributor

‎08-13-2026 10:55 AM

I am trying to Use background script, which is timing out after a while.

The  script I am using identifies Vulnerable Items (VITs) that are linked to more than one Vulnerability record through the sn_vul_m2m_vul_group_item table and prints the results.

What the script does

  1. Queries the sn_vul_m2m_vul_group_item M2M table.
  2. Builds a map where:
    • Key = Vulnerable Item Sys ID
    • Value = Array of related Vulnerability Sys IDs
  3. Removes duplicate vulnerability references for each VIT.
  4. Finds VITs associated with multiple vulnerabilities.
  5. Retrieves the VIT number and all related vulnerability numbers.
  6. Prints output like:
VIT0001234 --> VULN0001001, VULN0001002, VULN0001003

Script:
navyanowdev_0-1786643462741.png


And also I tried generating a report, but can't add related list conditions.

navyanowdev_1-1786643655450.png

 




Labels:
0 Helpfuls
  • 777 Views
1 REPLY 1

kmohammed
Giga Guru

Saturday

The timeout is expected with this approach: the script scans the entire sn_vul_m2m_vul_group_item table, builds a map of every VIT in memory, and then runs extra queries to resolve each VIT and vulnerability number. On production-sized data that is exactly what runs past the background script transaction limit.

 

Let the database do the counting instead, with GlideAggregate. This returns only the VITs that actually have more than one vulnerability, so there is no full-table map and no per-VIT lookup loop:

 

var ga = new GlideAggregate('sn_vul_m2m_vul_group_item');

ga.groupBy('sn_vul_vulnerable_item');

ga.addAggregate('COUNT');

ga.addHaving('COUNT', '>', 1);

ga.query();

while (ga.next()) {

  var vitId = ga.getValue('sn_vul_vulnerable_item');

  // Query sn_vul_m2m_vul_group_item once more, filtered to this vitId only, to collect its vulnerability numbers.

}

 

Two follow-ups that matter for the report itself:

 

1. A standard report cannot express "count of related records is greater than 1" as a related-list condition, which is why your report attempt stalled. Run the aggregate above in a scheduled script instead of an interactive background script, write the resulting VITs and their vulnerability numbers to a small custom table, and report on that table.

 

2. If the result set is still large, narrow the aggregate first — for example, to open VITs only — rather than scanning the whole M2M history. The key change is the same either way: filter with COUNT in the database, and only resolve numbers for VITs that pass that filter.

0 Helpfuls