Rapid7 VM Integration - Challenges with Remediation Tracking, Asset Comparison, and Timestamps

[navyanowdev]

We're currently working with the Rapid7 Vulnerability Management (VM) integration and have encountered several challenges related to remediation tracking and asset synchronization.

Some of the issues we're seeing include:

Inconsistencies between vulnerability remediation status in Rapid7 and the corresponding records in ServiceNow.
Confusion around the use of currentTime and comparisonTime parameters when retrieving assets through the Rapid7 VM API.

Asset records not always reflecting expected changes between comparison windows, making it difficult to accurately identify newly discovered, remediated, or modified assets.
Challenges troubleshooting incremental data loads when timestamps differ by only a few minutes or when API pagination/cursor-based retrieval is involved.

Difficulty validating whether discrepancies are caused by API response timing, synchronization schedules, data transformation logic, or delayed updates within Rapid7.
For example, we've observed API calls similar to:
currentTime=2026-08-03T09:40:08Z
comparisonTime=2026-08-02T09:43:49Z

In this scenario, the comparison window is approximately 23 hours and 56 minutes apart, and we're trying to understand how Rapid7 determines asset state changes and remediation status within that timeframe.

I'd like to hear from anyone who has experience with:

1. Rapid7 VM and ServiceNow Vulnerability Response integrations.
2. Best practices for handling asset comparison windows.
3. Troubleshooting missing or delayed remediation updates.
4. Managing API pagination and cursor-based synchronization.
5. Validating asset and vulnerability reconciliation between Rapid7 and ServiceNow.
Any recommendations, lessons learned, or documentation references would be greatly appreciated.

Thank you!