Security and Trust Center

We are committed to helping customers gain confidence in the workloads they run on Databricks. If your team would like to run a pen test against Databricks, we encourage you to:

• Run vulnerability scans within the data plane systems located in your cloud service provider account.
• Run tests against your own code, provided that those tests are entirely contained within the data plane (or other systems) located in your cloud service provider account and are evaluating your own controls.
• Participate in the bug bounty program.

Join the Databricks Bug Bounty program facilitated via HackerOne and get access to a deployment of Databricks that isn’t used by live customers.

We require multifactor authentication to access core infrastructure consoles such as the cloud service provider consoles (AWS, GCP and Azure). Databricks has policies and procedures to avoid the use of explicit credentials, such as passwords or API Keys, wherever possible. For example, only appointed security members can process exception requests for new AWS IAM principals or policies.

Databricks employees can access a production system under very specific circumstances. Any access requires authentication via a Databricks-built system that validates access and performs policy checks. Access requires that employees be on our VPN, and our single sign-on solution requires multifactor authentication.
Learn more →

Our internal security standards implement separation of duties wherever possible. For example, we centralize our cloud identity provider’s authentication and authorization process to separate authorizing access (Mary should access a system) from granting access (Mary now can access a system).

We prioritize least privileged access, both in internal systems and for our access to production systems. Least privilege is explicitly built into our internal policies and reflected in our procedures. For example, most customers can control Databricks employee access to their workspace, and we automatically apply numerous checks before access can be granted and automatically revoke access after a limited time.
Learn more →

Databricks leverages an Ideas Portal that tracks feature requests and allows voting both for customers and employees. Our feature design process includes privacy and security by design. After an initial assessment, high-impact features are subject to Security Design Review from a security expert in engineering, along with threat modeling and other security-specific checks.

We use an agile development methodology and break up new features into multiple sprints. Databricks does not outsource the development of the Databricks platform, and all developers are required to go through secure software development training, including the OWASP Top 10 at hire and annually thereafter. Production data and environments are separated from the development, QA and staging environments. All code is checked into a source control system that requires single sign-on with multifactor authentication, with granular permissions. Code merge requires approval from the functional engineering owners of each area impacted, and all code is peer reviewed.

We run quality checks (such as unit tests and end-to-end tests) at multiple stages of the SDLC process, including at code merge, after code merge, at release and in production. Our testing includes positive tests, regression tests and negative tests. Once deployed, we have extensive monitoring to identify faults, and users can get alerts about system availability via the Status Page. In the event of any P0 or P1 issue, Databricks automation triggers a “5 whys” root cause analysis methodology that selects a member of the postmortem team to oversee the review, and follow-ups are tracked.

We use best-of-breed tools to identify vulnerable packages or code. Automation in a preproduction environment runs authenticated host and container vulnerability scans of the operating system and installed packages, along with dynamic and static code analysis scans. Engineering tickets are created automatically for any vulnerabilities and assigned to relevant teams. The product security team also triages critical vulnerabilities to assess their severity in the Databricks architecture.

Databricks has a formal release management process that includes a formal go/no-go decision before releasing code. Changes go through testing designed to avoid regressions and validate that new functionality has been tested on realistic workloads. Additionally, there is a staged rollout with monitoring to identify issues at early stages. To implement separation of duties, only our deployment management system can release changes to production, and multi-person approval is required for all deployments.

We follow the immutable infrastructure model, where systems are replaced rather than patched, to improve reliability and security by avoiding the risk of configuration drift. When new system images or application code is launched, we transfer workloads to new instances with the new code. This is true both for the control plane and the data plane (see Security Features section for more on the Databricks architecture). Once code is in production, a verification process confirms that artifacts are not added, removed or changed.

The last phase of the SDLC process is creating customer-facing documentation. Databricks docs are managed similarly to code, where the documentation is stored within the same source control system. Significant changes require technical review as well as review from the docs team before they can be merged and published.
Visit documentation →