Copilot CLI Gets /security-review. Treat It as a Fast First Pass, Not a Security Program.

GitHub just put a security reviewer in the terminal. That is useful. It is also exactly the sort of feature teams will misuse if they are desperate for a checkbox.

Copilot CLI now has an experimental /security-review command for reviewing local code changes before they reach a pull request. GitHub says the command returns high-confidence findings with severity, confidence, and actionable suggestions. It is tuned for common high-impact vulnerability classes: injection flaws, cross-site scripting, insecure data handling, path traversal, weak cryptography, broken access control, authentication and session issues, server-side request forgery, unsafe file handling, unsafe deserialization or dynamic execution, and security-sensitive misconfiguration.

That list is not decorative. It maps to the places modern application code actually gets hurt: data crossing a trust boundary, user-controlled input reaching interpreters, auth checks drifting out of sync with product behavior, file paths becoming authority, and “temporary” dynamic execution living long enough to become architecture. A fast AI-assisted review loop can help developers notice those problems while the diff is still fresh in their head.

The terminal is the right place for early security friction

Security feedback is most valuable before the developer has emotionally moved on. Pull-request comments often arrive after the author has switched tasks. Code scanning alerts may show up after CI. A formal security review may happen after the design has already hardened into “too late to change cheaply.” A terminal command that looks at local changes can catch issues at the cheapest possible moment: before the branch leaves the laptop.

That is the strongest argument for /security-review. It puts a focused check in the same environment where developers already run tests, formatters, linters, and git commands. It also fits the way AI coding tools are actually being used. Developers and agents are editing more files faster, often across glue code, request handlers, auth paths, template rendering, shell/database boundaries, and serialization logic. A quick pass over high-impact vulnerability classes is good friction.

But GitHub is careful about the framing, and teams should preserve that caution. The changelog explicitly says this does not replace code scanning, secret scanning, dependency scanning, or manual security review. Good. The command is a feedback loop, not a control. The difference matters.

LLM-powered review is good at contextual suspicion. It can reason that a value came from a request, passed through weak validation, and landed in a dangerous sink. It can notice that an authorization check moved below a data access call. It can flag “this is probably user-controlled HTML” in a way a generic rule might miss. But it is not an exhaustive scanner. It is not a CVE database. It is not a partner-integrated token revocation system. It is not a repeatable policy engine with SARIF output and audit semantics unless GitHub makes it one.

Use it where ambiguity is high and cost of delay is low

The rollout pattern should be explicit. Enable experimental mode for a pilot group, not the entire organization by surprise. Ask those developers to run /security-review on changes that touch authentication, authorization, database queries, command construction, file upload/download paths, template rendering, cryptography, deserialization, external requests, session handling, and security-sensitive configuration. Also run it on agent-generated pull requests before they are opened or before review starts.

The prompt discipline matters. Broad prompts like “is this secure?” produce theater. Better prompts are narrower: review changed request handlers for auth bypass; check this shell command construction for injection; inspect uploaded-file path handling; look for unescaped HTML paths; review SSRF risk in this URL fetcher. The command may package a security-review behavior, but developers still need to aim it at the risk.

Teams should track whether findings are actionable. If the command catches one real path traversal or auth bypass before pull request review, it earns its keep. If it produces a stream of vague warnings that reviewers learn to ignore, it becomes another alert channel with AI branding. The practical metric is not “number of findings.” It is “number of real issues caught earlier than they would have been otherwise, without training developers to trust noise.”

There is also a cost and quota wrinkle. Copilot CLI’s README describes the tool as terminal-native, powered by the same agentic harness as GitHub’s Copilot coding agent, with repository, issue, pull request, MCP, action preview, LSP, and model-selection support. It also says each prompt submitted to Copilot CLI reduces the monthly quota of premium requests by one. Security review on every save is probably the wrong default. Security review on meaningful diffs and risk-bearing files is much more defensible.

AI review should make existing controls sharper, not optional

The healthier mental model is “pre-commit reviewer,” not “security program.” Keep CodeQL or equivalent code scanning as the repository-level analysis layer. Keep secret scanning for credentials, because token formats and partner revocation flows are not a vibes problem. Keep dependency scanning for known vulnerable packages. Keep human review for business logic, product-specific authorization, abuse cases, and architecture-level risk. Then use /security-review to shorten the feedback loop before those systems have to catch everything.

This is especially important for AI-generated code. Coding agents can be confidently wrong in a very specific way: they produce plausible glue code that compiles, passes a happy-path test, and quietly violates a boundary. They may choose an unsafe default because it is common in examples. They may preserve a bad pattern from nearby code. They may add a helper that works for trusted input and then call it from an untrusted path. A fast security pass over local changes is a useful counterweight, but only if the team remembers that one AI system reviewing another AI system is not independent assurance.

The better workflow is boring: agent writes code, developer reads the diff, /security-review looks for high-impact issues, tests run, code scanning runs, secret scanning runs, dependency checks run, and a human reviewer signs off. If that sounds like too many layers, the alternative is pretending a slash command has the same authority as a security program. It does not.

My take: this is a good feature precisely because it lives early in the loop. GitHub should keep pushing security feedback closer to the edit point. Teams should adopt it with discipline, measure whether it catches real bugs, and reject any attempt to turn “the AI reviewed it” into a merge criterion. Fast first pass: approved. Replacement gate: request changes.

Sources: GitHub Changelog, GitHub Community discussion #196523, github/copilot-cli README, GitHub Docs: code scanning, GitHub Docs: secret scanning