Prevent Reopening of Vulnerable Items (VITs) from New Detections – Best Practice? Hi Team,

chepurip · 3 weeks ago

I am working on the module and have a requirement where certain Vulnerable Items (VITs) should not reopen when new detections are received from the scanner (e.g., ).

I understand that, out of the box, when a new detection matches an existing VIT (based on CI and vulnerability), the system automatically reopens the VIT even if it is in a Closed/Resolved state.

To handle this, I tried implementing a Business Rule to prevent reopening for specific scenarios. However, I am concerned that this approach may interfere with OOTB detection correlation logic and impact standard VR functionality.

Could you please suggest:

What is the recommended OOTB approach to prevent specific VITs from reopening?
Should this be handled using False Positive / Risk Acceptance (Exception) workflows?
Are there any best practices using Exception Rules or detection filters to achieve this?
Is there any supported way to conditionally control reopening without impacting the correlation engine?

Appreciate your guidance and any references or documentation.

Thanks in advance!

Vikram Reddy · 3 weeks ago

Hi @chepurip,

Skip the Business Rule, your instinct to worry about it is right, that layer sits right in the middle of the detection import/correlation logic and a custom rule there is exactly how you end up with two vulnerability groups for the same VIT down the line. What you actually want is Exception Rules, a native Vulnerability Response feature (available since the Paris release) that sits above the correlation engine instead of inside it.

The reason this fits your requirement specifically: an Exception Rule doesn't just close a VIT once, it keeps auto-deferring any VIT matching its condition on every subsequent import, including newly ingested and reopened detections that match. Detections still flow in and correlate normally against CI and vulnerability, the rule just stops the state from swinging back to Open for anything matching your condition.

Where to find it: in the Vulnerability Response application menu there's a separate Exception Rules module, listed just above Exception Management. You'll need the sn_vul.admin role to create or approve one.
What to key the condition on: whatever actually identifies "these shouldn't reopen" for you, CI, CI class, vulnerability group, source scanner, category, CVSS band, basically any field available on the vulnerable item.
Outcome: matching VITs go to Deferred once the rule is approved, and stay there as long as the rule and condition remain active.

On your other two questions: False Positive is meant as a one-time "this isn't real" call, but it isn't reopen-proof by default, if you leave a Reason and an Until date on the record, that Until date effectively schedules a reopen. Clear both before closing if you want it to stick. Risk Acceptance runs through the exception approval workflow and also lands in Deferred, that's the correct path when the finding is real but you're accepting the risk for now rather than saying it's a false positive. Either way, Exception Rules are what turn a one-off manual decision into something that keeps applying automatically without you touching the correlation code.

If it's really one vulnerability group that keeps splitting into two on reopen, that's usually an auto_refresh setting on the group rather than a reopen problem at all

References

Thank you,
Vikram Karety
Octigo Solutions INC
My Blog: glideandgen.com