Copilot /security-review Moves Vuln Catching Earlier

Security feedback that shows up after you open a PR is late feedback. You have already lost the mental context of the change, the fix costs more, and the path of least resistance is to ship and hope CI is kind. GitHub Copilot is now shipping a public preview of /security-review inside the Copilot app, bringing the same AI-driven scan that landed experimentally in Copilot CLI into the place many developers already work. The pitch is simple: run a focused security pass on your current workstream changes before the code lands.

That is a genuine workflow shift, not a rebrand of existing scanners. It will not replace GitHub code scanning, Dependabot, or secret scanning. Used as a pre-commit first pass, though, it closes a gap those tools never owned.

What the command actually returns

Open a project in the Copilot app, make your changes, and run /security-review. The command analyzes the in-flight diff and returns high-confidence findings scored by severity and confidence, plus actionable suggestions you can apply and re-check without leaving Copilot. GitHub is deliberately filtering for signal over volume. The scan is tuned toward common, high-impact classes: injection flaws, cross-site scripting, insecure data handling, path traversal, and weak cryptography.

The earlier CLI experimental version spelled out a broader set of patterns the model is meant to reason about from a change set: broken access control, auth and session handling issues, secrets and sensitive data exposure, SSRF, unsafe file and path handling, insecure cryptography, unsafe deserialization or dynamic execution, and security-sensitive misconfiguration. The shared design goal is the same. Flag things that are likely useful and actionable, not every theoretically possible smell.

This is LLM inference over the current diff, not a deterministic rule engine walking the whole tree. That is both the feature and the limit. You get speed and context while the change is still hot. You do not get full-repo taint analysis or dependency CVE matching.

Where it sits in the real security stack

GitHub is explicit that /security-review complements, rather than replaces, dedicated tooling. Code scanning with CodeQL still owns deep, cross-file analysis and CI gating. Dependabot still owns dependency risk. Secret scanning still owns credential leaks. Manual review still owns architecture and business logic. The new command sits earlier: a lightweight, on-demand check while the developer still has full context of the edit.

That pre-commit window has been underserved. Most teams get security signal only after push, when the cost of a fix has already gone up and the temptation to defer is high. AI-assisted coding made the gap worse. Models write faster than review processes were designed for, and generated code still needs security scrutiny. A fast, local-ish first pass on the exact lines you just touched is the right product shape for that problem.

Related work in the broader Copilot security surface (autofix for CodeQL alerts, AI-assisted PR reviews) attacks later stages. /security-review is the one that tries to keep the vulnerability from ever becoming a PR comment.

How developers should actually use it

During public preview the command is available to Copilot Free, Pro, Business, and Enterprise users. The workflow is intentionally low ceremony:

1. Work in the Copilot app as usual.
2. Stage or simply hold the changes you care about.
3. Run /security-review.
4. Apply suggestions that hold up under your own judgment, then re-run if needed.

Treat the output like a sharp junior reviewer who knows the OWASP greatest hits and is biased toward high-confidence calls. Accept the fix when the finding is real and local. Ignore or escalate when the model is guessing about auth boundaries or multi-file data flow it cannot see.

Practical placement in a day:

• After a non-trivial edit that touches input handling, templates, queries, paths, or crypto.
• Before you open a PR that includes AI-generated code you have not fully audited.
• As a personal gate before you hand the change to someone else for review.

It is not a substitute for branch protection or required CodeQL status checks. Keep those. Use /security-review to reduce the number of findings those systems ever see, and to fix the easy ones while the code is still warm.

Teams that already run prompt-driven security reviews in Copilot Chat will find this tighter and more automatic. The slash command is scoped to the workstream diff and returns structured severity and confidence instead of free-form chat. That is better for habit formation than a custom prompt library you have to remember to invoke.

Limits worth keeping in view

Scope is the main one. The command sees the current changes, not the full program. It will miss issues that require cross-file taint tracking, whole-repo configuration analysis, or dependency graph reasoning. CodeQL still wins those fights.

Confidence filtering cuts noise, which is good for adoption, but it also means silence is not a clean bill of health. Absence of findings means "nothing high-confidence in this diff," not "this change is safe."

The CLI path that preceded the app feature has its own trust-model history (prompt-injection research against the CLI surface). The app command inherits the same general caution you should already apply to any AI tool that reads your code: use it on your own changes, keep stronger controls in CI, and do not treat the output as an audit artifact for compliance.

Custom org rules, export into CI, and deeper GHAS integration are the obvious next asks from early feedback. Until those exist, this remains a developer-local tool, not a policy engine.

Worth enabling now

The thesis holds. Moving a high-confidence, diff-scoped security pass into the Copilot app is the correct shift-left move for the vulnerability classes that dominate everyday coding mistakes. It is production-useful today as a fast first filter, especially on AI-touched changes, and it is not yet (and may never be) a replacement for CodeQL, secret scanning, or human review.

Turn it on for the public preview. Run it on the next change that touches untrusted input. Keep your real scanners in CI. The teams that win are the ones that catch the boring injection and path bugs in under a minute, then let the heavy tools focus on what only they can see.