Yes. GitHub custom deployment protection rules let a GitHub App approve or reject a deployment to an environment, so an external system can hold a deploy until its check passes. The feature is in public preview, so confirm current availability and limits in GitHub's documentation before you design around it.
How the rule works
Per GitHub's documentation, custom deployment protection rules are powered by GitHub Apps. After a rule is installed on a repository, you enable it for each environment where it should apply. From then on, whenever a workflow job targets that environment, the rule runs automatically.
The job waits. The documentation says a triggered rule waits up to 30 days for a webhook response before timing out and failing the job. Any number of apps can be installed on a repository, but at most 6 deployment protection rules can be enabled on an environment at once.
Built in alternatives
Not every team needs a custom app. Environments already offer simpler protections:
| Protection | What it does | Good for |
|---|---|---|
| Required reviewers | Up to 6 people or teams, and one approval is enough | Human sign off on production |
| Prevent self review | Stops the person who triggered the run from approving it | Separation of duties |
| Wait timer | Delays the job for a set number of minutes | A cooling off period |
| Deployment branches | Limits which branches can deploy | Keeping feature branches out of production |
| Custom protection rule | An app decides, based on outside data | Automated checks against other systems |
GitHub notes that availability of some protections in private repositories depends on plan, so check yours.
What a good security check returns
If you build or buy a protection rule for security, decide what it evaluates and what it says back. A useful check:
- Receives the commit, the environment and the artifact reference.
- Looks up current findings for exactly that artifact, not a stale scan of an older one.
- Applies a written rule, such as no new critical findings that are reachable.
- Approves or rejects, with a short reason a developer can act on.
- Fails closed on its own errors, or has a documented, time limited override.
That last point matters. A check that silently approves when its backend is down is a gate in name only. A check that blocks forever when its backend is down will be disabled by an annoyed team. Pick a behavior, write it down and test it.
Keep the loop short
Thirty days is a ceiling, not a goal. A security check should answer in seconds to minutes, so a developer gets feedback while the change is fresh. If a human decision is needed, route it to the right owner and let the check say who.
Test the failure paths
Before you trust it, deploy to a test environment with the rule enabled and try these: a clean artifact, an artifact with a blocking finding, a missing scan result, and the check service being unreachable. Record what happened each time.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply rules to pull requests and releases, and its SBOM and dependency scanning provides the findings those rules read. If you wire a deploy approval to your own checks, point it at the same rule set so developers get one answer, not two.
Quick check
Is a custom deployment protection rule the same as required reviewers?
No. Required reviewers are people. A custom rule is a GitHub App that decides automatically from outside data.
What happens if the app never responds?
According to the documentation, the rule waits up to 30 days and then the job fails.
Sources
Last reviewed: 19 October 2026.
