Security at Deepnote

Protecting your account

We made a decision to not support password login and only use trusted third party login providers, Google and Github. Both support several means of multi-factor authentication (MFA) and have a solid level of security against brute force, or credentials stuffing attacks.

Access control for projects

Projects have granular role-based access control (RBAC) settings, to allow you to choose what your collaborators can and cannot do. For more details, see the relevant documentation.

Defense in depth

As we understand that no system will ever be 100% secure, we try to apply defense in depth in design of our apps. One specific example is how we approached identifiers: while we perform authorization checks on all endpoints, Ds for users or projects are high entropy UUIDs. This assures that even if an IDOR would occur in one of our applications, any large-scale exploitation would be much more difficult than with sequential identifiers.

Protecting your privacy

You control and own your data and, whether it’s your personal or work information, we’re committed to keeping it private. Our privacy policy describes when we collect your information and why.

Protecting your source code, data and secrets

All files in Deepnote are encrypted at rest, whether they are files you create there or anything you upload. The keys are managed and rotated automatically by our Cloud Service Provider.

For sensitive information (such as database integrations or environment variables), we apply a layer of AES-256-CBC encryption before storing them in our database. Decryption keys are stored separately.

All data transmitted between Deepnote and our users is protected using Transport Layer Security (TLS), and our Strict-Transport-Security (HSTS) settings assure that your browser will never send an unencrypted request to us.

Rigorous security testing

We perform security testing on a regular basis to identify and patch any vulnerabilities in our stack. We also work with third-party security specialists to keep Deepnote users and their files safe.

Vulnerability disclosure

If you’re good enough to spot a vulnerability in our site, we’d love to know about it. Take our word on that we'll reward anyone who reports any critical vulnerability in any of deepnote.com subdomains for the first time. To be eligible for a reward, please follow the guideline below:

• To reach us, please check our security.txt file.
• If you feel like it, please encrypt all sensitive information using our PGP Key
• Provide full details of the vulnerability so that we can easily reproduce it.
• Avoid disrupting or degrading our services in any way. Given the nature of our business, denial-of-service attacks are not welcome at all.
• Please keep in mind that RCE on the container that is designed for you to execute code is not considered a vulnerability.
• Don’t copy, delete, access, or change any data that doesn’t belong to you.
• Don’t publicize any details of the vulnerability until we’ve had a chance to fix it.

Team equipment

All Deepnote team members' computers have up-to-date OS, have a strong passphrases and encrypted storage.

Team access

We follow the principle of least privilege in how we write design our cloud infrastructure and how we access it. We use Google account authentication with two-factor authentication enforced for all accesses to production systems (many of us utilize FIDO2 tokens).

Code reviews

Changes to source code destined for production systems are subject to code reviews by qualified engineering peers. We adhere to a secure development lifecycle and review the security implications of every change. Prior to updating production services, the contributors to the updated software version are required to verify that their changes are working as intended in the staging environment.