Skip to content
GitStart's Documentation
GitHubTwitter

Security

We take security seriously. When we work on code for you, we keep it safe by only copying the parts we need to fulfill the work requested. GitStart developers can only see a fraction of your codebase, a copy “sliced” at a particular moment, and how much they see will always be in your control.

When you sign up, you must agree to our legal terms and terms of service. Our terms cover many aspects ranging NDAs and other warranties for the protection of your copyrights, patents, or trade secrets, as well as payment terms and more. Any information in this documentation is superseded by them.

Our terms of service can be found at https://gitstart.com/terms.

AI Usage

We utilize AI in various parts of our workflow and continue to roll out AI features. We exclusively use Microsoft Azure and do not under any circumstances all your code or IP to be utilized to train any publicly available models. Any AI interaction on behalf of our Developers is exclusively routed through our APIs to ensure no leakage.

Code security

To keep your code safe, we use a combination of technology and process.

In summary, we use internal tooling to create a copy of your repository, which we call a “slice.” Developers work on their own local machines, on a “slice” or copy of parts of your code base, as described above. There is a strictly limited set of developers and technical support employees who have access to this copy.

Slicing your repository

When you create an instance, you get to define and control which parts of your repository or repositories you want to give GitStart access to.

We developed secure internal tooling that enables us to pull and push code to your repository without getting access to your entire codebase and history. You specify which paths from your code repository can be shared and synced. Thus, developers can only see a fraction of your codebase, a copy “sliced” at a particular moment. How much they see will always be in your control.

Manually configuring which portion of your repository to share

While we work on automating this process, you can also define and share with us a git-slice.json file that includes the necessary configuration. The template for such a file is included below.

Our developers will only be able to see the files and folders you specify in the folders array.

The configuration JSON file should follow the schema:

{
  "$schema": "<http://json-schema.org/draft-06/schema#>",
  "title": "Gitslice",
  "type": "object",
  "description": "The configuration options for Gitslice",
  "additionalProperties": false,
  "properties": {
    "repoUrl": {
      "type": "string",
      "description": "The link to your codebase repository",
      "format": "uri",
      "qt-uri-protocols": ["https"],
      "qt-uri-extensions": [".git"]
    },
    "folders": {
      "type": "array",
      "description": "An array of file and folder paths that you can securely share and our developers will work on",
      "items": {
        "type": "string"
      }
    },
    "branch": {
      "type": "string",
      "description": "The specific branch we should GitSlice from your repository"
    },
    "ignore": {
      "type": "array",
      "description": "An array of file and folder paths we should not slice. These are the files that you want to avoid sharing with us",
      "items": {
        "type": "string"
      }
    }
  },
  "required": ["repoUrl", "folders", "branch", "ignore"]
}

This is an example of what the GitSlice configuration JSON file might look like:

{
  "repoUrl": "https://github.com/{yourOrganization}/{yourRepo}.git",
  "folders": ["folder/test"],
  "branch": "dev",
  "ignore": ["CODEOWNERS"]
}

Developer access

Developers will always have access to a fraction of your code base, isolated from the rest of your team and never interacting with them or stepping on each others’ toes.

Our developers are manually vetted and assigned to your instance and are under strict contractual obligations to keep your code safe. Please see the section about the GitStart developer community for more information about this.

GitHub Repository security

These are some of the practices we follow in GitHub to keep your code safe:

  • GitHub Repository Permission
    • Base permission within the organization where we slice your repo is set to “No Permission.”
    • All sliced repositories are private by default.
    • Only selected members with explicit access to the repository can view it. Currently, the people who are granted access are:
      • Developer(s) with write access,
      • Technical project manager(s) with maintainer access,
      • Client success team with admin access.
  • Two-factor authentication
    • We require two-factor authentication for everyone in the GitStart organization.

Code Ownership

You own the code GitStart writes. From a practical standpoint, however, GitStart will appear as the code author in git blame authorship as a constraint imposed by git. Rest assured that developers are fairly compensated for their work and that you own the code.

Please refer to legal terms for a more detailed explanation of code ownership.

Remember: you are always in control

You drive the process in the following ways:

  1. You control which tickets you assign to us. When you assign us tickets from issue-tracking software, we copy the bare minimum information needed to work** We copy only the tickets explicitly assigned to us, along with information that developers need to deliver the work, e.g., ticket title, description of work required, and any additional files and media.

  2. You must approve the cost of each PR. No PR gets merged without explicit cost approval from you. You can approve or reject the estimate until you reach an agreement based on the requirements outlined in the ticket.

  3. You define which portions of your repository we have access to. You can give or take away access, but the sliced portion still needs to work locally for development.

  4. You can request changes if you are not happy with the work. We will work with you to find a solution that works for both of us.