GitHub Copilot Security Review vs CodeQL: What Can Block a Merge?

GitHub Copilot's /security-review should never be your required merge gate. Use it as fast local triage for active changes, then let CodeQL code scanning and a ruleset enforce the repository policy.

The production verdict

Copilot security review and CodeQL belong at different points in the same delivery path. The Copilot command gives a developer fast, contextual feedback before code leaves the workstream. CodeQL produces repository-level code scanning alerts that a GitHub ruleset can turn into an enforceable merge condition.

That distinction matters more than whether both tools can find an injection flaw. A production gate needs a known trigger, durable evidence, a failure state, and an owner for bypasses. /security-review gives you a useful opinion. CodeQL plus a ruleset gives the repository a policy.

GitHub's new app command is still valuable. It analyzes in-flight changes, returns high-confidence findings scored by severity and confidence, and proposes changes that the developer can apply and reverify. GitHub explicitly describes it as a lightweight, on-demand check that complements code scanning, Dependabot, and secret scanning. It is not the replacement for any of them. GitHub's Copilot app announcement is clear about that boundary.

CodeQL owns the other side of the boundary. It builds a representation of supported source code, runs maintained queries, and publishes findings as GitHub code scanning alerts. Default setup can choose the languages, query suite, and scan events for the repository; advanced setup and external CI are available when the defaults are not enough. GitHub's CodeQL documentation documents all three setup paths.

The one axis that separates them: enforceable evidence

CodeQL wins the merge-gate decision because its result can participate in repository policy. The Copilot command wins the feedback-speed decision because it runs while the developer still owns the change.

The ruleset is the decisive piece. GitHub can prevent a pull request from merging when a required code-scanning tool finds an alert at the configured severity, when its analysis is still running, or when the required tool is not configured. Those are fail-closed states. A clean chat response has no equivalent repository policy. GitHub's ruleset reference defines the blocking conditions.

The practical consequence is simple: a developer can skip an advisory command, close its window, or run it before the final diff. A required code-scanning rule follows the pull request state. If analysis is missing, unfinished, or above the severity threshold, the merge stays closed.

Where Copilot security review earns its place

Use /security-review before the pull request, when the cheapest fix is still a local edit. That is where contextual AI review creates value without pretending to be a control plane.

Consider an engineer changing an authorization handler and its data-access layer. The useful local loop is:

• Finish a coherent slice of the change, including tests.
• Run /security-review against the active workstream.
• Inspect the reported data flow, severity, confidence, and proposed remediation.
• Apply a suggestion only after checking the intended authorization behavior.
• Rerun the review on the resulting diff, then open or update the pull request.
• Record every accepted, rejected, and deferred finding in the pull request when it changes the security decision.

The command is tuned for injection, cross-site scripting, insecure data handling, path traversal, and weak cryptography in the app. The CLI announcement describes broader coverage across 11 categories, including broken access control, SSRF, insecure deserialization, hardcoded credentials, supply-chain risks, and cross-prompt injection against LLM-integrated code. Those are useful review prompts for agent-authored changes. They are not a recall guarantee.

GitHub's own command reference sets the correct expectation: /security-review is a focused review of active local changes, not a full repository security audit. The Copilot CLI reference should be the sentence your rollout policy copies.

Treat this evidence as a handoff, not ceremony. If the developer changes the diff after the local review, the old result is stale. The pull request should say so, and the developer should rerun the command before asking for approval.

Where CodeQL must remain the gate

Use CodeQL where repeatability and repository enforcement matter. Its strongest production property is not that it catches every vulnerability. It is that the same policy can run on every relevant pull request and produce an alert the repository understands.

Start with the default query suite as the required signal. GitHub describes it as high precision with few false-positive code scanning results. Evaluate security-extended separately before making it blocking: it includes the default suite plus lower-precision and lower-severity queries, and GitHub warns that it may return more false positives. The CodeQL query-suite reference gives you the tradeoff without marketing fog.

For a production team, the rollout rule is:

• Require the default suite on protected release branches.
• Run security-extended in an observed, non-blocking lane until security owners understand its alert volume and failure modes.
• Promote only the severities and query classes the team can triage within its release process.
• Keep a named owner and reason for every ruleset bypass.
• Export the alert state with the release evidence when compliance or incident response needs a durable trail.

Language coverage is the first place this breaks. CodeQL supports its published language set, but GitHub explicitly says PHP and Scala are not supported. Attempting to scan an unsupported language can produce no alerts and incomplete analysis. A green workflow in that situation is not a clean security result.

The fix is to require a compatible third-party code-scanning tool for the unsupported part of the stack. GitHub rulesets can require code-scanning results from a named tool, so the policy remains fail-closed. Keep /security-review as supplemental coverage, especially for business logic and cross-file context, but never let it mask a missing SAST lane.

The cost boundary also differs. Copilot app /security-review is available to Free, Pro, Business, and Enterprise users during public preview. Code scanning is free for public repositories. Private repositories need GitHub Code Security, where usage is measured by unique active committers and activity looks back 90 days. Budget against the people touching enabled repositories, not the repository count. GitHub's current Advanced Security billing documentation is the source of truth.

