GitHub AI Scan: A Finding Still Needs a Reviewer

A security finding is useful when it changes a decision. If it lands in a pull request and nobody owns it, adding another scanner mostly adds another place to overlook a problem.

GitHub made AI Scan for pull requests generally available on 15 October 2026. It complements CodeQL with analysis for selected languages and frameworks, including Bash, PHP, Terraform configuration and Dockerfiles. That makes it relevant to repositories where deployment code receives less scrutiny than application code.

The first operational decision is who must read its findings before a merge. Write that down before switching it on.

Understand what a green result means

According to the AI Scan documentation, findings are advisory. They do not fail the code scanning check and cannot enforce a merge requirement through rulesets. AI Scan also excludes pull requests from forks and those created by Dependabot, and it does not provide a full repository scan.

Those boundaries matter when reporting coverage. “Code scanning enabled” is too broad a label for a dashboard. Record whether the particular change was eligible, whether a scan completed and whether someone reviewed its findings.

Keep existing review and test requirements in place. A generated finding can direct attention to an unsafe command or missing validation, but absence of a finding does not establish that either is safe.

Use a short, repeatable triage record

The following is a proposed team process. It is deliberately separate from the scanner's own severity label.

Consider a shell step that constructs a command from a pull request value. The review should trace where that value originates and how it reaches the shell. A statement that “this input is internal” is incomplete until the reviewer identifies who can control it and under which event the workflow runs.

Do not manufacture an exploit to make every alert look serious. Equally, do not dismiss a finding because the suggested patch is poor. The diagnosis and the proposed repair are separate things to assess.

Review suggested fixes as ordinary code

Ask whether the change protects the intended boundary, whether it changes valid behaviour and what narrow regression check demonstrates that. An escaping change may address one interpreter while leaving a second interpretation unchanged. A rejected URL may solve one case while accepting an equivalent form elsewhere.

Use a small test that exercises the actual failure path, with inert data and a non-production target. Include one valid case, the relevant invalid case and any boundary that caused the original ambiguity. Record the result after running it; do not paste a suggested test into a pull request and describe the issue as verified.

If the concern belongs in a later change, assign it a person and a date through the team's existing issue process. For a material unresolved issue, the human approval decision should remain outstanding even when the scanner check is green.

Our guide to checks before an AI-assisted merge covers the same practical distinction between a tool producing output and a team accepting a change.

Budget and coverage belong in the pilot

Repository eligibility and billing are separate checks. GitHub's billing documentation states that AI Scan consumes Code Security AI Credits, including for public repositories. Available included credits and spending limits depend on the billing account. A public repository does not by itself make this usage unmetered.

Begin with a bounded set of repositories and estimate the number of qualifying pull requests and revisions. GitHub's feature documentation warns that enabling the organisation setting can start scans across eligible repositories that already have code scanning enabled. Review that effective scope before the change.

For the pilot, track completed scans, excluded changes, actionable findings and review time. Keep false positives with a short explanation so the team can distinguish a noisy rule from a misunderstood application boundary. Do not turn the number of alerts into a productivity target.

A useful pilot ends with an answer to a practical question: did the new signal help reviewers make better decisions at an acceptable cost? If it did, expand the scope with the same ownership model. If it did not, adjust or disable the added scan setting while retaining the existing security checks.

References

• GitHub Changelog: AI Scan for pull requests generally available — 15 October 2026; checked 17 October 2026.
• GitHub Docs: AI Scan for pull requests — checked 17 October 2026.
• GitHub Docs: GitHub Advanced Security license billing — checked 17 October 2026.