Protect pull requests with GitHub checks

To block merging, require the Signals Corps Supply Chain / scan status check in a GitHub branch ruleset. Signals Corps maps findings to the check conclusion. GitHub enforces that conclusion.

On a Team trial or paid plan, the current managed policy blocks stable, high-confidence High and Critical findings. Lower-severity findings and other alert-only rules remain visible without blocking the merge. The Free plan is alert-only.

Can I block only Critical findings?

Not today. GitHub cannot interpret individual finding severities, and the current Signals Corps managed threshold includes both High and Critical findings. A Critical-only threshold would require a future policy option.

Before you start

You need:

• a GitHub organization owner, repository administrator, or custom role that can edit repository rules;
• the Signals Corps GitHub App installed for the target repositories;
• each repository connected to and monitored by the correct Signals Corps Workspace;
• at least one completed Supply Chain check on a target repository, so GitHub can offer the check and its expected source; and
• a Team trial or paid plan if findings should block merging.

GitHub ruleset availability depends on repository visibility and the organization’s GitHub plan. Confirm the current eligibility details in GitHub’s ruleset documentation before planning an organization-wide rollout.

Keep the GitHub App limited to the repositories that the Workspace should monitor. Do not grant the app or ordinary users a ruleset bypass.

How conclusions affect merging

Supply Chain conclusion	Meaning	When the check is required
success	The scan completed with no findings.	GitHub permits merging.
neutral	Findings are alert-only under the effective managed policy.	GitHub permits merging and keeps the findings visible.
failure	A stable, high-confidence High or Critical finding matched under a Team trial or paid plan.	GitHub blocks merging.
action_required	Coverage was incomplete or the scan could not produce an authoritative result.	GitHub blocks merging until the problem is resolved and the check is rerun.

GitHub treats success, neutral, and skipped as passing required-check states. A check with a failure or action_required conclusion, a queued or in-progress check, and a missing required check all block merging. See GitHub’s status check reference.

How do I make Supply Chain block a pull request?

Configure either an organization ruleset or a repository ruleset. The ruleset must require pull requests and the exact Signals Corps Supply Chain / scan status check.

Protect repositories across an organization

An organization ruleset is the recommended way to apply one policy consistently across selected repositories.

1. In GitHub, open the organization Settings.
2. Under Repository, select Rules, then Rulesets.
3. Create a New branch ruleset and give it a clear name, such as Supply Chain merge protection.
4. Select the repositories to protect and target their default branches.
5. Start in Evaluate mode when your GitHub plan offers it. This records how the rule would behave without immediately blocking developers.
6. Enable Require a pull request before merging.
7. Enable Require status checks to pass before merging.
8. Add the exact check name Signals Corps Supply Chain / scan.
9. Select the Signals Corps GitHub App as the expected source. This prevents another integration from satisfying the rule with a check that has the same name.
10. Decide whether branches must be up to date before merging, and keep the bypass list as small as possible.
11. Save the ruleset, test it, then change its enforcement status to Active.

GitHub documents the available controls in Rules available for rulesets.

Protect one repository

For a pilot or a repository-specific exception:

1. Open the repository Settings.
2. Select Rules, then Rulesets.
3. Create a branch ruleset for the default branch.
4. Require pull requests and the exact Signals Corps Supply Chain / scan status check.
5. Select the Signals Corps GitHub App as the expected source, restrict bypasses, and save the ruleset.

Prefer an organization ruleset once the pilot is complete. Repository-level rules are easier to configure inconsistently.

Test before broad enforcement

1. Apply the ruleset to one fixture or noncritical repository in Evaluate mode.
2. Open a benign pull request and a test pull request with a known blocking finding. Confirm the expected results in GitHub’s Ruleset Insights.
3. Keep the pilot limited to that repository and change the ruleset to Active.
4. Confirm the benign pull request can merge.
5. Add a known alert-only finding and confirm the check is neutral and merging remains available.
6. On a Team trial or paid plan, add a known stable High or Critical finding. Confirm the check reports failure and GitHub disables merging.
7. Remove the finding, rerun the check, and confirm merging becomes available.
8. Review the check link, annotations, exact commit SHA, and scan details in the Control Plane.
9. Expand the organization ruleset only after the pilot passes.

A required status check protects only the commits and branches covered by the GitHub ruleset. If direct pushes must also be prevented, require pull requests and configure branch restrictions. Any actor on the bypass list can bypass the protection, so review bypass use in GitHub’s audit log.

A required check that is never created remains missing and intentionally blocks merging. Confirm every targeted repository is supported, connected, and monitored before expanding an organization ruleset. Keep the Staging and Production GitHub Apps out of the same repository and ruleset.

If you use GitHub merge queues, validate the complete merge-group check lifecycle on a test ruleset before requiring Supply Chain across those repositories.

Troubleshooting

Why is the check missing from GitHub’s selector?

Confirm the app is installed for the repository and the repository is monitored in the correct Workspace. Trigger one Supply Chain scan, wait for the check to finish, then return to the ruleset. GitHub only offers checks that it has seen recently.

Why is the check missing or pending on a pull request?

Check the app’s repository selection, the Workspace connection, repository monitoring, and the ruleset’s branch target. The check must be reported for the pull request’s current head commit.

Why is a finding neutral?

The Free plan is alert-only. On a Team trial or paid plan, findings outside the managed stable, high-confidence High and Critical blocking subset remain alert-only and produce a neutral conclusion.

Why did a finding not block merging?

Confirm the ruleset is Active, targets the pull request’s base branch, requires the exact check name, pins the expected app source, and does not grant the actor a bypass. Also confirm the Workspace is on a Team trial or paid plan.

Why does the check say action is required?

The scan could not produce an authoritative result, often because coverage was incomplete or an orchestration step failed. Open the linked scan, resolve the reported problem, and rerun it. Signals Corps does not treat scanner errors as clean results.

Why do I see duplicate Supply Chain checks?

Check whether both Staging and Production GitHub Apps, or an older app installation, can access the same repository. Remove the unintended installation or repository access before enforcing the expected Production source.

Related documentation

• Connections and repositories
• How scanning works
• Scans and results
• Rules and policy

GitHub interface labels and ruleset behavior were last verified on October 16, 2026.