dbt

Security Bug Bounty Program

Overview

dbt Labs wants to engage the security community to help improve security for our users and products. We sponsor our security bug bounty program through which we may provide rewards to security researchers who responsibly disclose valid security issues. At this time, we do not offer monetary rewards but do offer ultra-rare dbt Labs swag based on the business severity of the security issue. All rewards will be provided at the discretion of dbt Labs and are subject to change without notice. In addition, we maintain a bug bounty leaderboard and, with a valid finding and your permission, will list you on our website.

Scope and Reporting

All security testing will be conducted using black box testing methodology against our production environments. In order to have your vulnerability verified, you will need to send the report to bug-bounty@dbtlabs.com. Please make sure the subject is clear that this is a bug bounty request (e.g., Bug Bounty: XSS found in site).

All findings MUST include:

  • Repeatable, programmatic ways for the internal team to replicate and validate
  • Vulnerability title, summary, walkthrough, and impact assessment
  • Be provided in English

We ask for testers to clean up after testing, including the deletion of all accounts and data that were used for security testing.

In Scope

The following domains have been approved for testing:

  • *.dbt.com
  • *.dbtlabs.com
  • *.getdbt.com

We operate in a multi-cloud environment so ensure that you adhere to both Amazon’s Penetration Testing Policy and Microsoft’s Penetration Testing Policy. The underlying infrastructure, to include cloud hosting companies, is subject to change without notice.

Explicitly Out of Scope

  • Denial of Service (DoS/DDoS) attacks. If you believe you may have a DoS-related vulnerability then email bug-bounty@dbtlabs.com and we can assess setting up a testing environment for the test.
  • Social engineering attacks. These include anything that would require another user to be coerced into navigating to or interacting with an attack. Examples include, but are not limited to:
    • Phishing
    • Website spoofing
    • Link manipulation (e.g., changing an “l” to a “1” in a url to deceive a user)
  • Brute force attacks (e.g., to access a user’s account).
  • Accessing another user’s data by any means. If you need to test an exploit that will interact with another user then set up a second user account for testing or reach out to bug-bounty@dbtlabs.com if you need specific testing requirements.
  • Testing against dbt Labs' physical properties, employees’ properties, or data centers.

Vulnerabilities Excluded from Rewards

Depending on their impact, some of the reported issues may not qualify if they do not present a considerable amount of risk to the business. Below are some examples of non-qualifying security issues.

  • Disclosure of known public files or directories, (e.g., robots.txt).
  • Clickjacking and issues only exploitable through clickjacking.
  • CSRF on forms that are available to anonymous users (e.g., the contact form).
  • CSRF attacks that require knowledge of the CSRF token (e.g., attacks involving a local machine).
  • Logout cross-site request forgery (logout CSRF).
  • Content spoofing.
  • Login or Forgot Password page brute force and account lockout not enforced.
  • OPTIONS HTTP method enabled.
  • Username/email enumeration.
  • Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), such as:
    • Strict-Transport-Security.
    • X-Frame-Options.
    • X-XSS-Protection.
    • X-Content-Type-Options.
    • Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP.
    • Content-Security-Policy-Report-Only.
    • Cache-Control and Pragma
  • HTTP/DNS cache poisoning.
  • SSL/TLS issues, such as:
    • SSL attacks such as BEAST, BREACH, Renegotiation attack.
    • SSL forward secrecy not enabled.
    • SSL weak/insecure cipher suites.
  • Self-XSS reports will not be accepted.
    • Similarly, any XSS where local access is required (i.e., User-Agent Header injection) will not be accepted. The only exception will be if you can show a working off-path MiTM attack that will allow for the XSS to trigger.
  • Subdomain takeover without proof of exploitability.
  • Missing or incorrect SPF records of any kind.
  • Missing or incorrect DMARC records of any kind.
  • Source code disclosure vulnerabilities.
  • Information disclosure of non-confidential information.
  • Email bombing/flooding/rate limiting.
  • Google Maps API Keys.
  • Vulnerabilities that require the user/victim to perform extremely unlikely actions (e.g., bypassing default security configurations in common web browsers).

Rewards

Severities

Our vulnerability rating system uses five severities: Critical, High, Medium, Low, and Informational. We evaluate submissions and assign severity based on our assessment of business risk.

Critical

Any vulnerability that would lead to full compromise of dbt Labs application, infrastructure, or data. Examples include:

  • Gaining privileged access to infrastructure
  • Gaining remote (e.g., shell) access to containers, infrastructure, or supporting applications
  • Gaining ability to export or delete databases

High

Any vulnerability that where the compromise of a sensitive data would lead to lateral movement. Examples include:

  • Ability to steal user access keys and using them to gain access to another application within dbt Labs.
  • Gaining access to portions of the infrastructure where man-in-the-middle operations could be conducted.

Medium

Any vulnerability that would lead to compromise of a sensitive data. Examples include:

  • Ability to steal user access keys
  • Ability to change data associated with other users
  • Persistent cross-site scripting (XSS) that can access another user’s settings

Low

Any vulnerability that would lead to performance degradation or data spillage. Examples include:

  • Application vulnerability via API endpoint manipulation
  • UI bug via data input that could cause performance or security issues
  • Subdomain takeover with proof that data is flowing to that subdomain

Informational

Issues that have no specific security impact. Examples include:

  • Lack of implemented security practices that may not apply in our specific context
  • Disclosure of information about the application environment
  • Debug statements

Valid Submissions

Valid submissions will receive a response within a timely manner (usually a week). Once a submission has been assessed a severity by dbt Labs, if it is assessed Low or higher, then we will request the following information to reward the bounty. Information requested will include:

  • Full legal name
  • Physical address
  • Phone number (required by carrier for delivery)
  • Approval to add you to our Acknowledgements page
    • Preferred name (what you would like to be called on our Acknowledgements page)
    • Link to your personal profile (e.g., LinkedIn)

Legal Disclosure

We are unable to issue rewards to individuals who are on US sanctions lists, or who are in countries on US sanctions lists (e.g., Cuba, Iran, North Korea, Sudan, Syria). You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your eligibility for the program depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to reward is entirely at our discretion. dbt Labs rewards bug bounty hunters on a first-come, first-served basis, so if you report a vulnerability that is already known, it is not eligible for reward. There is no guarantee of a reward if a report is submitted. We will not share findings from other submitters.

Your testing must not violate any law, disrupt our systems, or compromise any data that is not your own.

If you have any questions, please contact bug-bounty@dbtlabs.com.

Definitions

  • Black Box. Type of testing where we share no sensitive information with the testers. We do not grant special accesses and the main goal is to test from the perspective of an attacker who has no internal knowledge of the systems.
  • Business Impact. A qualitative assessment of how a vulnerability will impact the business based on mitigating controls, quantitative assessments (e.g., CVSS), environmental factors, and other internal metrics that could be used to assess the impact of the vulnerability.