Can we delete vulnerable item detection records that were not updated for more than an year

[sath]

Hi,

We have more than 2.8 million records in vulnerable item detections and more than 1.6 million records were in closed state for more than an year. We are considering to implement auto delete rule on vulnerable item detections (sn_vul_detection) that delete the records that were in closed state and not updated for more than an year.

Would like to understand if there would be any repercussions by implementing this rule?

Also, want to make sure if the Vulnerable Item would remain in the instance even though the detection is deleted?

[kmohammed]

Hi sath,

Yes, you can do this, and with the condition you describe it is the standard way to control the size of sn_vul_detection. A Table Cleanup rule (sys_auto_flush) on sn_vul_detection with a condition like State is Closed AND sys_updated_on older than 365 days is the right mechanism - do not do this with a scripted delete.

On your second question, the Vulnerable Item will NOT be deleted. sn_vul_vulnerable_item is the parent record and detections are child evidence records that reference it. The cascade runs the other way: deleting a VIT removes its detections, but deleting a detection never deletes the VIT. The VIT keeps its own state, assignment, and its first found / last found values.

The repercussions to plan for are these:

1. You lose the evidence, not the item. Proof, scanner/source, port and the per-detection first/last found history are gone for those 1.6M records. A closed VIT that is audited later will no longer have the detection that proved the finding. If you have audit/retention obligations, archive or export the detections before the cleanup deletes them.

2. Some VITs will be left with zero detections. That is functionally fine for a closed VIT, but run a count in a sub-production clone first so you know how many VITs lose their last detection, and check any reporting you have that is built on sn_vul_detection rather than on the VIT - those historical numbers will drop.

3. Rescans still work as normal. If a scanner reports the same vulnerability on the same CI again, VR creates a fresh detection and the normal VIT reopen logic applies. What you lose is continuity - the new detection starts with a new first found, even though the VIT itself keeps its original dates.

4. The delete itself is the operational risk. 1.6M rows is a large delete: test the exact rule on a clone, let auto-flush work through it in its scheduled batches, and avoid a one-off deleteMultiple() during business hours.

So: safe for the VITs themselves, as long as you are comfortable losing the detection-level evidence and you stage it through a clone first.

Regards,

Karimuddin