Skip to main content
Many teams have decided that low-risk changes reviewed by Zenable’s coding verifiers are able to merge to main without human review. Stop queueing low-risk, routine changes behind human review, significantly reducing lead time for changes and end-to-end cycle time. To implement this for yourself, enable the PR risk assessment, publish it as a required check, and update your rulesets — then you’re all set.
GitHub only today. On GitHub the checks are native check runs (rich output, re-runnable from the PR’s checks tab); on GitLab they publish as commit statuses, and merge execution is GitHub-specific.

​
Enable It

  1. Go to Settings → Configuration and pick the profile your repos use.
  2. Under PR/MR risk assessment (mode must not be Off), switch on Merge gate.
  3. Set your knobs:
    • Auto-merge risk threshold — highest assessed risk an author may merge without review (default low)
    • Ready to merge label — the label an author applies to say “merge this” (default Ready to merge)
    • Needs-review label — always forces peer review, at any risk level (default zenable/needs-review)
To guarantee certain changes always get peer review regardless of the AI assessment, add risk floors — deterministic rules like “more than 1,000 changed lines is at least medium risk” that ensure a minimum risk. Once enabled, Zenable posts a zenable/risk-assessment check on every PR: pending while reviewing, passing with the assessed level (and a findings summary in the check’s output) once done. The assessment rides the PR — a push carries the latest result forward to the new commit, so nothing goes red or pending mid-iteration. Review timing is unchanged and configured in one place — see Reviewer Configuration for when reviews run and how to request one. Before moving on, open a small test PR and confirm the configuration works as expected: the check goes pending, then passes with an assessed level, the risk label lands on the PR, and the assessment summary appears in the check’s output.

​
Wire It Into Branch Protection

We recommend creating three rulesets on your default branch (Repo → Settings → Rules → Rulesets): your CI baseline, an AI review ruleset, and a human review ruleset:
1

CI baseline

Your existing required checks, such as requiring linear history, and a Require a pull request rule with 0 approvals.
2

Automated Risk Assessment

One required status check: zenable/risk-assessment, with the Zenable App selected as the source. Consider adding org admins as bypass actors (For pull requests only) as a break-glass if Zenable is ever unavailable.
3

Human review

Your human review requirements, when they apply (for instance, approval count and code owners). Add the Zenable App as a bypass actor, For pull requests only. This is the only ruleset Zenable can bypass, and only for acceptable levels of risk after the author requests to merge (by attaching the appropriate label) so they maintain full control over timing.

​
Merging a Low-Risk PR

As the PR author, once the check shows your PR at or below the threshold, and if you’d like to merge your PR:
  • Enable auto-merge on the PR (to define the merge method and commit message you want Zenable to use), or
  • Apply the Ready to merge label yourself. Importantly, the label must be applied by the PR author for it to be considered.
Zenable re-verifies that the assessment is within your configured risk threshold and the needs-review label is absent, then merges. CI and the risk assessment still apply in full; only peer review is waived. Anything above the threshold goes through your normal review flow untouched. To force review on a specific PR regardless of risk, apply the needs-review label.

​
Review Check (no gating)

Want visibility without any merge policy? Enable Review check on commits under PR Reviews in the same configuration profile. Zenable adds a zenable/review check on all PRs that are enabled for PR reviews, set as passing when the review has completed (naming the assessed risk level) and skipped for each commit that hasn’t been reviewed. Because skipped counts as passing on GitHub, it informs without gating, and it works alongside or entirely independent of risk-based merging.