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.
*** Add endpoints ***
Vulnerability Parsing
Much like other XML parsers when hitting the 'vulnerability' tag we pull the following data:
...
Note |
---|
|
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.
Status | ||||
---|---|---|---|---|
WH Vulnerability | Open | Closed | Open | False Positive |
WH Attack Vector 1 | Open | Any Value | NOT Open | Any Value |
WH Attack Vector 2 | Any Value | Any Value | NOT Open | Any Value |
WH Attack Vector 3 | Any Value | Any Value | NOT Open | Any Value |
ThreadFix Finding | Open | Closed | False Positive | False Positive |