---
title: "Bugcrowd"
slug: "bugcrowd"
tags: ["connectors", "bugcrowd", "connector setup", "bug bounties"]
updated: 2025-06-24T17:16:08Z
published: 2025-06-24T17:16:08Z
canonical: "help.nucleussec.com/bugcrowd"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.nucleussec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://identity.bugcrowd.com/login?user_hint=tracker).
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.**

![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/image(401).png)
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: ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/image(402).png)
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:

![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/image(403).png)
  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:

| **Bugcrowd Status** | **Nucleus Status** |
| --- | --- |
| New | Active |
| Triaged | Waiting For Verification |
| Unresolved | In Progress |
| Resolved | Mitigated |
| Not Reproducible | False Positive |
| Not Applicable | False Positive |
| Out of Scope | Accepted Risk |
| Informational | Accepted Risk |

### 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](https://help.nucleussec.com/docs/finding-statuses#finding-statuses).

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.

## Related

- [Overview](/connectors-overview.md)