The purpose of this document is point the differences of how Vulcan present the data comparing to Tenable.

In this document we will cover:

  1. Introduction
  2. Number of unique vulnerabilities
  3. Number of unique assets
  4. Number of vulnerability instances
  5. Differences over time
  6. Tenable data by scan
  7. Tenable informational vulnerabilities
  8. Scans configurations


Since in both Vulcan and Tenable you can set the time frame of the history you'de like to see, please make sure they both align before comparing. (both default to 30 days).

One more thing to account for is the scan interval. Vulcan pulls the data off of Tenable once a day, and it takes some time to ingest the data. make sure that this process finished ("Connected" status on the connectors), and that you are looking at data newer than that timestamp - which cause the number of differences.

Number of unique vulnerabilities

This is the number of currently alive vuln. In the entire account. In Tenable you get to that number by navigating to the Vulnerabilities page. You'll see at the end of the vulnerabilities table a number:

In this case its 365 unique vulnerabilities. Mind that it is different than the number at the top of the table, which shows the amount of vulnerabilities instances - which we will elaborate in different sections.

In Vulcan - you should see the same number in the vulnerabilities table - under the Vulnerable tab:

Number of unique assets

Vulcan pulling Tenable data via API. Tenable's API shows only licensed assets. to get that number in the Tenable UI to compare the data properly, you\ll have to fiter the unlicensed assets out.

To do so, go to the assets table, filter to "is licensed=True".

The result will yield a number that can be compared against the Vulcan UI - in the top right widget:

Number of Vulnerability Instances

these are essentially the connection between Vulnerabilities and assets. to get that number in Tenable's UI, simply click on the vulnerability table, and look at the number called Total Count:

In Vulcan, you can see this number straight off the dashboard, in the "Vulnerability instances and risk over time" widget:

If you have more than 1 scanner, you can use the vulnerability table "export" option by filtering with the correct scanner name:

You'll get a CSV with the exact amount (remember to subtract 1 of the header).

What happens over time?

Vulnerability management is dynamic, and numbers might start to shift - what is that mean?

  • Vulnerability move to fixed - Tenable will indicate that vulnerability is fixed, Vulcan will ingest the data, and you should see the numbers align. You can drill down in each vulnerability to see the flow.
  • Vulnerability "disappeared" - there are certain cases in Tenable where the vulnerability does not report as fixed but is not here anymore. Most of the time it's due to the fact that the asset is not seen anymore. In these cases, Vulcan will treat the Vulnerability as Fixed, so it will be removed from the counts to match Tenable but will stay in the history of auditing.
  • Archiving Assets - Both Tenable and Vulcan have a setting to delete stale assets (have not been seen in the last X days). If Vulcan is set to a lower number (by default, it's not - these Vulnerability instances might still be visible in Tenable, but removed from Vulcan, which will align eventually once the Tenable Threshold will be reached.

Culprits to avoid

  • Looking at specific scan data - scan data is not what Vulcan aims to pull, Vulcan aims to pull the overall status. Scan data might be confusing since it might show "dead" hosts just so you know you scanned them - but they pose no risk since they don't exist. Tenable treats it the same way - by not adding them to the assets table.
  • Informational severity findings - These can be seen by looking in Tenable in the asset view/scan view. They are not seen in the Vulnerability table, since they are not actually vulnerabilities. Vulcan filters them out as well.
  • Scans in Tenable can be marked as "Keep private" - for the scan data. this means that the finding cannot be pulled off the API and will skew the numbers.

Did this answer your question?