New API version released 2021-10-28

Add visibility_scope attribute to comment

Previously there were only 2 visibility scopes for a comment resource: bugcrowd staff, customer (private) or bugcrowd staff, customer, researcher (not private).

Now we’ve introduced more fine grained communication between parties on a submission. The short names of the visibility scopes that exist are: bugcrowd, everyone, bugcrowd_and_customer, bugcrowd_and_researcher. To access this information get the visibility_scope attribute on the comment resource e.g. fields[comment]=author,visibility_scope

Add create comment endpoint POST /comments

Added a new endpoint for creating comments on submissions. Here is an example creating a comment only visible to Bugcrowd staff and your team:

POST /comments
{
  "data": {
    "type": "comment",
    "attributes": {
      "body": "markdown _enabled_ body",
      "visibility_scope": "bugcrowd_and_customer"
    },
    "relationships": {
      "submission": {
        "data": { "type": "submission", "id": "A_SUBMISSION_UUID" }
      }
    }
  }
}

Add external_issue relationship to submission

Added the external_issues relationship to the submission resource. An external_issue is a link from a submission to an external entity through an integration. This is common for Jira, GitHub, and many other types of integrations offered. The external_issue resource also has a relationship to the integration so you can tell what type of integration it belongs to.

To access this new relationship you can use the fields and include parameters wherever submission resources are returned. For example: GET api.bugcrowd.com/submissions?fields[submission]=external_issues&fields[external_issue]=remote_url&include=external_issues This would return the remote_url for all accessible submissions:

{
  "data": [
    {
      "id": "A_SUBMISSION_UUID",
      "type": "submission",
      "relationships": {
        "external_issues": {
          "data": [
            { "id": "AN_EXTERNAL_ISSUE_ID", "type": "external_issue" }
          ],
          "links": {
            "related": {
              "href": "NOT IMPLEMENTED YET",
              "meta": {
                "count": 1,
                "total_hits": 1
              }
            }
          }
        }
      }
    }
  ],
  "included": [
    {
      "id": "AN_EXTERNAL_ISSUE_ID",
      "type": "external_issue",
      "attributes": {
        "remote_url": "https://example_co.jira.com/issues/123"
      }
    }
  ],
  "links": {
    "self": "/submissions"
  }
}

Add event based webhooks

Previously events were only accessible through the activity resource as a relationship, but the event resource body was not includable. The ability to include the event resource through the activity resource is planned for a future version.

Now you can receive events in real time as webhooks for the following event types:

  • blocker.created
  • blocker.updated
  • submission.created
  • submission.updated

To set up webhooks go to your integration settings for a program: tracker.bugcrowd.com/PROGRAM_CODE/settings/integrations/outgoing_webhooks

webhooks documentation

Add filter and sort by latest activity to submission index

On the /submissions index endpoint, you can now filter by latest activity timestamp on the submission. You can also sort by the latest activity timestamp.

Example:

api.bugcrowd.com/submissions?filter[updated]=from.2021-01-01T00:00:00Z&sort=updated-desc

Add jira to submission source attribute values

We have added a new source jira for submissions because we can now import issues from Jira integrations. You can now use the jira key in the source filter on the /submissions endpoint. In previous versions jira is not allowed as a filter, and submissions imported from Jira will be returned with api as the attribute for source.

Add download_url to FileAttachment

To replace the s3_signed_url, we’ve added a download_url attribute to the FileAttachment resource that will redirect to an s3 link with a shorter expiry.

An authenticated endpoint that looks like files.bugcrowd.com/:file_attachment_id

To use this URL you must include the API ‘Authorization’ header and it will redirect to a signed s3 URL with a 10 second expiry. This way you can store the download_url and it will not expire, but the s3 link is kept secure.

WARNING: DO NOT USE cURL -L to follow the s3 redirect CVE: https://curl.se/docs/CVE-2018-1000007.html

Versions below 7.58.0 automatically forward the authorization headers

In later versions we will introduce OAuth which will somewhat mitigate the risk involved with the authorization header as it will expire.

Change wont_fix to informational

In previous versions the wont_fix state was used to describe valid vulnerabilities that were not going to be actioned by the developers.

Now the state is called informational. Creating submissions with a value of wont_fix for the state attribute or filtering by state value of wont-fix will now result in a 400 level error.

This also applies to fetching the transition timestamp field. Previous: last_transitioned_to_wont_fix_at New: last_transitioned_to_informational_at

Deprecate s3_signed_url on FileAttachment

The attribute s3_signed_url on the FileAttachment resource has been deprecated and will be removed in later versions. Instead, use the download_url which requires the Authorization header and will redirect to a signed s3 URL with a shorter expiry.

Remove invited-asc and invited-desc sort options from programs index

In previous versions, the /programs#index endpoint supported the sort options: invited-asc and invited-desc, but they did not work correctly and were essentially, ignored.

Now these sort options have been removed and using them will result in a 400 error. They also will not be mentioned in the available options of the sort parameter.

Add maximum page offset error

Previously the API would return an HTTP 500 error when paginating beyond 10,000 records.

Now it will return an HTTP 400 error when passing a page[offset] greater than 9,900.

Learn more here

Fix data type error when value is not an object

Previously when the top level data property value was not a valid object (a string for example), the API would return an opaque 500 error. Now the API will return a 400 level error noting the incorrect data type.

Fixed schema error for nullable fields

All fields where nullable is true were not returning the correct errors when the type is incorrect. Now when providing an incorrect type for a nullable field, you will receive an informative 400 error.

Example:

{
  "data": {
    "type": "submission",
    "attributes": {
      "severity": "2"
    }
  }
}

This will now return:

  The property '#/data/attributes/severity' of type string did not match one or more of the following types: integer, null."

Fix relationship default order

Fixes the default ordering of objects under the relationships key for all resources to be ordered by the created_at attribute. Previously relationships were ordered by the id attribute (UUID format) resulting in inconsistent ordering. Now all relationships will be returned in a consistent order.

Fix submission state filter when value is new

This is a bug fix being backported to all versions since filtering submissions by the new state was returning no submissions. Now the correctly filtered collection of submissions will be returned.

In previous versions, when viewing a Submission resource that belonged to an in-accessible program within an accessible organization, the Submission resource would expose values hidden under the same circumstances in the Tracker UI.

Now the same principal is applied in the API response, so the following fields will only be available on submissions belonging to programs directly accessible by the user.

  • bug_url
  • custom_fields
  • description
  • extra_info
  • http_request
  • remediation_advice
  • researcher_email
  • vulnerability_references
  • assignee
  • activities
  • comments
  • monetary_rewards
  • file_attachments

The title field will read as 'Original submission in another program'.

This is relevant on submission duplicates that are referenced from another program.

Remove researcher_email from submission

Previously we would return the researcher_email attribute on the submission resource because for submissions created through the API, this field is given by the API user. However, for submissions created through the external submission form, this data is provided by the researcher and should not be shared.

Now the researcher_email field will not be returned and requesting it in the fields parameter will result in a 400 error.

Scope included targets to user program access

In previous versions it was possible to use the include parameter to include submissions on a target.

Since the submissions on a target can be on other programs within the organization this would constitute elevated access.

Now when including submissions on a target only submissions that the user has access to are included.

Visit bugcrowd.com