GitHub Copilot adds /security-review: integrate it without false confidence

GitHub has added a /security-review command to the Copilot app. From a work session containing in-progress changes, a developer can request a focused vulnerability analysis before opening a pull request. Results rank findings by severity and confidence, then suggest changes that can be applied and verified in the same session.

The command is in public preview for Copilot Free, Pro, Business and Enterprise users. It targets issues including injection, cross-site scripting, insecure data handling, path traversal and weak cryptography. Moving detection closer to implementation is useful, but the result must not become an automatic authorization to merge.

The short answer

Its strongest position is an early, on-demand review. It may catch an issue while context is fresh and before a diff grows into a large pull request. It does not offer the exhaustiveness, reproducibility or governance of a complete security pipeline.

Review inside the local workflow

The command runs in an active Copilot app session. GitHub refers to the current “workstream”: the agent can inspect changes made in that session against repository context. A developer enters /security-review, waits for analysis and examines a prioritized list.

Proximity has a tangible advantage. A SQL injection reported minutes after implementation is cheaper to fix than an alert arriving after a long CI run or during final review. The author still remembers the purpose, design constraints and available tests.

It also creates a boundary. Anything outside the visible workstream may be missed: deployed configuration, infrastructure, dynamic dependencies, firewall policy, the real database schema or a third-party service. A convincing analysis of incomplete context is still incomplete.

The vulnerabilities it targets

GitHub says the command is tuned for high-impact, high-confidence findings. Announced categories include:

• injection into queries, commands and interpreters;
• cross-site scripting when untrusted data reaches HTML output;
• insecure handling of sensitive data;
• path traversal and insufficiently constrained file access;
• weak or incorrectly applied cryptographic primitives.

This selection attempts to control noise. A tool commenting on every style detail is eventually ignored. High confidence does not eliminate false positives, however, and the announced list is not a coverage guarantee. Business authorization defects, race conditions, logic flaws and cross-service interactions frequently require more context than a classic vulnerable pattern.

Teams should evaluate the tool against their own incidents and historical vulnerabilities. If the ten most serious recent defects involved tenant isolation or cloud permissions, good injection detection alone does not prove fitness.

Three products that serve different roles

GitHub now offers several mechanisms with similar-sounding names:

Dependabot covers another dimension: dependency versions and known vulnerabilities. Secret scanning searches for exposed credentials. None is a perfect duplicate of another.

/security-review is fast and conversational. CodeQL provides repeatable analysis, tracks alerts over time, identifies when they appeared and can support merge protection. Copilot code review can reason more broadly about a pull request, but GitHub explicitly warns that it may miss issues and that human validation remains necessary.

A sound architecture layers controls with different properties. Replacing scanners with a model conversation would reduce traceability precisely when an organization needs it most.

The plausible-fix problem

A generated suggestion may look precise, compile successfully and still relocate the vulnerability. Escaping one string may leave another path unprotected. Adding browser-side validation does not secure an API. Replacing a cryptographic algorithm without migrating existing data may lock users out or leave an incomplete transition.

Treat the proposed fix as an external contribution:

1. understand the described attack scenario;
2. confirm that attacker-controlled data reaches the sensitive operation;
3. write a test that fails before the fix;
4. apply the smallest appropriate change;
5. rerun functional, static and security tests;
6. inspect neighboring paths and similar calls;
7. have a component owner review the diff.

Confidence scores help prioritize investigation; they are not proof. A high-confidence alert may be neutralized by validation outside the visible context. No alert does not prove that authorization is correct.

Limit the context being shared

Security analysis naturally encourages developers to reveal configuration, logs and sensitive code. Before enabling the command, organizations should understand their Copilot settings, retention policy and which data may enter the service. A real secret must never be pasted into chat to explain an authentication flow.

The workstream may include temporary files, migrations with sample records or local configuration. Repository guidance should exclude secrets and identify confidential resources. Local secret scanning and push protection remain necessary because security review is neither announced as a vault nor an exhaustive credential detector.

An enterprise pilot should start on a noncritical or representative service with synthetic data. The purpose is to observe what is analyzed, what appears in results and how developers react before extending it to regulated components.

A preview should not become a blocking dependency

GitHub states that the command is in public preview and subject to change. Its interface, availability and result format may evolve. It should not become the only mandatory delivery step with no fallback during an outage.

Required controls should remain automated and observable in CI. The command can be recommended for sensitive files, added to a checklist or used before human review. If an organization makes it essential, it should document a degraded path: local static analysis, a security-owner review or the CodeQL pipeline.

This distinction also prevents screenshots from becoming audit evidence. A one-off conversation may not generate a signed, comparable and retained artifact like a SARIF result. Repository alerts and CI logs are stronger evidence.

Running a useful pilot

A two-to-four-week pilot can follow a straightforward protocol:

1. select two repositories representing major languages and risks;
2. define triggers such as authentication, queries, files, HTML rendering, cryptography and permissions;
3. retain the existing CI and human review;
4. classify every finding as true positive, false positive or unverifiable;
5. record vulnerabilities found later but missed by the command;
6. measure triage and remediation time;
7. verify suggested fixes with regression tests;
8. collect feedback without asking developers to self-certify the product;
9. compare results with CodeQL, dependency scanners and human review;
10. decide whether use should be recommended, required on selected paths or abandoned.

Useful metrics include true-positive rate, severity of detected issues, time saved and defects introduced by suggested fixes. Raw comment volume is misleading: five precise alerts are worth more than fifty ignored observations.

Where it belongs in the human pipeline

The ideal moment is after initial local tests and before opening a pull request. The code is complete enough to understand, while the author can still restructure it without disrupting an active review. A second run makes sense after a substantial tool-suggested fix.

The sequence can become: local tests, /security-review, remediation and regression tests, pull request, CI scanners, human review, then merge rules. Every stage contributes a different property: speed, reproducibility, expertise and governance.

The command adds little to a routine documentation edit. It deserves attention for a new authentication route, file upload or dynamically constructed query. Risk-based triggering preserves the team's focus.

Adoption checklist

• document which repositories and data may be used with Copilot;
• keep CodeQL, Dependabot, secret scanning and existing tests;
• never merge solely because no finding was returned;
• require a reproducing test for each confirmed vulnerability;
• review every generated fix;
• monitor false positives and, especially, known false negatives;
• define a fallback when the preview is unavailable;
• keep blocking rules in the CI platform;
• train developers to separate severity, confidence and exploitability;
• reassess the process when the command becomes generally available.

/security-review usefully brings security closer to the moment code is written. Its strength is a short, contextual and actionable loop. Its weakness would be turning that convenience into certification. Used as a first look before scanners and people, it can reduce the cost of errors. Used as a final verdict, it mainly creates a new source of false confidence.