Vulnerability response Discovered Item, CMDB Payload and IRE

[HelloCAD]

Hi ServiceNow Experts,

We have a ServiceNow Vulnerability integration with Rapid7. I wanted to understand the process after the raw CMDB data gets ingested into ServiceNow.

When Integration runs, what data (and format of data) for CMDB CI are ingested? Where can I view the Payload? 

How does the system know which CI class's IRE - Identification rules to run? I read it is identified from the payload, but I could not find where I can view and review the said payload.

How does the information from the Payload map to the attributes in the ServiceNow CMDB CI tables? 

Any help on these would be appreciated. Thank you.

[BhavaniYamsani]

Hi @HelloCAD ,

The IRE is not necessarily the first step when Rapid7 asset information is ingested into ServiceNow Vulnerability Response. The integration first processes the scanner's asset information and attempts to correlate it with existing Discovered Items and CMDB CIs.

The exact processing path depends on whether you are using Rapid7 InsightVM through REST APIs or the Rapid7 Data Warehouse integration.

When Rapid7 asset information is ingested, the process generally works as follows:

1. First, ServiceNow checks whether a matching Discovered Item already exists.

The Discovered Items table is sn_sec_cmn_src_ci.

ServiceNow uses the source information and external asset identifier to correlate incoming scanner data with an existing Discovered Item. This allows subsequent updates from the same scanner asset to be associated with the existing record.

IF THAT DOES NOT MATCH

2. Vulnerability Response evaluates the CI Lookup Rules.

Navigate to All → Security Operations → CMDB → CI Lookup Rules.

The Rapid7 integration can use lookup rules based on attributes such as:

• MAC address

• Fully qualified domain name (FQDN)

• Hostname

• IP address

These rules determine whether the incoming asset matches an existing CI in the CMDB. The lookup rule used for a Discovered Item can help you understand how ServiceNow identified the corresponding CI.

IF THAT DOES NOT MATCH

3. The applicable CI creation process can invoke the Identification and Reconciliation Engine (IRE).

IRE uses the CI class and identifying attributes supplied by the processing logic to evaluate the applicable CMDB identification rules. If no existing CI is identified, the applicable Vulnerability Response CI creation logic may create a CI in a supported class, depending on the available data and configuration.

Do not assume that IRE automatically selects the correct class simply by examining the IP address or hostname. The class information and the processing logic that constructs the IRE input are important.

Where can you view the payload?

Start with the Discovered Items table:

sn_sec_cmn_src_ci

Open the Discovered Item corresponding to the Rapid7 asset and inspect the source, external asset identifier, available identifying attributes, CI reference and CI matching rule fields.

However, the Discovered Item is not necessarily a complete copy of the raw Rapid7 API response.

To inspect the original data, trace the integration execution and its REST API response or Data Warehouse query results, depending on the integration type. If the complete response is not retained in the execution logs, inspect the relevant integration processing logic and use controlled debugging in a non-production environment.

If you specifically want to see the payload passed to IRE, inspect the CI creation processing path and the actual IRE input. This is different from viewing the original Rapid7 response.

How does the payload map to CMDB attributes?

The mapping depends on how the integration extracts and transforms the Rapid7 asset information.

For example:

• The Rapid7 asset ID helps identify the source asset and its Discovered Item.

• The hostname and FQDN can be used to identify an existing CI.

• The IP address and MAC address can be used by applicable CI lookup rules.

• The CI class and attribute values supplied to IRE determine which class and identifying information are processed during CI creation.

These are examples of how the attributes are used; they do not mean that every Rapid7 response field is automatically copied into a corresponding CMDB field.

To trace the exact mapping, select one Rapid7 asset, compare its source attributes with the associated Discovered Item and CMDB CI, and inspect the integration processing logic to determine which fields are extracted, transformed and passed to the lookup or IRE process.

Also remember that IRE reconciliation rules can restrict updates to existing CI attributes. A value present in the incoming payload may therefore not overwrite an existing CMDB value.

If you are troubleshooting incorrect CI matching, consider the following:

• Is the Discovered Item matched or unmatched, and which CI matching rule was used?

• Does Rapid7 provide reliable asset identifiers and identifying attributes?

• Are the CI Lookup Rules active and configured with the intended matching logic?

• If IRE is invoked, what CI class and attributes are present in its input payload?

• Are reconciliation rules preventing particular attributes from being updated?

• Are you using InsightVM or the Data Warehouse integration, and are you tracing the correct ingestion path?

The key is to trace one asset end to end: Rapid7 response → Discovered Item → CI Lookup Rules → IRE input, if applicable → final CMDB CI. This will help you determine whether the issue is in the source data, the lookup logic, the CI creation process or CMDB reconciliation.

If this answer helps, please mark it as helpful. Thank you!