Comparing InsightVM and Tenable.SC


Posted on August 14, 2020 by

Over the years, I’ve had the opportunity to work with both Rapid7’s InsightVM and Tenable’s Tenable.SC.  At the core of these products is their vulnerability scanners, Nexpose and Nessus respectively.  I wanted to compare these two vulnerability management products and document some of the pros and cons of each one.


While both products scan your network and report on vulnerabilities, they report them in different ways.  Ideologically, InsightVM is more vulnerability focused while Tenable.SC is more remediation focused.

To illustrate, let’s say you scan a Windows host after the Microsoft monthly patches have been released.  InsightVM will list every CVE and KB covered in the monthly patches as part of its vulnerability report.  So you can have a system go from zero vulnerabilities to 30 overnight.  On the other hand, Tenable.SC will only list one new vulnerability, the monthly patch roll-up.  That one vulnerability in Tenable.SC will cover all of the CVEs and KBs in the monthly roll-up (which are also searchable in Tenable).  But in both InsightVM and Tenable.SC the fix is the same – apply the monthly patch.

Both have their advantages.  It just depends on how you want your reports to look. Because InsightVM lists every vulnerability individually, reports will have many peaks and valleys as monthly patches are released and then applied. It also generates more data that you have to sift through.  The Tenable.SC reports tend to be flatter, making unusual spikes in vulnerability numbers easier to spot.

Answering “Why is this vulnerable?”

It’s common to want to understand WHY a vulnerability scanner thought a system was vulnerable.  In InsightVM, there is the Proof field that details what setting was checked and the value that made it vulnerable. This could be a registry key, a file version, a setting, or something else.  But there is always something in the Proof field that can tell you exactly why InsightVM thinks this system is vulnerable.

Tenable.SC puts this information in the Plugin Output field.  It’s very similar to InsightVM’s Proof field, in that it lists the registry key, file version, setting etc and the value that caused it to be vulnerable.  Many times, Tenable.SC will also list the expected value that would remediate the vulnerability.  For example, a registry key would need a specific value or a file version would need to be at least version X.Y to remove the vulnerability.

While both products do a good job of explaining WHY a system is vulnerable, Tenable.SC is more useful because the value necessary to remove the vulnerability is right next to the current, vulnerable value.  You don’t have to search through KBs and blog posts to find the fix.

Risk Exceptions

Not every vulnerability can be fixed.  Some vulnerabilities and their associated risk have to be accepted.  Both products have workflows that accomplish this.

InsightVM has a very mature and comprehensive workflow for accepting what they call Exceptions.  The roles of Exception Requestor and Exception Acceptor can be separated.  The Requestor fills in a form within InsightVM and lists the details of the exception request, an (optional) expiration date for the exception, and the reason it is being asked for (Acceptable Risk, Acceptable Use, Compensating Control, False Positive, or Other).  Vulnerability exceptions can be issued per asset, per asset group, per site, or globally.  The Acceptor can then review the Exception and either accept or reject it.

Tenable.SC calls this process Accepted Risk.  They accomplish this through an internal ticketing system within Tenable.SC.  On any screen within the Analysis → Vulnerability section of Tenable.SC, a ticket can be created.  This allows you to apply any filter you want to a request.   So the request can be for a very specific set of assets and vulnerabilities.  One of the categories in this ticketing system is “Accept Risk”.  Tenable.SC doesn’t have a section to document the reason for the Accepted Risk (like False Positive or Compensating Control). That would need to be documented somewhere in the ticket description or notes fields.  After the ticket is created, the approver would review the ticket and approve or reject the Accepted Risk.  The approver would then close the ticket.  Permissions to accept risk are only for highly privileged users in Tenable.SC.  So the roles of those who submit the Risk Acceptance requests and those who approve them can be separated.  Overall it’s adequate, but less mature than InsightVM’s implementation.

