Back to blog
IASeguridadDevOps

GitHub AI Scan adds useful security review for Laravel and homelab projects

GitHub can inspect PHP, Dockerfiles, Shell, and Terraform changes inside pull requests without adding a CodeQL workflow.

By Isma5 min read

The gap between the app and the deployment

A Laravel project is rarely just PHP. It usually includes a Dockerfile, deployment scripts, environment variables, GitHub Actions, and often Terraform for infrastructure. That is a normal setup when an app runs on a VPS, a small cluster, or a homelab. The problem is that security review for those files is easy to skip when reviewing a pull request in a hurry.

GitHub has made AI Scan for pull requests generally available. It is a security-focused scan for changes included in a pull request, especially for languages and formats that CodeQL does not cover. For a Laravel app deployed with Docker and automated with shell scripts, that covers a useful part of the repository. (github.blog)

What it can inspect in a Laravel repository

AI Scan supports PHP, Shell/Bash, Terraform configuration in HCL, and Dockerfiles, among other formats. It is not a replacement for any PHP analysis you already run, but an extra layer for the changes entering a pull request. That matters when application code and infrastructure live in the same repository. (docs.github.com)

GitHub documents detection categories including string injection, weak cryptography, broken access control, sensitive data exposure, insecure configuration, and SSRF. It also includes supply-chain risks, such as third-party actions, packages, or images that are not pinned appropriately. That does not mean it will catch every issue in those categories, but it can flag changes worth reviewing more closely. (docs.github.com)

In practice, it is useful when a pull request adds an HTTP request built from user input, loosens a security setting in Laravel, or changes a container base image. The same applies to deployment scripts handling secrets, URLs, or dynamically assembled commands. Those are often small diffs that are easy to approve quickly and much harder to undo after deployment.

No extra pipeline to build

The practical part is that AI Scan does not need a build configuration and does not rely on CodeQL default setup being enabled. Code scanning must be enabled for the repository, and the AI Scan on pull requests setting must be turned on. Once those conditions are met, GitHub runs the scan when a pull request is opened and after each new commit. (docs.github.com)

This does not replace tests, PHPStan, Larastan, or a proper code review. Each tool looks for different classes of problems, and none of them fully understands the business rules of an application. AI Scan works best as an extra signal in the place where changes are already discussed: the pull request.

If you manage repositories through an organization, the setting can also be controlled with the GitHub REST API. The documented parameter is pr_scan, and it accepts enabled or disabled. Before enabling it across every repository, check the enterprise policy and the billing model that applies to your account. (docs.github.com)

curl -L \
  -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/repos/OWNER/REPO/code-scanning/ai-scan" \
  -d '{"pr_scan":"enabled"}'

Where the findings show up

Results are shown in the pull request's Conversation and Files changed tabs, alongside CodeQL alerts. GitHub labels them with an AI indicator so they can be identified separately. Each finding explains the risk and, in many cases, includes a suggested remediation through Copilot Autofix. (docs.github.com)

A suggested fix is not a reason to apply a patch without reading it. It may address the pattern that was detected while breaking an application-specific or deployment-specific assumption. Treat it as a starting point for a change that still needs review, tests, and context.

The important limitations

AI Scan only examines pull requests; it does not perform a full repository scan or create a historical backlog in the repository security view. If a project already contains years of unsafe scripts, old images, or inherited configuration, this feature will not discover them by itself. You still need a deliberate repository review and the rest of your security tooling. (docs.github.com)

The findings do not block merges either. They are advisory, do not fail the code scanning check, and cannot currently be used as a ruleset merge requirement. If a condition must stop a deployment, you still need tests, custom checks, or another enforceable control. (docs.github.com)

It also does not run on pull requests from forks or on pull requests created by Dependabot. That matters for open-source projects accepting external contributions and for repositories relying on automated dependency updates. Do not build a security process around the assumption that this scan covers every incoming change. (docs.github.com)

Like any AI-based system, it can produce false positives. A finding is not proof that a vulnerability exists, and the lack of a finding is not proof that a change is safe. My approach would be simple: use it to spend more attention on PHP, containers, scripts, and infrastructure changes, not as a substitute for technical review.

Availability and cost

Public repositories owned by organizations or personal accounts can use AI Scan. For organizations, private and internal repositories require GitHub Code Security or GitHub Advanced Security; private repositories under personal accounts are not eligible. A GitHub Copilot license is not required. (docs.github.com)

Usage consumes Code Security AI Credits and can be constrained by budgets configured on the billing account. If a hard budget leaves no available credits, AI Scan stops producing findings until the limit is increased or a new billing cycle begins. That is worth checking before enabling it across an organization. (docs.github.com)

For a Laravel repository using Docker, Bash, and Terraform, AI Scan looks like a sensible extra layer because it covers the area where application code meets infrastructure. It does not require another workflow or a complex configuration just to get started. The important part is not mistaking those signals for a security guarantee or a control that will stop a merge.


Source: GitHub Changelog — AI Scan for pull requests generally available Official documentation: AI Scan for pull requests

Newsletter

What I learn coding with AI, every two weeks in your inbox.

Real numbers, mistakes included. No spam, unsubscribe in one click.

No spam, unsubscribe in one click. I only use your email to send you this and the newsletter. More in the privacy policy.