Scoutinternal

Reporting Security Vulnerabilities and Bug Bounty Inquiries to BitGo

Reporting Security Vulnerabilities and Bug Bounty Inquiries to BitGo

Problem

External security researchers, penetration testers, and other third parties frequently contact BitGo support to report potential security vulnerabilities found on BitGo's website or infrastructure, ask about a bug bounty program, request responsible disclosure channels, or inquire about the security impact of industry-wide supply-chain incidents. These contacts arrive via support@bitgo.com and cover topics such as XSS, CSRF, HTTP request smuggling, database access concerns, spoofed websites, and NPM supply-chain attacks. The core need is to route these reports to the correct security team and program.

Diagnostics

  • Identify the ticket type: Read the subject line and body to determine whether the sender is (a) reporting a specific vulnerability or set of vulnerabilities, (b) asking where/how to report a vulnerability or whether a bug bounty program exists, (c) inquiring about the impact of an industry-wide security incident on BitGo infrastructure, or (d) reporting a spoofed/phishing version of the BitGo website.
  • Check for specificity: Determine whether the reporter provides concrete technical details (e.g., specific vulnerability types like XSS, CSRF, HTTP request smuggling, API exploitability, database access) or is sending a generic/templated outreach.
  • Assess whether the inquiry is from an existing client: Check whether the sender is a known institutional client (e.g., asking about supply-chain impact on their custodied assets) versus an unknown external researcher. Client inquiries about security incidents may need to be routed to their assigned Customer Success Manager (CSM) for a tailored response.
  • Check for bounty payment requests: Some contacts request payment for previously reported bugs. These should also be directed to the Bugcrowd program where bounty eligibility and payouts are managed.

Resolution

Scenario: vulnerability-security-bug-bounty#researcher-reports-vulnerability

Trigger: An external party contacts support@bitgo.com to report one or more security vulnerabilities found on BitGo's website or infrastructure, or asks where to submit a vulnerability report.

Signals: vulnerability, security disclosure, bug found, XSS, CSRF, HTTP request smuggling, database access, API exploit, responsible disclosure, report security bug, vulnerability found, security vulnerabilities in your website

Steps:

  1. Thank the reporter for reaching out to BitGo Support.
  2. Direct them to submit their findings through BitGo's official bug bounty program on Bugcrowd: https://bugcrowd.com/engagements/bitgo-mbb-og-public
  3. Do not attempt to triage, validate, or respond to the technical details of the vulnerability report within the support ticket. The security team manages all assessment and communication through the Bugcrowd platform.
  4. Close the support ticket after providing the Bugcrowd link.

Notes: Many of these reports are templated or generic outreach from researchers seeking bug bounty payouts. Regardless of specificity or perceived legitimacy, always direct to the Bugcrowd program. Do not share internal security architecture details in the support reply.

"Please share your findings in a report with our security team here: https://bugcrowd.com/engagements/bitgo-mbb-og-public" (ticket #274602)

Scenario: vulnerability-security-bug-bounty#bug-bounty-program-inquiry

Trigger: An external party asks whether BitGo has a bug bounty program, how to participate, or requests payment for a previously reported bug.

Signals: bug bounty, bounty amount, bounty program, reward, where to report security bug, bug bounty on your site

Steps:

  1. Confirm that BitGo operates a bug bounty program through Bugcrowd.
  2. Provide the program URL: https://bugcrowd.com/engagements/bitgo-mbb-og-public
  3. For questions about bounty eligibility, payout status, or program rules, advise the reporter to manage all communication directly through the Bugcrowd platform, as support does not handle bounty payments or program administration.
  4. Close the support ticket.

Notes: Support agents should not commit to any bounty amounts, confirm eligibility, or make promises about rewards. All bounty decisions are managed by the security team via Bugcrowd.

Scenario: vulnerability-security-bug-bounty#client-supply-chain-incident-inquiry

Trigger: An existing institutional client contacts BitGo to ask whether a specific industry-wide security incident (e.g., NPM supply-chain attack) has impacted BitGo's infrastructure or their custodied assets.

Signals: supply-chain attack, NPM attack, infrastructure affected, production environment, partner integrations, incident assessment

Steps:

  1. Identify whether the sender is a known client with an assigned Customer Success Manager (CSM).
  2. If a CSM is assigned, escalate the ticket to the CSM for a direct response. The CSM will coordinate with internal engineering/security teams to provide an impact assessment.
  3. If no CSM is assigned or the CSM is unavailable, escalate to the support team lead to determine the appropriate internal contact for a security-incident response.
  4. Do not speculate about impact. Wait for an official internal assessment before replying.

Notes: In the NPM supply-chain attack case documented in the tickets, BitGo's CSM confirmed: "We have completed a full evaluation of our infrastructure and confirmed that nothing is affected by this issue. Our production environment remains unaffected." Each incident requires its own fresh assessment — do not reuse prior incident responses for new events.

"We have completed a full evaluation of our infrastructure and confirmed that nothing is affected by this issue. Our production environment remains unaffected." (ticket #243183)

Scenario: vulnerability-security-bug-bounty#spoofed-phishing-website-report

Trigger: Someone reports a spoofed, cloned, or phishing version of the BitGo website.

Signals: spoofed website, phishing, fake site, cloned website, spoofed version

Steps:

  1. Thank the reporter for the notification.
  2. Escalate the ticket internally to the BitGo security team immediately, including any URLs or screenshots provided by the reporter.
  3. Do not dismiss or close the ticket until the security team has acknowledged the report.

Notes: Spoofed website reports are distinct from vulnerability disclosures and should be treated as potential active threats to BitGo customers. Time-sensitive escalation is important.

Scenario: vulnerability-security-bug-bounty#s1-soc-security-disclosure-questions

Trigger: A client or their auditors request information about BitGo's security certifications, SOC reports, custody architecture, or related disclosures for regulatory filings (e.g., S-1 disclosures).

Signals: SOC 1, SOC 2, S-1 disclosure, audit, custody solution, qualified custody, segregated account, rehypothecate, private key management

Steps:

  1. Recognize that these requests are beyond the scope of standard technical support.
  2. Escalate the ticket to the client's assigned CSM or account manager, who will coordinate with internal compliance and legal teams to provide appropriate responses.
  3. If no CSM is available, escalate to the support team lead for routing.
  4. Do not independently answer audit or regulatory disclosure questions.

Notes: In one documented case, the CSM confirmed that BitGo uses qualified custody (custodial wallets where BitGo manages all 3 keys), is SOC 1 Type 2 and SOC 2 Type 2 certified, and stores digital assets in segregated accounts verifiable on-chain. However, each client relationship may differ — always defer to the CSM for client-specific answers.

"It is a qualified custody solution, so custodial wallets, where BitGo manages and stores all 3 keys." (ticket #272756)

"Yes, BitGo is SOC 1 Type 2 and SOC 2 Type 2 certified." (ticket #272756)

Related