Wiz Integration – Clarification on last found not updating for active detections

[MichelleS384771]

Hi everyone,

I’m currently facing an issue with the Wiz integration and would like to clarify how last found (mapped from lastDetectedAt) behaves, especially in relation to auto-closure rules.

 
We have an auto-close rule that closes Vulnerable Items if:

last_found is older than 14 days

Observed issue

• We are seeing multiple cases where: The vulnerability is still ACTIVE in Wiz
• However, in ServiceNow:

                The last found field is not being updated

• As a result:

                 The Vulnerable Item becomes stale
                 It gets auto-closed, even though the issue still exists in Wiz

Example scenario

• Vulnerability still active in Wiz as of: April 21
• In ServiceNow: Last Found = April 8.
• Because last_found was not updated: The detection was marked as stale. It was auto-closed on April 23
• After that: It was reopened on May 14, 2026
• Then again marked stale and closed on May 28, 2026

What I understand so far
From initial investigation:

• last found is mapped from Wiz:
         lastDetectedAt → last_found

However, it seems like:

• Even if a detection remains active in Wiz, last found is not always refreshed in ServiceNow

Questions / Clarifications needed
I would like to confirm the following:

• Does Wiz only send detections to ServiceNow when there are changes (new, updated, or resolved)?
  If a detection is still active but unchanged, is it expected that it will not be re-sent?
• If no new payload is received, is it expected that last_found remains unchanged even if the detection is still active?

Any insights, confirmations, or best practices from others using Wiz integration would be greatly appreciated.

Thanks in advance! 🙏

[abdulrehmanArif]

Hi Michelle, you've correctly identified the root cause — let me confirm and explain.

Yes, the Wiz integration only sends changed records.

The Wiz integration runs two scheduled daily jobs:

• "Wiz Fetch Vulnerabilities Daily Run – New Vulnerabilities" — fetches vulnerabilities found in the last 24 hours
• "Wiz Fetch Vulnerabilities Daily Run – Resolved Vulnerabilities" — fetches vulnerabilities resolved in the last 24 hours

The plugin is designed to import Wiz vulnerabilities as point-in-time incremental changes on a daily basis. This means if a vulnerability is still active in Wiz but nothing changed about it (no new detection, no resolution, no field update), Wiz will not re-send it in the daily run — and as a result, last_found in ServiceNow simply won't be touched. 

So to directly answer your questions:

1. Yes — Wiz only pushes detections to ServiceNow when there's a change (new or resolved). An unchanged active detection won't be re-sent.
2. Yes — if no new payload arrives, last_found stays at whatever it was when Wiz last reported that finding. This is expected behavior, not a bug.

The real problem is the mismatch with your auto-close rule.

Your 14-day auto-close rule based on last_found is fundamentally at odds with how the Wiz integration works. Since Wiz only reports on changes, stable active detections will naturally go stale in ServiceNow even though they're still very much open in Wiz.

What you can do:

• Switch your auto-close rule condition from last_found to "Asset Last Scanned" if Wiz is updating that field, or add an additional condition that checks the Wiz detection status field before closing — so only detections confirmed as resolved in Wiz get auto-closed.
• Use the On-Demand full import job ("Wiz Fetch Vulnerabilities – On Demand") periodically to resync all active detections and refresh last_found. This will pull everything regardless of change status and update dates properly.
• Increase your auto-close threshold to a window that gives the on-demand sync time to run before detections go stale.
• Alternatively, you can configure additional auto-close rule conditions (available in newer VR plugin versions) to require a Wiz status = "Resolved" before closure, preventing false positives from unchanged-but-active detections.

The cycle you're seeing (active → stale → closed → reopened → stale → closed) will keep repeating until the auto-close logic accounts for the incremental-only nature of the Wiz daily sync.

[omarchoudhu]

We are seeing the same behaviour as OP.

Your 14-day auto-close rule based on last_found is fundamentally at odds with how the Wiz integration works. Since Wiz only reports on changes, stable active detections will naturally go stale in ServiceNow even though they're still very much open in Wiz.

---

This sounds like a very weird statement as it contradicts the purposes for which Stale exists. Let's say you do not import Low severity vulnerabilities from Wiz. Now one of the VITs has changed in Wiz to Severity = Low. This VIT would therefore never goes to Stale as the Stale rule has been disabled. 

In the new Wiz integrations developed by ServiceNow there is no On Demand integration. There is only a delta integration. We configured the On Demand integration with the old Wiz plugin to run periodically since we noticed as well that most VITs did not get updates. Our assumption is that Last found is the timestamp of the snapshot when Wiz starts to scan the VM, but it takes hours to complete the scan and it getting updated in Wiz. That's where the logic of the delta update breaks and doesn't properly track the Last found timestamp.

And when we try to clear the Import since field (in the new Wiz integration), we notice that the integration runs are a lot slower than what they used to be in the On demand integration (the old Wiz integration).