Which repositories are graded, and how to take one out of scope

Every version control test grades the repositories your connection can see, and which repositories those are is decided in a different place on each provider. On GitHub it's set inside GitHub, not in UprootSecurity. On Bitbucket and Azure DevOps it's the project you chose when you connected, minus any repositories you exclude.

Scope is a claim, not a filter

What's in scope is what you're telling your auditor represents how you build and ship production software. Taking a repository out isn't hiding it — it's stating that it isn't part of that claim. That's often true and entirely defensible. It's also a sentence you may have to say out loud in a fieldwork call, so make every exclusion one you'd be comfortable saying.

Where scope is set, by provider

GitHub — change it in GitHub. There is no repository list to edit in UprootSecurity, and that's by design: the app can only read what GitHub granted it, so the grant is the scope. Open your organization's settings in GitHub, find the UprootSecurity installation, and choose either all repositories or a selected list. Add or remove a repository there and the next run follows.

Bitbucket — one workspace, one project, minus what you exclude. Every repository in the project you picked when you set the connection up is graded. To take one out, add it to the connection's exclusion list. Bitbucket identifies a repository by its slug — the short name that appears in the repository's URL — and that's what the exclusion list matches. Copy the slug straight from the URL rather than typing the display name; on Bitbucket the two are frequently different.

Azure DevOps — one organization, one project, same shape. Everything in the project you picked is graded, minus the repositories you name in the exclusion list.

On both Bitbucket and Azure DevOps, one connection covers one workspace or organization and one project, so the project you pick is the boundary of the claim these tests evidence. Pick the project that holds the repositories that build and ship your product — that's the population an auditor is asking about.

Multi-factor authentication is the exception: it's read once for the whole organization or workspace rather than per repository, so excluding a repository doesn't change it.

Your repositories also appear in Asset Inventory, fed by the same connection, where each one can be given an owner.

What's legitimately out of scope

• Sandboxes, spikes and personal scratch repositories that never reach production. Nothing in them ships, so no change-management gate is being claimed for them.
• Archived and read-only repositories. Nothing can change, so there's nothing to control — this is the easiest exclusion to defend.
• Documentation, marketing sites and infrastructure-configuration repositories, but only if they genuinely can't affect the production system. Infrastructure-as-code usually can, and excluding it is a claim that won't survive a serious audit. A repository that can change production is a production repository, whatever language it's written in.
• Vendored or mirrored copies of someone else's code that you don't modify. You're not developing it, so there's no development process to evidence.

What stays in, however inconvenient

• Anything that ships to production — including the small service nobody owns any more.
• Anything holding credentials, configuration or deployment automation for production. These are the repositories an attacker would want most, which is exactly why an auditor expects the gate on them.

The one exclusion you'll have to defend

Taking a repository out because its test is red is not scoping. It's the single move that turns a failing test into an audit finding — a failing test is a known gap you're working on, while an unexplained exclusion looks like you decided the evidence was inconvenient.

So the check before every exclusion is: would I have taken this repository out if the test were green? If yes, take it out and write down why. If no, leave it in and fix the underlying gap instead.

More repositories is not a better score

Scope should match reality. Padding it enrols repositories nobody considers production into a control they were never meant to carry, which just buys you failing tests for work that doesn't matter.

Review scope when it changes, not once a year

A new service, a repository that graduated from spike to production, a codebase inherited through an acquisition. The most common audit finding here isn't a bad exclusion — it's a production repository nobody remembered to add.

What happens when a repository leaves scope

Scope is read fresh on every run. A repository you exclude, remove from the project, or delete simply stops being part of what you're claiming, so it stops carrying evidence from that run onward.

It also makes scope changes visible. A repository whose results vanish is a question someone can ask, which is one more reason to make each change deliberate and record why. Putting one back is not a special operation — restore its visibility to the connection and it's picked up again on the next run.