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

MichelleS384771
Tera Contributor

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! 🙏

1 REPLY 1

abdulrehmanArif
Tera Expert

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.