Reporting on Exceptions or Accepted Risks is supported in both tools. For InsightVM, they have Reports that can be created to list all Exceptions.  For Tenable.SC, all of the Accepted Risks are listed in a Dashboard widget and in Workflow → Accepted Risk Rules.  One feature that is not currently built into either tool (but I would like to see) is notification of expiring exceptions.  This would allow for proactively reviewing the expiring exceptions before they expire.


Both tools have a good API for automation and integration.  

Rapid7 InsighVM API:

Tenable.SC API

Tenable’s API is a little easier to work with, but both allow the automation and integration of the tool within your environment. I’ve used both APIs to automate common tasks and pull information that is not natively exportable.

As of the date of this post, Tenable.SC has out-of-the-box integration with 39 different vendors.

InsightVM has integrations with 31 different vendors.

Vulnerabilities and False Positives

My experience is that InsightVM has more false positives than Tenable.SC.  I think this is because InsightVM is very aggressive in rooting out every vulnerability they can find.  They do integrate with Metasploit to validate the vulnerabilities.  That might cut down on the F+.  But just using InsightVM+Nexpose on its own generates more F+ than Tenable.SC.

I also found that Tenable.SC finds more True Positive vulnerabilities than InsightVM.  Specifically, Tenable.SC tends to find a lot more vulnerabilities related to installed applications, things like MS Office, Web Applications, Email Applications, etc.

Overall, I just trust the information out of Tenable.SC more than the information out of InsightVM.


Both tools have a mountain of data you can sift through.  So being able to find what you need is important.

InsightVM has a free search box, but you can also perform an advanced search to find specific things within specific fields.  Some of the fields you can search are IP, DNS name, CVSS score, Risk Score (Rapid7’s internally generated number to assess risk) and more.  Results are presented as a table and are exportable to CSV.

Tenable.SC does not have a free search field.  So every search will need to be done based on specific criteria like IP (full, CIDR, or range), full DNS name (you can’t wildcard DNS names in searches), plugin name (partial or full), plugin ID, CVE, and much more.  Once you’ve entered your search criteria, you can pivot to different views, like listing all vulnerabilities, grouping them by IP, or grouping by Responsible User, and more.  Search results can be exported as CSV or PDF with the ability to choose which fields you export. Once you have a filter you really like, it can be saved as a Query. One query I created listed all vulnerabilities newly discovered within the last 7 days.

Having the free search field in InsightVM is nice, particularly if you just want to perform a quick check on an asset.  But I find Tenable’s ability to pivot to different views of the data much more useful.  For example, let’s say you want to find all instances of TLS 1.0 and 1.1 in your environment. The plugin IDs for TLS 1.0 and 1.1 detection in Tenable.SC are 104743 and 121010.  A filter can be built with those two plugin IDs. The Vulnerability Summary screen will show how many assets are running each protocol.  Change to the IP Summary screen and the detections are now grouped by IP.  So you can see which assets have the most instances of TLS 1.0 and 1.1.  Switch to the Port Summary and you can see which ports have the most detections.  These different views make it easier to identify which areas to address to have the most impact.


  • InsightVM Projects

Rapid7 has a really nice feature called Projects in InsightVM.  You can build filters or add vulnerabilities ad hoc to Projects. As the vulnerabilities get remediated, it automatically updates the numbers in your Project.

  • Jira Integration

Tenable.SC integrates with Jira via a plugin.

The plugin will automatically pull vulnerabilities from Tenable.SC into a Jira project. Vulnerabilities can be imported based on severity levels. So you can import all vulnerabilities or just Critical, High, Medium, etc. vulnerabilities. It’s pretty easy to set up.  If you already use Jira, it’s a good way to track progress on your vulnerability management program.

Final Thoughts

Both tools can strengthen an organization’s security and reduce risk.  If you’re more on the Red Team side and want to leverage Metasploit, InsightVM might be the best choice.  If you’re more on the Blue Team side and are mainly interested in removing as many vulnerabilities as possible, Tenable.SC is probably the better choice.

Leave a Reply

Your email address will not be published. Required fields are marked *