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 or GitLab) 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 GitLab 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.

GitLab's scopes for API access don't differentiate between "read" and "write" access, hence, even as we only read data from your commit diffs, we have to use whole API access to read it ("read" access only lets us clone repositories, which we do not do).

For GitHub:

• "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)

For GitLab:

• "api" access grants us access to read data from your repositories via the API.
• "openid" access grants us access to authorize your account via OAuth.
• "read_user" access grants us access to your /user endpoint, letting us fill out your user profile.

These authorization scopes are pretty broad and cannot be constrained to specific actions. 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 and GitLab's token scopes. You can revoke all of these permissions at any time via your authorized applications settings page on GitHub, or your applications page on GitLab, but doing so may result in an interruption of service.