GitHub AI Scan Tutorial: Find Security Bugs in PHP Pull Requests

A PHP change can pass its tests and still introduce SQL injection, expose a secret, or let a user access another account’s data. On October 15, 2026, GitHub announced the general availability of AI Scan for pull requests, a security feature designed to identify vulnerabilities in languages and frameworks that its CodeQL scanner does not currently cover. This tutorial explains how to enable GitHub AI Scan, inspect its findings, and use it alongside existing security checks without treating AI-generated warnings as proof that code is safe or unsafe.

What GitHub AI Scan adds to a PHP security workflow

GitHub CodeQL is a code analysis engine that examines source code for security weaknesses using structured queries and language-specific analysis. It provides useful coverage for supported languages, but not every language or framework receives the same analysis. AI Scan adds another layer by examining pull request changes in areas such as PHP, Shell/Bash, Terraform configuration, Dockerfiles, Java Server Pages (JSP), and Blazor for C#.

The distinction matters if you maintain a PHP application. You can already use tests, dependency checks, and CodeQL where applicable, yet still lack equivalent CodeQL coverage for some of your PHP changes. AI Scan can identify additional risks directly in eligible pull requests, without requiring a separate scanning tool or a build system. It complements CodeQL rather than replacing it, and its results are advisory rather than guaranteed security findings.

Check repository eligibility before enabling AI Scan

Before changing settings, establish who owns the repository and whether code scanning is enabled. GitHub's October 15 announcement says AI Scan is available for public repositories owned by organizations or personal accounts. Private and internal repositories owned by organizations require GitHub Code Security or GitHub Advanced Security. A GitHub Copilot license is not required under the general-availability announcement.

AI Scan also has boundaries that affect testing. It runs on eligible pull requests, not as a full-repository scan, and does not run on pull requests from forks or pull requests created by Dependabot. Organization-owned repositories inherit the organization's effective setting, while repository administrators can opt out when the organization has enabled the feature. For a public repository owned by a personal account, an administrator can enable or disable AI Scan directly in the repository's code-scanning settings.

Step 1: Enable code scanning for your repository

Open your repository on GitHub and select Settings. Under the security section, open Advanced Security and check whether code scanning is enabled and available for your repository. If your account or organization needs an eligible GitHub security product, resolve that requirement before proceeding.

CodeQL default setup is not a prerequisite for AI Scan. That is an important distinction: you need code scanning enabled, but you do not have to configure CodeQL default setup just to make AI Scan run. If you already use CodeQL, keep it enabled where it provides useful coverage. AI Scan is intended to add findings for supported gaps rather than replace established static analysis.

Step 2: Turn on AI Scan at the correct permission level

The setting you need depends on repository ownership. For an eligible public repository under a personal account, open the repository's Settings, go to Advanced Security or its code-scanning controls, and locate the AI Scan for pull requests toggle. Enable it and save any required setting changes. The exact controls can vary with account type and GitHub's interface updates.

For an organization-owned repository, an organization owner or security manager should enable AI Scan in the organization's code-scanning settings. If the organization belongs to an enterprise, an enterprise owner must first allow the feature in the enterprise's code-security policy. Enterprise permission alone does not activate AI Scan: the organization must enable it separately, and eligible repositories must have code scanning enabled. Repository administrators can opt out of the inherited organization setting, but cannot opt in independently if the organization has disabled it.

Do not select a model or create a custom workflow just to enable AI Scan. GitHub runs the feature automatically when the repository's effective setting permits it and a qualifying pull request contains relevant changes. For an organization-wide rollout, review the available AI-credit budget before enabling it across many repositories.

Step 3: Open a pull request containing a meaningful code change

Make a normal change on a feature branch, push the commit, and open a pull request against your target branch. AI Scan checks eligible pull requests when they are created and again after new commits arrive. For a PHP application, a useful review might involve a controller accepting user input, a database query, an authorization check, or a file-handling operation. Do not deliberately introduce a real vulnerability into a production branch just to test whether the scanner detects it.