Ship the layered merge gate

The reliable design is a sequence of bounded checks with different owners. No single scanner gets promoted into a universal security oracle.

1. 1

   Put Copilot in the developer loop

   Run /security-review after a coherent change and its tests are ready. Require a disposition for findings that affect security behavior. Rerun after any material edit so the reviewed diff is the diff that reaches the pull request.

2. 2

   Run CodeQL on the pull request

   Enable default setup when its automatic language and event choices fit. Use advanced setup or external CI when the build, query packs, or runner boundary needs explicit control. The result must publish as code scanning alerts against the pull request.

3. 3

   Make code scanning fail closed

   Add the code-scanning rule to the protected-branch ruleset. Select the required tool and severity threshold. Keep merge blocked when the tool reports a qualifying alert, remains in progress, or is missing.

4. 4

   Route high-risk paths to humans

   Require accountable review for authentication, authorization, tenant boundaries, payment flows, cryptography, deployment permissions, and security-control changes. AI findings inform that reviewer; they do not approve their own remediation.

5. 5

   Log the exception path

   Capture the repository, pull request, commit SHA, scanner, query suite, alert disposition, bypass actor, bypass reason, and follow-up owner. Alert when bypass volume rises or required analyses disappear from protected branches.

GitHub's responsible-use guidance for AI-generated security fixes matches this design: review the suggestion, verify CI passes, and confirm the alert is resolved before merging. The model can propose the patch. Tests, code scanning, and an accountable reviewer prove whether it belongs.

The minimum useful release record should answer these questions without reopening a chat transcript:

• Which commit did the developer review locally?
• Which code-scanning tool and query suite ran on the final pull request?
• Which alerts were introduced, fixed, dismissed, or accepted?
• Did a ruleset block or allow the merge?
• Who bypassed a control, why, and who owns the follow-up?

That record is what incident response needs when a vulnerability appears later. "Copilot looked at it" is not evidence. A commit-scoped scan result, alert disposition, merge policy outcome, and named approver are.

What breaks first in production

The first production failure is usually stale evidence, not scanner quality. The developer runs /security-review, edits the implementation, and assumes the earlier result still applies. Bind the local review to a commit SHA and rerun after material changes.

The next failure is a green blind spot. CodeQL can only analyze its supported languages and modeled frameworks. Inventory repository languages before rollout, map each one to a required scanner, and fail enablement when any production language has no owner or coverage path.

Alert fatigue follows when a team makes every possible query blocking on day one. Start the required gate with CodeQL's higher-precision default suite. Observe lower-precision signals before promotion, and measure dismissed findings by query and reason. A noisy rule that developers routinely bypass is weaker than a smaller gate they trust.

Preview drift is another operational risk. /security-review and code scanning's AI detections are in public preview. Keep their use behind a documented rollout policy, recheck availability and billing before expanding, and never base a compliance promise on a preview-only behavior.

Finally, bypasses become invisible. The repository may be technically protected while administrators or approved actors routinely step around the rule. Log bypass actor, reason, affected commit, and follow-up owner. Review that stream with the same seriousness as failed scans.

For a broader rollout policy, the same principle applies to other AI review surfaces: treat AI security review as early signal, not approval. Pair the control data with repository-level Copilot rollout telemetry so adoption never outruns review capacity.

The decision rule

Use Copilot /security-review when the developer can still change direction cheaply. Use CodeQL and a ruleset when the repository must prove that a required scan ran and passed policy. Add a compatible required scanner where CodeQL has no language coverage, and keep humans accountable for business-logic security.

The choice flips only when the requirement flips:

• Need fast feedback on an active diff? Run /security-review.
• Need an auditable alert tied to the pull request? Run CodeQL code scanning.
• Need to prevent a merge? Require code-scanning results in a ruleset.
• Need assurance for authorization or tenant boundaries? Require a qualified human reviewer and tests that exercise the security invariant.

That is the production stack: advisory AI close to the author, repeatable static analysis in CI, policy at the repository boundary, and accountable approval where the cost of a miss is highest.

Is GitHub Copilot security review free?

During public preview, /security-review in the GitHub Copilot app is available to Copilot Free, Pro, Business, and Enterprise users. Treat that as preview availability, not a permanent pricing commitment.

Does Copilot /security-review run CodeQL?

No. GitHub says the Copilot-driven scan does not rely on GitHub code scanning, Dependabot, or secret scanning. It is a separate, lightweight review that complements those systems.

Can CodeQL block a pull request merge?

Yes, through a GitHub ruleset that requires code-scanning results. The rule can block when the required tool finds an alert at the configured severity, is still running, or is not configured.

What should a team use for PHP or Scala?

CodeQL does not support PHP or Scala. Require a compatible third-party code-scanning tool for those languages, keep its result inside the same ruleset, and use Copilot security review only as supplemental signal.

Start the AI Coding Rollout

Ship Copilot with repository policy, security gates, observability, and a rollout your engineering team can defend.