Bugcrowd

Overview

Nucleus enables you to regularly sync findings reported by security researchers in your Bugcrowd programs into your Nucleus console using an automated connector. The connector uses the APIs provided by Bugcrowd to seamlessly sync data into various Nucleus projects for use in analysis, triage, automation, and reporting.

Connector Setup

Connector Setup Checklist

Follow the steps in this checklist to successfully set up this connector:

1. API Access
   Create API Credentials in Bugcrowd Crowdcontrol.
   

2. Connector Configuration
   Create and configure the connector in your Nucleus project.
   

3. Data Ingestion
   Create one or more ingest rules to sync findings reported in programs from Bugcrowd.

1. API Access

1. Login to Bugcrowd Crowdcontrol.

2. In the top right of the menu bar, select the dropdown box for your user icon and select API Credentials.

3. Under the section Add credentials, enter an App name such as Nucleus Connector and click Create credentials.

   

4. Make a copy of the API Token displayed under HTTP Authorization Header without the leading “Token”.

2. Connector Configuration

1. Open Nucleus and go to Integration Hub > Connector Setup.

2. Under the Scanners section, click the Bugcrowd icon. You will see the following popup:
   

3. In the Setup Bugcrowd Connector popup, enter the following information:

   Field	Description
   Name	Enter an optional name for your connector.
   Description	Enter an optional description for your connector.
   Instance URL	Leave this URL as is.
   API Token	Enter the API Token you created in API Access. It should be in the form <username>:<password>

4. Click Verify Credentials.

5. Click Save.

3. Data Ingestion

1. Go to Integration Hub > Import via Connector.

2. Select the Bugcrowd connector you just created.

3. Select the method that you want to import:

   1. All Submissions

   2. Program

   

4. Select a schedule to import data into the project.

5. Click Save & Finish.

Connector Behaviour

Status Mappings

Finding states in Bugcrowd are mapped to Nucleus statuses according to the below table:

Status Persistence

As Bugcrowd is predominantly a workflow tool for triaging and managing individual custom vulnerability reports, the finding status persistence logic for findings that are ingested from Bugcrowd operates differently to the documented behaviour for other ingestion sources.

Rather than status changes that are set by users or automation rules persisting over changes in Bugcrowd, the most recently made status change from either tool will persist within Nucleus.

For example, suppose a finding was initially set to Triaged in Bugcrowd and is ingested into Nucleus and mapped as Waiting For Verification. A user then changes the status of the finding to Potential in Nucleus. Later, another user changes the status in Bugcrowd from Triaged to Not Applicable. On the next ingestion event, the status in Nucleus will change from Potential to False Positive.

This logic occurs based on the timestamp that the status was changed rather than the ingestion date, so changes made in the intervening time between ingestion will not change if the timestamps are out of order relative to the change in Nucleus.

Uniqueness, Matching & Tracking

As the findings that come from Bugcrowd are always unique reports submitted by a researcher, the logic for asset and finding uniqueness, matching and tracking operates differently to other data sources.

Each finding from Bugcrowd will always map one to one with a finding in Nucleus, and will be pinned to the initial asset it is attributed to. On subsequent ingestion, the finding will be updated, but the finding will not appear on other assets or move from asset to asset. This will be the case even if the asset identifier in Bugcrowd changes.

From time to time findings that have no asset identifier in Bugcrowd will be ingested in to Nucleus. When this occurs, Nucleus will create a new stub asset with the name Bugcrowd Asset {id} where {id} is the unique finding identifier attributed to the finding in Bugcrowd. Similar to the above behaviour, this finding will now always map to this asset, however the finding can be "moved" to other assets by merging this stub asset with another asset of the same type. On the next ingestion, the finding will then map to the merged asset.

As a consequence of this unique logic, ingestion events that appear on the Import History page will only show differentials even if the generated scan file contains more than what is listed on the page.