- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-06-2022 07:00 PM
The linked CI from a third party scanner (Tenable.io) is imported into the "Discovered Item", but I would like to know how to remove it.
The state of the record is "unmatched".
The reason is that there is a request from the customer to delete the CI that should not be imported into ServiceNow due to a setting error on the scanner side.
Of course, when a setting error on the scanner side is found, change the scanner setting so that the wrong CI will not be imported after that.
According to the Community article below, there is a setting called "nobody" in the ACL.
https://community.servicenow.com/community?id=community_question&sys_id=fc2336d31b580cd0ada243f6fe4b...
So, I think it may be possible to remove it by adding "admin" etc. here, but please tell me if this method is correct and what best practices are.
Best Regards.
Solved! Go to Solution.
- Labels:
-
Vulnerability Response

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-08-2022 02:28 AM
Hi,
I hoped that you would extract just the information you needed to delete the DI and ignore the rest of the article. One of the reasons I don't recommend deleting records in production is because they quite often are referenced by other records. For example, a Vulnerable Item reference a Discovered Item. In reality, I would bet your Remediation Team members do not use this reference anyways, so it should be fine. Unless.... you are using that field in your Assignment Rules and intend to re-run your assignment rules. The point here is that you need to understand the impact of deleting records in production.
You should not need to change the ACL. You should be able to run a Fix Script to delete just the Discovered Items and use Auto Flush on the unclassified hardware items.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-07-2022 02:23 AM
Here is an article on deleting VR data:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0820838
If you will be doing this in production, make sure you have tested this first in your lower environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-08-2022 12:29 AM
Thank you for introducing the URL.
I understand that this article describes how to delete all Vulnerability Response related records, including Discovered Items.
This time, I just need to delete some records of Discovered Item, but is there no such method or recommended?
If you don't recommend it, do you know what the risks are when you configure and remove ACLs?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-08-2022 02:28 AM
Hi,
I hoped that you would extract just the information you needed to delete the DI and ignore the rest of the article. One of the reasons I don't recommend deleting records in production is because they quite often are referenced by other records. For example, a Vulnerable Item reference a Discovered Item. In reality, I would bet your Remediation Team members do not use this reference anyways, so it should be fine. Unless.... you are using that field in your Assignment Rules and intend to re-run your assignment rules. The point here is that you need to understand the impact of deleting records in production.
You should not need to change the ACL. You should be able to run a Fix Script to delete just the Discovered Items and use Auto Flush on the unclassified hardware items.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-10-2022 11:40 PM
Thank you for your reply.
Sorry for my late reply.
Well, the deletion itself is possible using the Fixed Script.
Also, it is necessary to understand the impact of deleting it.
Since I have never used Fixed Script, I would like to understand how to use it first.
Thank you very much.