Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

GitHub AI security reviews: what now appears in pull requests

GitHub has added AI detections to code scanning and a /security-review command. Understand the prerequisites, limitations and a safe rollout plan for engineering teams.

PUBLIC RESEARCH
AUTHOR
/ CEO, Penetration Tester (OSCP, PNPT)
PUBLISHED
14 July 2026
READING TIME
9 min read
TOPIC
AppSec
GitHub AI security reviews: what now appears in pull requests

On 14 July 2026, GitHub released two AI-assisted code-security features. The first adds AI detections directly to code scanning results on pull requests. The second lets a developer run /security-review in the GitHub Copilot app against work currently in progress.

Moving feedback closer to code creation is useful. It is not, however, “a penetration test on every pull request”. The features have different scopes, prerequisites and trust models, and both are currently described as public previews.

Two features, two workflows

AI detections in GitHub code scanning

The new alerts appear in pull requests alongside the existing code-scanning workflow. GitHub says its AI engine extends coverage to languages and frameworks not currently supported by native CodeQL analysis. Each generated alert carries an AI label so reviewers can identify its source.

Enabling the preview requires:

  • GitHub Code Security;
  • CodeQL default setup on the repository;
  • permission at enterprise level;
  • enablement for the organisation or repository;
  • a GitHub Copilot licence and available AI credits during the preview.

One detail matters: GitHub calls these findings informational. They do not block pull-request merges. That is sensible for a preview, but teams must design their own triage and escalation rules.

/security-review in the Copilot app

The second feature is invoked by a developer on current changes. GitHub says it is tuned for classes including injection, XSS, insecure data handling, path traversal and weak cryptography. Output includes severity, confidence and actionable remediation suggestions.

The command is available in public preview for Copilot Free, Pro, Business and Enterprise plans. It is an on-demand review, not evidence that every change in a repository has been analysed.

What improves

The biggest advantage is not AI itself; it is feedback timing. A vulnerability found before merge is cheaper to fix because the author remembers the context, the diff remains small and a regression test can land in the same branch.

The second benefit is broader coverage. CodeQL is a precise, query-driven semantic-analysis platform, but language and framework support is not uniform. AI may surface a plausible problem in an area that previously sat outside the scanning boundary.

The third benefit is developer experience. When a comment provides a data path, impact and possible fix, security review becomes part of engineering rather than a separate report arriving a week later.

What remains out of view

An AI system reviewing a diff may not understand the complete environment:

  • cloud and runtime permissions;
  • reverse proxies, IAM, secrets and network policy;
  • interactions across services joined by queues or event buses;
  • business flows split between frontend, API and external providers;
  • production data and actual tenant boundaries;
  • logic flaws that look valid inside one file.

The model can also produce a false positive or recommend a patch that silences the symptom while preserving the root cause. Finding and fix therefore need separate verification. Do not auto-accept a change merely because the same system identified the issue and generated the patch.

CodeQL, AI and human review have different jobs

The new layer should complement the existing stack:

LayerBest use
lint rules and secret scanningfast, deterministic defects and exposed credentials
CodeQL / SASTrepeatable data-flow analysis and known vulnerability classes
AI reviewchange context, broader languages, hypotheses and remediation suggestions
human reviewerarchitectural intent, requirements and business risk
dynamic testing and pentestruntime behaviour and chained attack paths

Treat an AI detection as a signal source, not final proof. High-severity findings should require reproduction or a clear technical argument. A proposed fix should include a test that first demonstrates the defect and then proves it is closed.

A rollout that avoids alert fatigue

Week 1: controlled pilot

  1. Select three to five repositories across languages and risk levels.
  2. Do not make AI findings a blocking gate.
  3. Assign an AppSec owner for classification.
  4. Track true positive, false positive, duplicate and “needs context”.
  5. Measure triage time and accepted-remediation rate.

Week 2: calibration

  1. Identify the finding classes with the best signal.
  2. Define an SLA by severity and application exposure.
  3. Add a response template covering impact, evidence, owner, decision and regression test.
  4. Compare AI results with CodeQL, human review and the existing backlog.
  5. Calculate AI-credit cost per accepted finding, not per scan.

After the pilot

Expand only if the control has an owner, measurable noise and a defined response path. An alert without ownership becomes another backlog item rather than a security control.

Minimum evidence policy for AI findings

Retain:

  • commit identifier and analyser version;
  • an explicit AI-source label;
  • the vulnerable flow or condition;
  • reviewer decision and rationale;
  • links to the fix and regression test;
  • reverification status;
  • closure date and owner.

This record makes it possible to tell whether a future model update improves analysis or merely changes the writing style of comments.

Does it replace penetration testing?

No. These features can reduce the number of simple defects reaching production and free reviewers to focus on harder problems. A penetration test examines the running system, cross-component behaviour, authorisation, business logic, configuration and the possibility of combining individually weaker findings into a material attack path.

A mature process uses AI earlier and a web application and API penetration test as independent validation before a high-impact release or after a material architecture change.

Conclusion

GitHub is moving AI analysis into the place where developers already make decisions. That is valuable. A professional deployment still needs source labels, human triage, regression tests and quality measurement against the organisation’s own code.

The worst outcome would be more comments without more verified fixes. The best is faster remediation while CodeQL, human review and runtime testing remain independent layers of evidence.

Primary sources: GitHub — AI security detections on pull requests, GitHub — security reviews in the Copilot app, GitHub Docs — code scanning.

SHARE / COPY