What UprootSecurity reads from your repositories
We read metadata about your repositories and pull requests. We never read your source code, and we never write anything back.
That holds for every one of the six version control tests, on GitHub, Bitbucket and Azure DevOps alike. Below is the complete list of what the connection reads and why — the answer to give whoever has to approve the install.
What we read, and why
What we read | Why |
|---|---|
The list of repositories in scope, their web addresses, and each one's default branch | To know what's being graded, and which branch is the production one |
Whether the default branch is protected | The branch protection test |
Pull requests — title, number, author, source and target branch, whether it's open or merged, when it was created, updated and merged, and the commit identifiers the checks ran against | To identify each change and place it in time |
Who reviewed each pull request, and whether they approved | The code review test — specifically, whether someone other than the author approved |
The names and pass/fail results of the checks that ran on a pull request's code | The integration testing, dependency testing and static application security testing tests |
Whether your organization or workspace requires multi-factor authentication | The multi-factor authentication test |
The member list of your organization or workspace, and each member's role | To keep your people and access records current |
Every line on that list feeds a test or a record you can see in the platform.
Two of those items are free text your team writes — a pull request's title and its branch names. They're read exactly as written and shown on the test's evidence, where your auditor will see them — so treat a pull request title the way you'd treat anything else that ends up in an audit record.
What we never read
This is the half a security review is usually really asking about, so here it is stated in the negative.
- File contents. Not at any point, for any test. Nothing in the connection fetches a file, a blob, or a raw source document.
- Diffs, patches, or the contents of a commit. We record that a named check passed on a change. We never look at the change.
- Secrets, environment variables, or CI logs. We read a check's name and whether it succeeded — never what it printed while it ran.
- Nothing is written back, either. Nothing in your repositories is created, modified, closed or commented on. The connection reads, and only reads.
Why the permission looks broader than that list
The permission you grant is broader than the list above. Here's why.
Providers grant repository access at a coarse grain. The smallest permission that lets us see whether a pull request was approved is the same one that would let us read the code in it. That's a normal property of how these providers model repository permissions, not a sign that the wider access is being used.
The narrower answer is scope, not permission. A repository that isn't in scope is never opened: no pull requests, no reviews, no checks, no settings. That's a firmer boundary than any permission checkbox, and it's the one you control — which repositories are graded covers how to set it on each provider.
What happens to what we read
What we read for a test is shown as that test's evidence, on the test's own page. What we read about your members keeps your people and access records current.