GitHub pulls /security-review out of the CLI and into the Copilot app

The cheapest place to review code is in the author's head, thirty seconds before they push it. The most expensive place is on-call, after prod. Everything in between is negotiation. On July 14, the GitHub Changelog announced its latest attempt to move that negotiation earlier: the /security-review slash command is now available directly inside the Copilot app, in public preview.

The mechanic that actually changed

Per the changelog, /security-review runs from the Copilot app chat and scans your in-flight code changes for a set of well-known bug classes: injection, cross-site scripting, insecure data handling, path traversal, and weak cryptography. It returns findings ranked by severity and confidence, some inline suggestions, and a prioritised list of things to fix before you ship. Not exotic categories. The ones that show up in every retro.

The command itself is not new. GitHub notes the same review capability was already available in the Copilot CLI. What changed is the surface it lives on. It now runs in the same window as the code you are editing, without a context switch to a terminal.

Access, at least during the preview, is broad. The changelog lists Copilot Free, Pro, Business, and Enterprise as eligible. If you have a seat, you have the button.

Where it lands in a CI/CD pipeline

Look at where security signals typically fire today. Code scanning runs on the pull request. Dependabot runs on the manifest, on a schedule. Secret scanning runs on the push. All of them tell you something after you have already committed the change, and usually after you have already asked another human to look at the diff.

/security-review sits in front of all of that. It is a pre-PR pass, on the diff you have not committed yet, in the editor you are already in. GitHub's own framing calls it a complement to code scanning, Dependabot, and secret scanning, and that framing is honest: none of the existing controls disappear, one more control appears earlier.

Why does that matter to a CI/CD practitioner? Because every finding that reaches a PR costs a review round-trip, every finding that reaches main costs a revert or a follow-up patch, and every finding caught in the authoring loop costs the author roughly fifteen seconds. The pipeline math is not subtle.

Using it in practice

The flow the entry describes is: you edit code, you open the Copilot app chat, you type /security-review, you get findings on the current in-flight changes with severity and confidence, plus suggestions the app can apply in place.

There is no YAML to paste here. /security-review runs in the editor, not in CI. That is the whole point, and also the first thing to notice about the model.

The seams to watch

A slash command is not a required check. It is not a gate. It is not, in the preview form the changelog describes, an artifact that shows up on the pull request, a status a branch protection rule can require, or a policy a security team can enforce across every repo.

Consequences worth thinking through before you sell it upstream as a control:

• Nothing forces the developer to type the command. An authoring-loop check that relies on discretion has the same failure mode as a review checklist nobody opens.
• Findings live in the app session. Whatever you need your CI to block on must still come from code scanning, secret scanning, Dependabot, or a workflow you wrote yourself. This layer produces conversation, not evidence.
• The vulnerability classes the changelog lists are the well-lit ones. Injection, XSS, path traversal, weak crypto: pattern-matchable, high-recall. Business-logic flaws, authorisation gaps, and reasoning bugs that span multiple files are not on the list, and there is no reason to assume the tool silently covers them.
• Public preview means the behaviour will shift. Findings today may not be findings next month. If you build habits around a specific severity threshold now, expect to retune when the model or the ruleset changes.

None of this is a reason to skip it. It is a reason to be honest about what layer it is at. /security-review is an authoring aid, not a compliance control. Treat it accordingly.

How the neighbourhood approaches the same problem

Pre-PR security feedback is not a new idea, just a newly convenient one. IDE-side static analysis has been shipping for years from independent vendors and open-source projects: editor integrations from Snyk, Semgrep, SonarLint, JetBrains' bundled inspections, and various Checkmarx and Veracode plugins. They all trade depth for latency, and each one lives or dies on how the ruleset matches the code you actually ship.

The move GitHub is making here is closer to the LLM-flavoured version: an interactive pass in prose, with suggestions, rather than a deterministic rule engine spitting a hit list. If your workflow already sits in an editor Copilot does not run in, or if you have invested in a Semgrep ruleset that reflects your organisation's real risks, the marginal value of one more slash command is real but bounded. What actually moves the security posture of a pipeline is what you require in CI, what artifacts those checks produce, and what breaks the build. That layer is unchanged by this release.

The kicker

Shift-left is a slogan. /security-review is a slash command. The distance between the two is measured in whether anyone remembers to type it.