Skip to content
NewsProduct launch

GitHub Copilot brings AI security review into the app for all plan tiers

· by Pondero Newsdesk

The short version

GitHub shipped the /security-review slash command to the Copilot app on July 14, giving every subscriber on every plan tier on-demand vulnerability scanning inside their everyday coding workflow.

GitHub Copilot brings AI security review into the app for all plan tiers

Every GitHub Copilot subscriber on every plan tier can now run a security scan on in-flight code changes directly from the Copilot app. The /security-review slash command launched in the app on July 14 in public preview, moving a capability that had been available only in Copilot CLI into the interface most developers actually use day to day.

What changed

Before this release, /security-review required using Copilot CLI, a terminal-based tool that skews toward developers already comfortable with command-line security workflows. The app expansion removes that prerequisite. Any developer with a Copilot subscription can now type /security-review in the app's chat window and get a vulnerability scan of whatever code they are currently working on, per GitHub's changelog.

That shift matters for adoption. Most Copilot users interact with the tool through the app, not the terminal. Developers who never opened Copilot CLI now have access to the same scanning capability with no additional setup.

What the command does

The scan targets the developer's current workstream, meaning in-progress changes rather than the full repository. That scope keeps the output relevant to what is actually new rather than surfacing issues in code no one is touching.

Per GitHub's announcement, the results come back in three parts: high-confidence findings scored by both severity and confidence level, fix suggestions the developer can apply and re-verify without leaving Copilot, and a prioritized view that puts the most consequential issues at the top. The design keeps everything in one place, so a developer finds a problem, applies the suggestion, and confirms the fix all inside the Copilot chat window.

GitHub says the scanner is tuned specifically for five vulnerability classes: injection flaws, cross-site scripting, insecure data handling, path traversal, and weak cryptography. Each of those appears consistently in lists of common, high-impact bugs. The emphasis on "high-confidence" findings in GitHub's framing suggests an intentional choice to reduce noise. A scan that returns dozens of low-confidence flags is less useful than one that returns three things that are almost certainly real problems.

The command is positioned as a complement to GitHub's existing automated security tooling. Per the changelog, it sits alongside code scanning, Dependabot, and secret scanning rather than replacing any of them. The intent is a lightweight, on-demand check the developer runs themselves before committing, not a replacement for the CI-level safety net.

Who gets access

Copilot Free, Pro, Business, and Enterprise subscribers all have access during public preview, per the announcement. That covers the full plan range, from the no-cost tier to large enterprise deployments.

The flat access structure stands out. Security tooling in developer tools has historically been a premium feature, often gated behind enterprise contracts or higher-cost plan tiers. GitHub did not do that here, at least not at launch. Whether that policy holds at general availability is an open question; the public preview label carries no commitment to the current access model.

To try it: open a project in the Copilot app, make code changes, and run /security-review in the chat window.

Context: GitHub's broader security push on July 14

The /security-review app launch appeared alongside several other security-related Copilot changelog entries on July 14. GitHub also shipped an update that surfaces AI security detections from code scanning directly on pull requests, so findings from the automated CI pass appear alongside the diff without requiring a developer to check a separate dashboard.

The two features are complementary but distinct. /security-review is a manual, in-session check the developer runs on work in progress. The code scanning PR integration is an automated pass that fires as part of the existing CI pipeline. Together they push security signals earlier and closer to where developers are working rather than routing everything through a security-specific tool opened separately.

That orientation has run through GitHub's security product development for several years. CodeQL, Dependabot, and secret scanning each moved GitHub from "security dashboard you check occasionally" toward "security feedback that appears when and where you are writing code." The /security-review app expansion continues that progression.

What to watch next

No general availability date has been set. GitHub published no timeline alongside the public preview announcement.

Pull request comments are the next logical surface for /security-review. If GitHub follows the pattern it used with code scanning, a reviewer on a PR could eventually see a security pass alongside the diff automatically, without the developer needing to run the command manually. GitHub has not announced this, but the July 14 code-scanning-on-PR update points toward exactly that workflow.

The access tier question is also worth watching. A free-tier /security-review during preview is a strong signal that GitHub treats the feature as a user acquisition and retention tool at this stage. If the company moves it behind Business or Enterprise at GA, that would mark a shift: the security review graduated from growth driver to revenue line. If access stays open, the bet is that keeping developers inside the Copilot ecosystem is worth more than the incremental seat revenue.

For teams running Copilot now, the practical implication is straightforward. A scan before committing catches injection flaws and path traversal issues at the cheapest possible point in the development cycle, before code review and long before production. The capability is there now; the question is whether teams build the habit of using it.

Sources