Findings come inVulnerability management
Tenable
Ingests Tenable's host and network findings, deduplicates them against everything else that reports the same CVE, and gives each one an owner and a deadline.
What the connector does
- Vulnerabilities from the scans and asset groups you name
- Host identity resolved to the platform's own asset fingerprint, so one machine is one asset
- CVEs enriched with EPSS and CISA KEV before anything is prioritised
- Findings that a later scan no longer reports become closure candidates
Credential required
Tenable access and secret keys with read permission on the scans you name.
What this connector is for
Tenable is very good at telling you what is wrong with a host. It has no view of the application that runs on it, the team that owns that application, the ticket somebody opened last week, or whether the CVE is being exploited today. Those are the four things that decide what gets fixed first.
What is ingested
Vulnerability results with their plugin identifiers, CVEs, affected hosts and ports. Host identity is the part that matters most: the same machine reported by Tenable, by an RMM agent and by a cloud inventory has three different names, and the platform resolves all three to one asset before counting anything.
What happens next
Each vulnerability becomes a finding on that asset. The CVE is enriched from EPSS and the CISA known-exploited catalogue, and the resulting priority reflects exploitability rather than CVSS alone — which is what stops a queue of five hundred "critical" findings from meaning nothing. Routing opens a ticket in your own tracker, and the SLA clock starts.
What you have to grant
Read-only API keys. The connector does not launch scans in Tenable, does not change asset groups, and does not mark anything fixed there.