No Handling for Deleted Assets Resulting in Stale Vulnerability Items

[LokireddyS]

We have identified a limitation in the out-of-the-box Tenable integration related to asset deletion handling.

Current Behavior

• The Tenable integration imports asset and vulnerability data into ServiceNow.
• When vulnerabilities are no longer present for an existing Tenable asset, the integration correctly closes the corresponding detections and Vulnerability Items.
• However, when an asset is removed or no longer appears in the Tenable import payload, ServiceNow does not receive any indication that the asset has been deleted.
• As a result, the associated Vulnerability Items remain open until they are closed by the configured stale detection/auto-close process.

Business Impact

This behavior impacts vulnerability reporting and SLA compliance.

For example:

• A Tenable asset is deleted, decommissioned, or no longer exists in Tenable.
• The asset is no longer included in subsequent Tenable imports.
• ServiceNow retains the Vulnerability Items associated with that asset.
• These Vulnerability Items remain open until the stale detection process closes them, even though the asset no longer exists in Tenable.

This results in inaccurate vulnerability metrics, remediation tracking, and compliance reporting, as vulnerabilities remain open longer than expected.

Questions

1. Is this the expected behavior of the out-of-the-box Tenable integration?
2. Does the Tenable integration provide any supported mechanism to identify assets that have been removed or deleted from Tenable?
3. Is there any out-of-the-box process or scheduled job that compares imported asset snapshots to identify assets that no longer exist and automatically closes the associated Vulnerability Items?
4. What is the recommended ServiceNow best practice for handling deleted Tenable assets without implementing custom customizations?
5. Has this behavior been addressed in any recent plugin release or is there an existing enhancement request?