Telling UprootSecurity which CI checks to look for
Integration testing, dependency testing and static application security testing (SAST) are one mechanism with three settings. For each, you type the name of a CI check, and the test asks one question of every pull request it grades: did a check by that name finish successfully on that pull request's code?
So the whole job is typing the name your provider actually reports — and that name is a different thing on each provider. Here's where to read it.
The name to type, by provider
Provider | What to type | Where to read it |
|---|---|---|
GitHub | The check run name. In GitHub Actions, that's the job name — not the workflow's name. | Open a recent pull request and look at the list of checks on it. Copy the name exactly as written. |
Bitbucket | The build status key your CI publishes the status with, such as jenkins-ci. Not its display label. | The key your pipeline or CI plugin is configured to send. |
Azure DevOps | The status context name — the name the pipeline publishes its status under. | The pipeline or service that posts the status back to the pull request. |
On GitHub, the workflow file name never appears. A workflow in ci.yml containing a job called unit-tests produces a check called unit-tests. If that job sets its own display name, the display name wins. Matrix jobs produce one check per combination, and the combination is part of the name — test (18.x) — so pick the combination that carries the proof you're claiming.
On Bitbucket, the key and the label are two different strings. The friendly label on screen can differ between commits for the same check; the key is the stable identifier your CI sends every time.
How the name is matched
A check name is an identifier, not a description. It matches the way an identifier matches — exactly, capitalization included. unit-tests and Unit Tests are two different checks, to us and to your branch protection rule alike. Copy it, don't retype it.
Commas list alternatives, not a checklist. You can put several names in one field separated by commas, and any one of them passing satisfies the test. That's useful: it covers a repository that renamed its check partway through, and it covers a fleet where two teams run different CI systems under one connection.
The verdict is reached per pull request. How UprootSecurity grades your version control covers what happens with those verdicts.
Keep your check names stable
Treat a check's name as a small interface other things depend on. Branch protection rules that require the check before a merge, dashboards, release gates and this test all refer to it by name and nothing else. Rename the check and every one of them is now pointing at a name nothing reports — none of them can tell the difference between "renamed" and "never ran."
That's CI hygiene worth having on its own. It just happens to matter here too. If you do rename a check, update the name here in the same change, alongside the branch protection rule you'd update anyway.
Name them after what they prove, not how they run
dependency-scan survives a move from one scanner to another. snyk-action-v3 doesn't — the day you switch tools or bump a version, the name changes and everything pointing at it has to be tracked down.
Name each check after the claim it makes. The tool underneath then becomes an implementation detail you can swap whenever you like, which is the point of having the check in the first place.
One check serves one test
Point each field at the check that actually does that job, and only that job. Putting the same name in all three fields claims three separate practices from one piece of evidence — and that is precisely the claim an auditor tests, by asking to see the output of each.
The three ask different questions:
- Integration testing — does this change still work with the rest of the system?
- Dependency testing — are the libraries you pull in free of known vulnerabilities?
- SAST — does the code you wrote contain patterns already known to be dangerous?
A test suite says nothing about a vulnerable package version, and neither of those reads your own code for injection flaws.
If you run one of the three today and not the others, the answer is to add the missing ones — not to aim all three fields at the check you already have. Setting up your checks covers what each one should contain and how to run all three from a single pipeline. A dated, reasoned gap reads far better to an auditor than a green tick that doesn't survive the first question about it.
Set the names while you're connecting
Fill in all three names in the same pass where you choose which repositories are in scope. It costs one look at a recent pull request, and it's what makes the connection produce usable evidence from its first day.
Names set today shape the record from today forward — each pull request keeps the verdict it earned, so the sooner the names are right, the more of your evidence is clean.
Common mistakes
- Typing the workflow name on GitHub. The workflow is the file; the check is the job inside it. Read the name off a real pull request rather than off the file.
- Typing Bitbucket's display label. The label is cosmetic and can vary between commits; the status key is the name to use.
- Typing the name from memory. Copy it from a pull request that ran recently — a remembered name is usually the name someone meant to use.
- Reusing one check name across all three fields. One check proves one practice, and the other two claims are the ones you'll be asked to evidence.