GitHub AI Scan Is GA: Add a Review Step for Terraform, Shell, and Docker Changes

What changed on October 15

A small web application can have well-reviewed application code and still ship risky deployment scripts or infrastructure settings. GitHub made AI Scan for pull requests generally available on October 15, 2026. Its stated purpose is to complement CodeQL with detections in selected languages and frameworks outside CodeQL’s current coverage, including Terraform HCL, Shell/Bash, Dockerfiles, PHP, JSP and Blazor.

For teams that build and maintain websites or cloud systems, the practical question is how to review that additional signal. The workflow below is an original proposed pilot, not a test of GitHub’s detection rate. Primary documentation was checked October 19.

1. Verify access and cost before enabling anything

You need an eligible repository, code scanning, an effective AI Scan setting that permits it, and an administrator who understands the billing account. Public repositories under personal or organization accounts are eligible. Private and internal organization repositories require GitHub Code Security or Advanced Security. Current documentation excludes private personal-account repositories and repositories in a managed user account’s personal namespace. A Copilot seat is not required.

Usage consumes Code Security AI Credits. Check included credits, the responsible billing account and applicable budgets; public availability does not mean unlimited free scanning. A hard budget with no available credits prevents findings. Do not publish a repository or migrate its ownership merely to try this feature.

Enterprise permission to use AI Scan does not itself switch scanning on. Organization enablement can immediately activate all eligible repositories already using code scanning, with repository administrators able to opt out afterward. Prepare the affected repository inventory and budget before that organization-wide change. Use an isolated eligible test environment if that is the only way to keep the pilot bounded.

2. Make one ordinary change reviewable

Select an authorized nonproduction repository containing a representative supported format. Record its owner, visibility, effective setting, existing scanners and budget owner. Open a normal same-repository pull request with an intentional maintenance change. Do not add a real credential or deliberately expose a live service to manufacture an alert.

AI Scan runs on qualifying pull requests when created and after new commits. Its AI-labeled findings appear in Conversation and Files changed, alongside CodeQL results. It does not need CodeQL default setup, and a waiting or failed CodeQL analysis does not by itself stop AI Scan. Record the commit you inspected so later edits do not get confused with the reviewed version.

Absence of a finding is not proof the change is safe or even eligible. Confirm the setting, supported changes, origin of the pull request and available credits. Keep existing configuration checks, dependency checks, secret scanning and peer review.

3. Turn a finding into a checkable engineering question

Read the flagged path and surrounding code. For a reported unsafe command construction, trace where the input comes from, how it is validated, which identity executes it and whether the affected path runs in your deployment. An explanation can be plausible while missing those conditions.

Suggested review prompt for an approved assistant: ‘Using only this finding, the supplied diff and the referenced files, explain the suspected input-to-operation path. Cite file and line references. List the conditions needed for the issue to occur and the evidence still missing. Propose the smallest correction and a focused regression check. Do not invent reachability, severity or a successful test.’

Expected output is a hypothesis and a proposed verification plan. A reviewer should reproduce relevant behavior safely or document why the evidence is insufficient. If an autofix is offered, inspect the diff and run the appropriate tests; a generated patch can alter behavior or miss a related path.

4. Keep the merge decision visible

AI Scan findings are advisory. They do not fail the code scanning check and cannot be made a merge-blocking ruleset requirement. A pull request can therefore have passing required checks and an unresolved AI finding. Put a named security reviewer and a documented disposition into the existing review process when a material finding needs attention.

Fork and Dependabot pull requests are excluded, and AI Scan does not perform full repository scans or create ordinary backlog alerts in the repository security view. Retain the established safe validation process for those paths. Do not give untrusted workflows broader credentials to obtain extra coverage.

What a useful pilot should leave behind

Keep the effective configuration, eligibility gaps, actual credit use and reviewed findings together. Compare confirmed useful findings with unsupported ones, and record reviewer effort. Do not turn alert volume into a detection benchmark. Expand only after the team knows which changes are covered, who receives findings and what the ongoing cost looks like.

• Coverage: list eligible changes and the excluded contribution paths.
• Evidence: retain the reviewed commit, disposition and actual test result.
• Ownership: name the triage owner and the person monitoring the AI credit budget.