Tenable "finding_id" in Vulnerability Response

D_SantiagoHQY
Tera Contributor

3 hours ago

We are trying to find where the Tenable "finding_id" is stored within the Vulnerability Response tables.
Does anyone know? Or has anyone figured out how to modify the Tenable Integration Processes to include the Tenable "finding_id" on the Detection Table? There are several fields like that, where they are listed in the JSON attachment for the Vulnerability Integration Process, but the values don't end up in any table. 

If anyone has guidance on how to customize the integration or where the Tenable "finding_id" is stored in VR, it would be greatly appreciated!

0 Helpfuls
  • 85 Views
1 REPLY 1

Ana39
Tera Expert

2 hours ago

 

From what I’ve seen, the Tenable finding_id is typically present in the raw JSON payload/attachment during ingestion, but it is not mapped by default into the standard VR detection tables. ServiceNow preserves only a subset of the payload fields during transform/import.

The important part:

  • Detection records live mainly in:
    • sn_vul_detection
    • sn_vul_vulnerable_item
  • Raw ingestion/intermediate data is often stored temporarily in:
    • sn_vul_entry
    • import/intermediate tables
    • attachment JSON on the integration run

But finding_id is usually not persisted out-of-box into a dedicated column.

A lot of Tenable metadata gets discarded unless explicitly mapped during the IntegrationHub ETL / parser phase.

What is probably happening

The Tenable API payload includes something like:

 

 
{
  "finding_id": "abc123",
  "asset_uuid": "...",
  "plugin_id": "...",
  ...
}

But the VR integration pipeline only maps supported fields into:

  • detection key
  • proof
  • port
  • protocol
  • asset
  • vulnerability
  • etc.

Per ServiceNow docs, the Tenable detection key itself only uses:

  • Vulnerability
  • Port
  • Protocol
  • Asset ID

—not finding_id.

So unless customized, the value disappears after ingestion.

Best approach (recommended)

Create a custom field on:

  • sn_vul_detection
    • example: u_tenable_finding_id

Then customize the ingestion mapping.

Where to customize

Usually one of these places depending on VR version:

1. IntegrationHub ETL Transform Maps

Look for:

  • Data Sources
  • Import Sets
  • Transform Maps
  • ETL Definitions

Related to:

  • Tenable.io
  • Tenable.sc
  • Vulnerability Response Integration

2. Script Includes

Common places:

  • sn_vul.*
  • sn_sec_cmn.*
  • Tenable-specific parser classes

Search for:

 

 
finding_id

or

 

payload

or

 

 
detection

inside Script Includes.

3. Identification / Detection Creation Logic

Sometimes the detection object is built in a script like:

 

 
detection.setValue(...)
 

That’s where you inject:

 

detection.u_tenable_finding_id = source.finding_id;

Super useful debugging trick 🔥

During an ingestion:

  1. Open the Integration Run
  2. Find the attachment/raw payload
  3. Confirm finding_id exists
  4. Then trace where it disappears

Usually it vanishes between:

  • import set row
    → transform
    → detection creation

Another VERY important thing

Be careful modifying the OOB detection key logic.

If you accidentally include finding_id in correlation logic, you can create:

  • duplicate detections
  • duplicate VITs
  • broken reopen/close behavior

So:
✅ store it as informational metadata only
❌ don’t use it as correlation unless absolutely necessary

What I would personally do

Minimal-risk customization:

Step 1

Add field:

 

 
sn_vul_detection.u_tenable_finding_id

Step 2

Find the final detection creation script.

Step 3

Map:

 

 
if (source.finding_id) {
    detection.u_tenable_finding_id = source.finding_id;
}

Step 4

DO NOT touch:

  • detection key
  • VI matching
  • correlation identifiers

Quick way to locate the exact script

Search in Studio / Scripts Background for:

 

 
sn_vul_detection

and:

 

 
insertDetection
createDetection
DetectionBase
Tenable

A lot of VR ingestion eventually funnels through DetectionBase-style logic depending on version

0 Helpfuls