Use Codeac PR checks as a merge gate for security policy
Gate pull requests with Codeac by configuring its check as a merge gate, shifting security feedback left and blocking risky changes before they reach main.
24 Apr 2026, 20:10 UTC

The useful decision is to block merges, not just report
The problem with post-merge security reporting is timing. Findings arrive after code is in main, which forces hotfixes, backports, and risk acceptance under pressure. With Codeac, the practical engineering decision is to use Pull Request checks as a merge gate: run SAST and dependency checks on the diff, map findings to a policy, and post a check result back to the PR. That shifts feedback left and keeps risky changes out of the main branch.
How PR gating works in Codeac
Codeac is a cloud code security platform. When a repository is connected, Codeac can be triggered on pull request open and update via webhook or CI integration. The scan is scoped to the PR diff rather than a full repo scan.
The mechanism is: PR event → Codeac scan → findings classified → policy evaluation → check status posted to the PR. If the policy fails, the check is reported as failing and, when branch protection is configured, merge is blocked. Findings are surfaced as PR comments with remediation context.
Unfamiliar terms: SAST is static application security testing, analysis of source code without execution. Dependency checks identify vulnerable open source libraries. A policy is a set of rules that decides which findings are blocking, warning, or informational.
Worked policy pattern
The following configuration is illustrative. Actual field names and schema in Codeac are version sensitive and should be confirmed in your workspace. It shows the intent: enable checks for the language stack, set a severity threshold for blocking, and allow controlled exceptions for medium findings.
# illustrative repository policy, not a verified Codeac API reference
policy:
name: pr-gate-web
scope: pull_request
checks:
- type: sast
languages: [typescript, python]
fail_on: severity >= high
- type: dependencies
fail_on: severity >= high
fail_on_cves: [critical]
exceptions:
- rule_id: hardcoded-secret
allow: medium
requires_approval: true
max_age_days: 30
reporting:
comment_findings: true
require_passing_check: true
Interpretation: SAST and dependency checks run on the PR diff. High severity findings fail the check. Medium findings for a specific rule can be allowed with reviewer approval and an expiration. The check must pass for merge.
Where to apply this: in the Codeac workspace for the target repository, under Pull Request Checks or Policy Enforcement settings. Permissions needed are workspace admin to edit policies and repository admin to connect the repo and enable branch protection integration.
Limits to plan for
Scan coverage is bounded by supported languages and analysis modes. Codeac may not analyze every framework construct or proprietary build step. Verify language support for your stack before relying on gating.
Noise is a real cost. Un tuned rules produce false positives, which erodes trust and leads to bypasses. Baseline existing findings before enforcing blocking.
Latency adds to PR cycle time. Diff scans are faster than full scans but still add minutes. For large diffs or monorepos, scan time and result aggregation can grow. Self-hosted or monorepo setups increase complexity for path filtering and policy scoping.
Policy enforcement is only as good as the rule set and exception handling. Exceptions should be auditable, time-boxed, and require approval. Without that, teams create permanent carve-outs.
Common mistakes to avoid
Enabling blocking on all severities without baselining. This causes PR churn and encourages disabling the check. Start with high severity blocking, tune, then expand.
Relying on default policies without adjusting to codebase risk. Default policies are generic. Adjust severity thresholds and rule inclusion to match your threat model and tech stack.
Ignoring flaky or non-deterministic findings. If a finding appears intermittently, do not gate on it. Track flakiness in the policy audit log and either fix the rule or exclude it until stable.
Not wiring the check into branch protection. A failing check that is not required for merge is just reporting. Ensure the CI/CD platform requires the Codeac check to pass.
Verify it works
Open the Codeac workspace for the target repository and inspect Pull Request Checks or Policy Enforcement settings to confirm gating is enabled and which checks are active.
Trigger a test pull request with a known safe change and a change that should violate the defined severity threshold. Verify the check status posted to the PR and whether merge is blocked.
Review the policy/exception audit log in Codeac to confirm which rules fired, how findings were classified, and whether exceptions were applied as intended.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.