How UprootSecurity grades your version control
Six tests read your version control connection, and they grade two different things. Your repositories are current state — fix the setting and the next run goes green. Your pull requests are a record of what happened — and turning a check on today doesn't put it on a pull request that merged last month.
That split explains almost everything that surprises people here — including why a fix you made this morning doesn't clear yesterday's reds.
The six tests, and what each one asks
Two of them read your repositories as they are right now:
- Multi-factor authentication — does your GitHub organization or Bitbucket workspace require two-factor sign-in for everyone in it?
- Default branch protected — is the default branch of each repository in scope protected, so code can't land on it unchecked?
Four of them read your pull requests:
- Code review — for each merged pull request, did someone other than the author approve it?
- Integration testing, dependency testing and static application security testing (SAST) — did the check you named finish successfully on that pull request's code?
Those last three are one mechanism with three names. You tell UprootSecurity what your test run, your dependency scan and your security scan are called, and each test looks for its own name. Getting that name exactly right is the whole job — telling us which CI checks to look for covers where to find it on each provider.
What gets graded
Scope comes from the connection, and it's set in a different place on each provider — which repositories are graded covers where, and how to take a sandbox out of scope in a way you can defend.
Monitoring starts when you connect. Pull requests raised before then are out of scope, permanently. They ran under whatever process you had at the time, and grading them would judge old work by a new rule.
Why fixing your pipeline today doesn't turn old pull requests green
A pull request is graded on what actually happened on it. Turn your security scan on this morning and every pull request merged before this morning still shows that check missing — because on those pull requests, it was missing. Re-running the test reads the same history and reaches the same answer.
That's deliberate. These tests are evidence that a gate was operating over a period, not a screenshot of how your pipeline is configured today. A record that rewrote itself the moment you changed a setting would prove nothing to an auditor, which is exactly why they ask for this one.
So an old red isn't a verdict on your program. It's a dated record of the period before the gate existed — and an auditor expects to see that improve going forward, not disappear.
What you control from here is the record going forward. Turn the gate on, keep it on, and every pull request from then on carries clean evidence. You clear a red by making new pull requests pass, not by editing old ones — so the story to tell an auditor is the date the gate went in and the clean run since, not a tick that appeared overnight.
The repository tests work the opposite way, and they're forgiving. Branch protection is re-read from scratch on every run, so the moment you protect a branch, the next run reflects it. Nothing there is held against you afterwards.
What the verdict means
One failing item fails the whole test. There's no partial credit and no percentage. The test is the claim that this gate held for everything it covers, and one item that slipped through makes the claim untrue.
Marking a single item Not Applicable is the supported lever. It carries your reason, sticks across future runs, and can be lifted again by the person who marked it. Use it for a repository or a pull request that genuinely isn't part of what you're claiming — not for one that's simply red. A handful with good reasons is normal. A pattern of them is what an auditor will pull on.
A test with no pull requests to grade yet is Pending, not failing. Nothing is broken — nothing has been observed yet.
Tests re-run every day, and there's a Run Test control on the test's page for when you've just changed something and don't want to wait for tomorrow.
Common mistakes
- Expecting a fix to clear old reds. Turning the gate on changes what happens next; it doesn't rewrite what already happened. Judge the fix by the pull requests raised after it.
- Naming a check approximately. The name has to match what your provider actually reports, character for character — get it from the provider, not from memory.
- Reading a red test as a verdict on today. A failing pull request test is a dated record — check the date on the failing items before you change anything.