GitHub Copilot /security-review: Verify AI Findings Before You Commit

GitHub has added an on-demand security review to the GitHub Copilot app. The /security-review slash command examines in-flight workstream changes and returns prioritized findings before the code lands. GitHub announced the command in public preview on July 14, 2026 and says it brings AI-driven vulnerability scanning already available in Copilot CLI into the app workflow.

GitHub documents the command, availability, output, and targeted vulnerability classes described below. The verification process in this guide is inferred defensive guidance. CodeRiskTools did not independently test the hosted Copilot review engine, reproduce its detections, or measure false-positive or false-negative rates. Treat each result as a review lead: neither a finding nor a clean response is a security verdict.

What the command does—and what remains your responsibility

GitHub says /security-review analyzes current workstream changes and returns high-confidence findings scored by severity and confidence, with suggestions that can be applied and reverified. The vendor says the scan focuses on common high-impact classes including injection, cross-site scripting, insecure data handling, path traversal, and weak cryptography. During the preview, GitHub lists Copilot Free, Pro, Business, and Enterprise users as eligible.

Those statements describe the vendor’s intended behavior, not demonstrated coverage for your repository. The changelog calls the check lightweight and on demand, and says it complements code scanning, Dependabot, and secret scanning. Keep those lanes separate. A local change review cannot establish that dependencies are safe, credentials were never committed, deployed configuration is correct, or every reachable code path was analyzed.

Preflight: freeze the scope before scanning

Start by recording the repository, branch, base commit, current head commit, and a clean or intentionally dirty working-tree state. Save the exact diff you intend to review. If generated files, submodules, ignored files, untracked files, or local configuration affect the change, identify them explicitly. Without a frozen scope, a later “fixed” result may refer to different bytes than the original finding.

Run the command with least-privilege credentials and a bounded environment. Remove production tokens and customer data from prompts, fixtures, logs, and screenshots. If the review can invoke tools or inspect external resources in your setup, confirm what access is enabled. A security scanner should not become a new route for sensitive data exposure.

A seven-step verification workflow

1. Capture the baseline. Record the exact head SHA, diff, relevant configuration, command time, Copilot app version if visible, and whether the feature is in preview.
2. Run the review once. Preserve the returned class, severity, confidence, location, explanation, and proposed change. Do not paste secrets into a ticket to make the evidence complete.
3. Trace attacker control. Identify who can influence the input, which trust boundary it crosses, the sensitive operation it reaches, and the realistic impact. Read callers and configuration beyond the highlighted line.
4. Create a synthetic negative test. Reproduce the suspected behavior with non-sensitive data. Include an expected rejection or safe output, not merely a successful application start.
5. Repair the boundary. Prefer strict parsing, contextual output encoding, server-side authorization, safe APIs, path containment, parameterized queries, and least privilege over comments or prompt wording.
6. Review the proposed patch independently. Inspect every changed line, generated dependency change, test modification, and exception path. A Copilot-generated fix can introduce a different defect.
7. Re-run and reconcile. Repeat the command on the new head, run the negative test and broader suite, then record fixed, not reproduced, accepted risk, or blocked with the responsible reviewer.

How to verify a suggested fix

A disappearing alert is useful evidence, but it is not enough. First prove that the original unsafe behavior fails under the repaired code. Then add boundary cases: encoded input, alternate content types, nested paths, symbolic links where relevant, missing authorization context, and error handling. Finally run regression tests around legitimate behavior so a security repair does not silently break the product.

For cryptography findings, verify the actual primitive, parameters, key source, rotation path, and storage rather than changing an algorithm name in one function. For injection or cross-site scripting, test the real sink and rendering context. For path traversal, resolve and contain canonical paths at the operation boundary. The OWASP Code Review Guide is an independent community reference for structured manual review, but it does not validate a specific Copilot result.

Keep complementary controls independent

• Code scanning: preserve its query identity, extraction status, and alert trace instead of merging it into an AI-review count.
• Secret scanning: search committed history and active credentials through its own workflow; do not assume a change-only review covers them.
• Dependabot: keep advisory, affected-range, fixed-version, and update-error evidence separate from source-code findings.
• Tests: pin the test result to the reviewed commit and include security-negative cases.
• Human approval: require an accountable reviewer to reconcile conflicting tools and residual risk.

If any lane is disabled, times out, lacks entitlement, or cannot inspect a file type, record not measured rather than “clean.” This distinction is especially important during a public preview, where availability and behavior may change.

Evidence checklist before commit

• The reviewed base, head SHA, and complete intended diff are recorded.
• The working-tree and generated-file scope is explicit.
• The Copilot output is attributed as vendor-generated, not CodeQL evidence.
• Attacker control, trust boundary, sensitive operation, and impact were inspected.
• A synthetic negative test reproduces or meaningfully challenges the finding.
• The proposed fix received line-by-line human review.
• The original unsafe case fails after repair and legitimate behavior still passes.
• Code scanning, dependency, secret, and test lanes have explicit statuses.
• No real credential, private repository content, or customer data was copied into public evidence.
• The final decision names the exact commit, reviewer, outcome, and residual risk.

Common interpretation mistakes

Do not equate “high confidence” with confirmed exploitability or “no findings” with complete coverage. Do not apply a suggested patch without testing the original path. Do not let the scan of current changes erase risk in unchanged callers, configuration, dependencies, or deployment policy. And do not count two tool alerts as two vulnerabilities until their source, sink, location, and root cause have been reconciled.

Conversely, an AI-generated alert should not be dismissed only because it came from an AI system. Investigate its evidence. A defensible dismissal identifies a concrete control—such as framework-enforced contextual encoding, an unreachable path, strict allowlisting, or a tested authorization boundary—and pins that explanation to the reviewed commit.

FAQ

Does /security-review replace GitHub code scanning?

No. GitHub explicitly describes it as complementary to code scanning, Dependabot, and secret scanning. Keep independent status and evidence for each control.

Can I treat a clean response as merge approval?

No. It means no finding was returned for that invocation and observed scope. It does not demonstrate complete file, language, runtime, dependency, or configuration coverage.

Should I apply Copilot’s suggested fix automatically?

No. Review the patch as untrusted code, reproduce the original issue with synthetic data, add boundary cases, and run regression tests on the exact new commit.

Who can use the command during preview?

GitHub’s July 14 changelog lists Copilot Free, Pro, Business, and Enterprise users. Check the current vendor page and your account because preview availability can change.

Official sources and next step

• GitHub Changelog: security reviews in the GitHub Copilot app — vendor documentation for command behavior, preview availability, output, and targeted classes.
• GitHub Docs: responsible use of GitHub Copilot code review — vendor guidance on human validation and feature limitations; this page covers Copilot code review generally, not an independent test of the slash command.
• OWASP Code Review Guide — independent community guidance for structured manual security review.

Continue with the CodeRiskTools guides for security validation of third-party coding agents, CI gates for AI-generated code, and secret scanning AI-assisted changes. Use the single comparison hub to distinguish tool scope without converting feature lists into security guarantees.