Secbez Docs

Policy & Merge Checks

How Secbez maps findings to GitHub Check Run conclusions and how to enforce merge gates.

Secbez evaluates the new findings introduced by a pull request against your policy and emits a Check Run conclusion the rest of GitHub can act on (branch protection rules, required status checks, downstream automation).

How policy evaluation works

After scanning a pull request, Secbez:

  1. Filters findings to new items only (baseline findings are tracked but never gate the PR).
  2. Applies suppression rules (server-side and inline).
  3. Applies the configured severity / confidence thresholds.
  4. Picks the strictest matching outcome — fail, warn, or pass.

The conclusion is reported on the PR as the Secbez Security Scan Check Run.

Default policy thresholds

ConditionAction
Any critical severity findingFail
Any high severity + high confidence findingFail
Any high severity finding (any confidence)Warn
Any medium severity findingWarn
All other findingsPass

needs-review findings default to warn; you can configure them to gate or pass.

Enforcing merge checks

To prevent merging PRs that fail the security gate:

  1. Go to your GitHub repository Settings → Branches.
  2. Edit (or add) a branch protection rule for your default branch.
  3. Enable Require status checks to pass before merging.
  4. Select the Secbez Security Scan check.

Once enabled, PRs with a Failure conclusion cannot be merged until the issues are resolved or explicitly suppressed.

Customizing policy

Per-repository policy is editable from the dashboard's Settings → Policy tab. You can:

  • Move thresholds up or down across severity / confidence buckets.
  • Apply per-rule overrides (e.g., always fail on SEC.SECRETS.AWS_SECRET_KEY, regardless of confidence).
  • Apply per-path policies (e.g., ignore findings in __tests__/ or vendor/).
  • Configure how needs-review and low-confidence findings are treated.

Stricter policies catch more issues before merge. More permissive policies reduce friction but accept more risk — and ones that ignore high+high are no longer a meaningful gate.

Enterprise: custom policy engines

Enterprise deployments can plug in a custom policy module — e.g., one that consults an external risk-scoring service, applies tenant-specific overrides, or maps Secbez categories onto an internal compliance framework. See Enterprise → Customization.

On this page