Use the preview to cover a known CodeQL gap in selected pull requests, but keep merge controls and repository-wide coverage with the security tools built for those jobs.
Update — August 12, 2026: GitHub’s documentation now spells out the preview’s boundaries: it analyzes pull requests only, cannot enforce a merge rule, and does not create backlog alerts in the repository security view. Those limits change how a team should use it.
GitHub code scanning can surface AI-powered security detections directly on pull requests. The public-preview engine is meant to extend coverage into languages and frameworks outside CodeQL’s built-in analysis, putting a potential issue into the review workflow before code is merged.
That is useful coverage, not a new security gate. The practical decision is whether a repository has a meaningful CodeQL gap that a reviewer can investigate—not whether every repository should receive another stream of advisory alerts.
Know what it scans—and what it leaves behind
The engine runs on pull-request creation and after each new commit. It works directly with the pull-request code, can use repository context such as code search, and does not require a build system. Its findings appear in the pull request with an AI label, alongside CodeQL results; they are advisory and do not block a merge.
The scan is confined to pull requests. It does not scan the whole repository and its findings do not become backlog alerts in the repository security view. They also cannot yet be used in rulesets to require a merge condition. Keep CodeQL, dependency review, secret scanning, tests, and a human approval rule for the controls that must cover existing code or block delivery.
Target an actual coverage gap
GitHub names PHP, Shell/Bash, Terraform configuration, Dockerfiles, JSP, and Blazor as examples of coverage beyond CodeQL’s normal language and framework set. Start with a repository that actually uses one of those gaps and has enough pull-request traffic to produce evidence. A conventional CodeQL-supported application with a mature review process may not be the best first candidate.
The current categories include injection, weak cryptography, access control, sensitive-data exposure, insecure configuration, authentication failures, integrity failures, SSRF, and supply-chain risks. Use those categories to define who reviews what. Do not promise that an AI label means every vulnerability class in that repository has been assessed.
Make the pilot measurable and reversible
The public preview requires GitHub Advanced Security and a GitHub Copilot license, consumes AI credits, and is off by default at enterprise, organization, and repository levels. Enterprise administrators must allow it, organizations opt in, and individual repositories can opt out. Establish that ownership and a credit budget before switching it on.
For each finding, review the changed data flow, reproduce the condition where possible, assess exploitability in the deployed environment, and record the resolution. Track findings per pull request, confirmed issues, duplicate or false-positive rate, reviewer time, time to remediation, and AI credits per confirmed issue. Set a review date and disable the pilot if it adds untriageable alerts without finding a gap your existing controls missed.
This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.
PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.
