Data Security Overview

We take the responsibility of securing our customers' source code very seriously. We have designed our system with security and privacy in mind from the ground up.

Grit is proudly SOC2 Type I compliant. You can request a copy of our audit report by emailing security@grit.io.

Where is Grit hosted?

Grit is hosted on Google Cloud Platform, in the United States. We use Google Cloud's secure infrastructure to ensure the privacy and security of customer data.

You can find a full list of our subprocessors here.

How does Grit ensure the privacy and security of customer data?

Our system is designed with strong security measures including encryption at rest and in transit. We build on top of Google Cloud Platform's Cloud Security with our own additional security measures.

Our strongest security measure is running code analysis in isolated, ephemeral virtual machines. This ensures that customer repositories are never exposed to other customers and are only stored for the duration of the analysis. Once analysis is complete, the virtual machine is destroyed and the data is deleted within 30 minutes.

Where can I report security issues?

If you have a security concern, please contact us. You can reach us at security@grit.io.

What authentication and authorization mechanisms does Grit use?

We primarily rely on GitHub for authentication and authorization. Users connect to Grit through OAuth, and can access the same repositories on Grit that they have access to on GitHub. We do not allow escalation of privileges or store GitHub credentials.

For enterprise customers, we also support SAML-based single sign-on (SSO) through Auth0/Okta.

How does Grit ensure the ongoing security of its codebase?

Grit works with industry experts to conduct penetration tests on a regular basis. In addition to penetration tests, we also implement daily code reviews, static analysis checks, and dependency scanning at the code level.

Who owns source code modified by Grit?

You own all of your source code. Grit does not claim any ownership rights in your source code, nor do we assume any responsibility for your code. You are responsible for ensuring that your code complies with all applicable laws and regulations.

What data does Grit collect?

We rely on source code data, including file content and reviews, to provide our services to you. We collect data to provide the service, some of which is then saved for further analysis and product improvements.

How does Grit use the data it collects?

We use the data we collect to provide our services to you, to improve our services, and to develop new services.

There are three main categories of data we collect:

  1. Granular source code feedback. We collect source code data and user feedback to provide services to you. This data is used to track specific learnings about your code and to improve future changes generated by Grit. For example, we might observe that a particular naming convention is used in your code and retain that information to improve future changes. These specific tweaks are isolated to your account and not shared with other customers.

  2. Standard library changes. When we make changes to your code, we often apply migrations from our standard library. In some cases, we might need to refine or enhance a standard library migration to work well on your codebase. These anonymized enhancements are upstreamed to the standard library and shared with other customers. For example, if we observe that our Chai to Jest migration misses a particular test format in your codebase, we might enhance the migration to support that format and upstream the change to the standard library.

  3. Usage data. We collect information about your interactions with the Grit platform, including access dates and times, hardware and software information, device event information, log data, crash data, and cookie data. We use this information to administer and improve services, analyze trends, and track users' use of the platform. For example, we might observe that a particular screen in the Grit web application crashes when viewing a large number of files and decide to build a new screen to improve performance.