For general information & instructions on the use of Remote Providers within ThreadFix, please refer to this page's parent page: Remote Providers.

For information on REST API functionality for Remote Providers, please refer to the following: Remote Providers API

Introduction

WhiteHat doesn't manage application scanning in a typical way.  There is no concept of a scan file to indicate an atomic scan action with a start and an end, so ThreadFix must artificially create that concept.  Additionally, vulnerabilities can evolve over time within WhiteHat with multiple attack vectors being identified.  Each attack vector will have its own properties around found and tested dates and will have its own state which could be distinct from the parent vulnerability state.  ThreadFix manages all this data in a very specific way as described below.

Application Fetch

The following WH endpoint is used to fetch applications:

• https://sentinel.whitehatsec.com/api/site/
• More information here

Scan Fetch

WhiteHat does not provide an endpoint to fetch 'scans'.
Instead, it provides an endpoint that is used to fetch all vulnerabilities. We use the following endpoint and parameters to return vulnerabilities for a specific application. For EU region, substitute https://sentinel.whitehatsec.com for https://sentinel.whitehatsec.eu.

https://sentinel.whitehatsec.com/api/site/{site_id}?display_links_last_completed_scan=1&key={apiKey}

https://sentinel.whitehatsec.com/api/vuln/?key={apiKey}&display_description=1&display_solution=1&display_attack_vectors=1&display_risk=1&display_impact=1&display_likelihood=1&display_custom_risk=1&query_site=/{site_id}/&page:order_by=modified_desc

Vulnerability Parsing

Much like other XML parsers when hitting the 'vulnerability' tag we pull the following data:

• Native Id
• Vulnerability code
• Severity code
• URL reference

When the parser hits 'attack vectors', each one is parsed for the following pieces of information:

• Tested date
• Attack vector state
• Found date

Initial Scan Creation

The first time you import results for an application in WhiteHat into an application in ThreadFix, scan objects will be created on behalf of WhiteHat in one of two different ways depending on how you configure the Remote Provider connection.  

All Vulnerabilities 

If the user selected the "All Vulnerabilities" option when configuring their remote provider, then ThreadFix will create as many artificial "scan" objects as required to encapsulate all historic data for both open and closed vulnerabilities in WhiteHat.  The way scans are defined when pulling old data from WhiteHat is based on a grouping we perform around the WhiteHat vulnerabilities and their attack vectors' found and tested dates.  Put simply, we bundle WhiteHat vulnerabilities into scans with a scan date based on when an attack vector was found and last tested grouped into calendar days.  

Open Vulnerabilities

If instead of "All Vulnerabilities", "Open Vulnerabilities" was selected when configuring the remote provider, ThreadFix will pull in only the open vulnerabilities in WhiteHat, and they'll be bundled into a single initial scan object.  ThreadFix will not pull in any data related to closed vulnerabilities in WhiteHat.  All subsequent imports will create new scan objects using the method described above for all vulnerability updates after the most recent import.

Determining WhiteHat Vulnerability Status

Because of the unique nature of the WhiteHat findings, some logic needed to be employed to map their concept of Vulnerabilities and Attack Vectors to the ThreadFix concept of Findings, taking into account the different States each Attack Vector could have as well as the different Found Dates and Tested Dates.  The following table describes how we determine if a WhiteHat Vulnerability is Open, Closed, or a False Positive.  It shows a hypothetical WhiteHat Vulnerability with 3 Attack Vectors within it.  The statuses of the Vulnerability and the Attack Vectors are listed, with the resultant ThreadFix Finding status listed in the bottom row.