We've designed our platform with multiple layers of protection to keep your data secure. Our in-depth defense approach includes physical security at our secure facility, encrypting all data in transit (via HTTPS), industry standard protection including firewalls, network vulnerability scanning, network security monitoring, and intrusion detection systems.

The development team at Static Object has access to the main Static Object database, which stores data per the policies outlined in the "Where is my data stored?" question. Users can configure whether Static Object developers are permitted to simulate account login for the purposes of debugging problems you may report to us. If you prevent simulated login, we will be unable to assist in debugging most account-related issues, but we leave that choice up to you.

As we analyze your code, we store lines that are relevant to the specific commits being analyzed. We do not clone or check out repos in whole. The source code lines we store are transformed using a one-way hash algorithm that allows us to detect revised lines without keeping the original content of those lines in our database. Any code line content we store is purged from our database via a scheduled cron job based upon the time of creation. If you request to view a commit that lies outside the storage window, we recreate your specific commit content from its source (i.e., GitHub) at that time. Thus the reason that viewing older commits in your repo may require a 1-3 minute delay while we reconstruct their content.

We expect to have native 2-factor auth implemented by November. It would have been higher on our development roadmap if not for the fact that both Google and GitHub (our available login services) implement their own 2-factor options. Assuming that you have enabled 2-factor on the service used to create your Static Object account, you will incur 2-factor security by proxy when accessing Static Object.

GitHub's permission scopes don't allow us to specify fine-grained read/write permissions, which means we need read/write for your entire repo to enable our code analysis.

Specifically, write access to your repo allows us to create a webhook that notifies us of relevant events (i.e., push events, new branches, merges, etc). It also allows us to post comments on commits on your behalf.

• "Write" permissions: create webhooks on repos/organizations so we're notified of relevant events, post comments on commits to GitHub.
• "Read" permissions: list public and private repos and organizations, read source code, read public user data (name, avatar).
• Repo: Grants read access to repo, commit statuses.
• User:email: Grants read access to a user's email address so we can contact you if you request to be notified (e.g. there is a new Static Object user from your org)

GitHub's authorization scopes are pretty broad and cannot be constrained to specific organizations. However, we will never create pull requests, merge pull requests, or delete branches without your explicit approval. Here's some information on GitHub's authorization scope. You can revoke all of these permissions at any time via your authorized applications settings page on GitHub, but doing so may result in an interruption of service.