Matched Discovered Items have empty 'Matching type for the DI' field

[HelloCAD]

We have Rapid7 integration setup for Vulnerability response. Many of the Discovered Items that have 'Matched' state has empty 'Matching type for the DI' field. How is this possible?

Is this a known error or is this happening due to some gaps?

[Nilesh Pol]

@HelloCAD 

The issue you're encountering with Rapid7 integration for Vulnerability Response, where Discovered Items (DIs) in the 'Matched' state have an empty 'Matching type for the DI' field, can be attributed to several factors. Here's a breakdown of potential causes and solutions:

1. Integration Configuration:

   • Ensure that the integration between Rapid7 and ServiceNow is correctly configured. The mapping of fields from Rapid7 to ServiceNow should be reviewed to ensure that the 'Matching type for the DI' field is correctly populated during the data transfer.

2. Data Mapping and Transformation:

   • Check the data transformation logic used in the integration. There might be a gap in how the 'Matching type for the DI' field is mapped or transformed from Rapid7 data to ServiceNow. Ensure that the field mapping includes logic to populate this field.

3. Scripted Transform Maps:

   • If you are using scripted transform maps, verify that the script correctly handles the population of the 'Matching type for the DI' field. There might be a condition or error in the script that prevents the field from being populated.

4. Integration Logs:

   • Review integration logs for any errors or warnings that might indicate why the 'Matching type for the DI' field is not being populated. Logs can provide insights into any issues during the data import process.

5. Field-Level ACLs:

   • Ensure that there are no field-level ACLs or permissions that might be preventing the population of the 'Matching type for the DI' field. Sometimes, ACLs can inadvertently restrict data updates.

By systematically checking these areas, you should be able to identify the root cause of the issue and resolve it. If the problem persists, consider reaching out to your ServiceNow administrator or Rapid7 support team for further assistance.

[HelloCAD]

Hi @Nilesh Pol , thank you for your response.

Shouldn't the field 'Matching type for the DI' on Discovered item be populated after the Lookups & IREs. It should not be from the source or transform maps/scripts?

Thank you.

[Simon Hendery]

Hi @HelloCAD - I'd bet money that an hallucinating LLM was behind that answer. Let's hope someone else can help.

[andy_ojha · Accepted solution]

Hey there,

Is this a fairly recent deployment of Vulnerability Response (i.e. initially going live after Jan 2024), or perhaps did we go live with Vulnerability Response prior to 2024?

The "Matching type for the DI" field, was introduced in VR v18 - around the March 2023 timeframe.

If we went live with VR prior to March 2023, and upgraded VR after that time -> the "Matching type for the DI" field would have been added to the Discovered Item table during a later upgrade

• However, the field "Matching type for the DI" would only be populated for Discovered Items created after that time (after we upgraded) - i.e. after we upgraded to a version of VR beyond v18
• Discovered Items created before that field was added to the Discovered Items table, would have this field with blank values - i.e. if the Discovered Items were created on VR before v18 or later

Reference:

https://www.servicenow.com/docs/bundle/store-release-notes/page/release-notes/store/security-operati...

This information is only available for data that is populated for Vulnerability Response v18.0 and later. On existing data, this column doesn’t contain any value.

• Note: If you reapply the CI lookup rules, some CIs on DIs might be updated, resulting in this column being populated.

If we have Discovered Items created after we migrated to VR v18 or higher - i.e. created last week from Rapid7, on VR v26.x - that would indicate we have a problem, and it'd be best to open up a ServiceNow Support Ticket to investigate.