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…

#### 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.