Help to understand flow from tenable to SNVR to VUL/VIT assigned to CI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
I know this is a shot in the dark but I have inherited providing support when VUL tickets are assigned mostly when the VUL is assigned to a non-matching CI. Where do I start to reverse engineer? Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hey @MitchPautz,
Start with the Discovered Item record sitting behind the VIT, not the CI or the vulnerability itself, that's where the mismatch actually gets decided. Tenable data lands in sn_sec_cmn_discovered_item, and on every import the integration first checks the Source ID field for a prior match before it ever touches the CMDB. If there's no prior match, it runs your CI Lookup Rules (Security Operations > CMDB > Lookup Rules, table cmdb_ci_lookup_rule), lowest order first, and stops at whichever rule returns exactly one CI. Open the Discovered Item and check the Source Data field plus which rule actually fired. In practice, wrong-CI assignments almost always trace back to rule order: an IP-based rule sitting ahead of MAC or hostname rules, matching on a shared or reused IP and landing on a NIC or some low-level network device instead of the real asset. Reorder so MAC and NAME rules run before IP, then use the Reapply CI Lookup Rules action on the affected records to reprocess without waiting for the next scan cycle. Also worth checking the sn_sec_cmn.ignoreCIClass property, it can exclude noisy classes like load balancers and NICs from ever being eligible as a match, and honestly a messy CMDB is the other half of this problem more often than people expect.
Thank you,
Vikram Karety
Octigo Solutions INC
