GitHub announced a focused new Copilot CLI capability on June 10, 2026: the /security-review slash command. According to GitHub’s changelog, the command runs a security review on your local code changes directly from the terminal and ships as an experimental feature in public preview. For QA engineers and SDETs, that is more relevant than it sounds. It puts a lightweight security check closer to the point where test automation code, API helpers, and release scripts are actually being changed.

This is not a replacement for formal AppSec tooling. GitHub is explicit that the new command does not rely on GitHub code scanning, Dependabot, or secret scanning. Instead, it is positioned as an on-demand review layer you can run before you commit. That distinction matters because QA teams should treat it as a fast signal, not a final verdict.

What GitHub actually announced on June 10

  • GitHub says /security-review analyzes local code changes, not just a remote pull request.
  • The command returns high-confidence findings scored by severity and confidence, plus actionable suggestions in the terminal.
  • GitHub says the scan is tuned for common high-impact issues such as injection flaws, cross-site scripting, insecure data handling, path traversal, and weak cryptography.
  • GitHub also says the command is experimental. Its docs show experimental features can be enabled with --experimental or the /experimental slash command.

The last point is easy to miss. This is not a mature compliance gate. It is a preview feature inside Copilot CLI, and the operational expectation should be closer to assistant-guided review than policy enforcement.

Why this matters for QA engineers

QA teams increasingly own more than test cases. They maintain Playwright and Selenium frameworks, API test harnesses, synthetic test-data generators, environment utilities, CI scripts, and helper services around test execution. Those assets can introduce real security risk when rushed changes slip through: unsafe logging of tokens, weak temporary credential handling, permissive file writes, insecure mock endpoints, or brittle sanitization in test-only utilities that later get reused in production-adjacent workflows.

A terminal-native review step is useful because it can be run before a pull request is opened and before a human reviewer has context-switched into the change. That fits common QA workflows better than waiting for a later security pass. If the command reliably flags suspicious patterns in changed test code, it could reduce low-value review churn and help testers catch avoidable mistakes earlier.

A practical QA workflow to test this week

Use GitHub Copilot CLI security review on one narrow class of changes first: test infrastructure updates. Good candidates include auth fixtures, API client helpers, file-upload utilities, and any script that touches secrets, cookies, headers, or local file paths.

/experimental
/security-review

Then compare the output against your existing review checklist. Did the command flag anything you already expect a reviewer to catch? Did it miss an issue your team considers important? Did it produce vague noise that would slow triage down? Those answers matter more than whether the feature feels impressive in a demo.

What QA leads should verify before rolling it out

  • False-positive rate: if it floods reviewers with low-signal warnings, teams will ignore it quickly.
  • Test-code coverage: verify whether it catches patterns common in automation repositories, not just classic app-code issues.
  • Secrets hygiene: confirm whether it surfaces unsafe logging, token handling, or copied credentials in fixtures and utilities.
  • Developer experience: check whether the terminal suggestions are concrete enough to act on without another round of prompting.
  • Workflow placement: use it as a pre-commit or pre-PR advisory step first, not as an autonomous gate.

The key operational point is simple: a helpful AI security review command can save time, but an overtrusted one can create blind spots. QA organizations should measure it against known risky changes and compare the output with their manual review baseline.

Bottom line

GitHub’s June 10, 2026 launch of /security-review is a meaningful update because it moves AI-assisted security feedback directly into the CLI where many QA engineers already work. The feature looks most useful as a fast, local review pass for automation code and support scripts. It does not replace code scanning or human judgment, but it is worth piloting in one controlled workflow.

Sources