For example, suppose a controller builds an SQL query by concatenating a request parameter into the query string. Your existing tests might verify that the endpoint returns the expected records for ordinary input, but those tests may not cover malicious input. AI Scan may flag the unsafe query construction and explain the risk. That result gives the reviewer a concrete issue to investigate; it does not establish that every possible exploit path has been found or that the rest of the application is secure.

Step 4: Review the AI-labelled findings on the pull request

When AI Scan identifies a potential problem, inspect the pull request's Conversation and Files changed tabs. Its findings appear alongside CodeQL results and carry an AI indicator, making it easier to distinguish them from traditional CodeQL alerts. A finding can describe the potential security issue and explain why the affected code may be risky. Many findings include a suggested remediation, although a suggested fix is not guaranteed to be available for every issue.

Start by reading the affected code and tracing how data reaches it. If the finding concerns SQL injection, check whether user-controlled input can reach the query and whether parameterized queries are used correctly. If it concerns broken access control, verify the server-side authorization checks rather than relying on whether a button is hidden in the interface. Confirm the underlying behavior with focused tests or a controlled security test before accepting or dismissing the finding.

AI Scan supports feedback on findings through a thumbs-up or thumbs-down mechanism. Use it when the result is useful or inaccurate, and document your team's reasoning when triaging a security issue. If you already use a repository security scanner or automate pull-request review with a review API, keep those workflows in place and decide how AI Scan fits into the wider review process.

Step 5: Fix verified issues and test the change

Once you confirm a vulnerability, implement the smallest correct fix and add a regression test where practical. For SQL queries in PHP, that commonly means using prepared statements with bound parameters rather than concatenating untrusted values. For authorization problems, enforce permissions on the server for every sensitive operation. For exposed secrets, remove the secret from the code and rotate it if it may already have been disclosed; deleting a value from the latest commit alone does not invalidate a compromised credential.

If a suggested fix is available through Copilot Autofix, treat it as a proposed code change that requires review. Compare the patch with the original finding, check edge cases, and run the application's tests and existing security checks. If you determine that the warning is a false positive, record why the code is safe and use the available feedback mechanism. Avoid suppressing a finding simply because a test suite passes: tests and security analysis answer related but different questions.

Understand the limits before making AI Scan a gate

AI Scan findings are advisory. They do not fail the code-scanning check and cannot currently be used as ruleset requirements to block a pull request from merging. Teams should therefore not assume that enabling the feature creates a mandatory security gate. Keep required checks, human review, access-control tests, dependency scanning, and other suitable protections in place.

AI analysis can also produce false positives, and supported languages or detection categories may change over time. GitHub identifies categories such as string injection, weak cryptography, broken access control, sensitive-data exposure, security misconfiguration, authentication failures, data-integrity failures, server-side request forgery, and supply-chain risks. Coverage across these categories is not a guarantee that every vulnerability will be detected. The feature also consumes Code Security AI Credits, so a rollout should account for usage and billing budgets rather than assuming every scan is cost-free.

Step 6: Confirm that the feature is actually enabled

If no AI findings appear, do not immediately conclude that the scanner is broken. Check the repository's effective AI Scan setting, confirm that code scanning is enabled, and verify that the pull request is eligible. A pull request from a fork or one created by Dependabot will not trigger AI Scan, and a change that does not touch a supported coverage area may produce no AI finding. A clean result means the scanner reported no qualifying issue in that scan, not that the entire change is vulnerability-free.

Organization owners and security managers can use GitHub's security overview to review AI Scan enablement and adoption. The coverage view helps identify repositories where the effective setting is enabled or not enabled, while the code-scanning-on-pull-requests report separates AI Scan metrics from CodeQL metrics. These views are useful when rolling the feature out across a team because they help distinguish a configuration problem from a repository that simply has not produced a finding.

For a PHP team, the sensible next step is to enable AI Scan on one eligible repository, inspect several real pull requests, and compare the findings with the team's existing review process. Expand adoption after you understand the signal quality, the review effort, and the AI-credit usage. The strongest result is not a dashboard full of warnings; it is a repeatable process that catches genuine vulnerabilities before the code reaches production.