Security reviews are now available in Copilot CLI (experimental)

[coadaflorin]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Copilot in GitHub

Body

Overview

AI is changing how developers write code, and security needs to meet developers earlier in the flow. Copilot CLI now includes an experimental /security-review command that helps developers review code changes for potential security vulnerabilities directly from the terminal.

The goal is simple: give developers a fast way to ask, "Did I just introduce a security issue?" before code makes it to a pull request.

What does it do?

The /security-review command analyzes code changes and looks for high-confidence security issues. When it finds something worth calling out, it provides context, severity, and confidence so developers can understand the risk and decide what to do next.

It is designed as a security-focused code review companion in the CLI: no tool switching, no extra dashboard, and no waiting until later in the development lifecycle to get feedback.

Why this matters

Models are getting better at writing code, but code generated or edited with AI still needs security reviews. Developers are moving faster, and security feedback needs to keep up.

By bringing security review into Copilot CLI, we are making secure development easier to access where many developers already work. This is useful when iterating locally, validating changes before opening a PR, or checking AI-generated code before it becomes part of a larger change.

What kinds of issues can it look for?

The command focuses on security-relevant code patterns that can be reasoned about from the changes being reviewed, including:

• Injection risks in database queries, shell commands, templates, or dynamically constructed expressions.
• Cross-site scripting risks from rendering user-controlled content without appropriate escaping or sanitization.
• Broken access control, such as missing authorization checks or trusting client-controlled values for sensitive decisions.
• Authentication and session handling issues, including insecure token handling or risky authentication flows.
• Secrets and sensitive data exposure, such as logging tokens, exposing credentials, or mishandling private data.
• Server-side request forgery risks from fetching attacker-controlled URLs without sufficient validation.
• Unsafe file and path handling, including path traversal, unsafe archive extraction, or writes based on untrusted input.
• Insecure cryptography, such as weak algorithms, hardcoded keys, or incorrect use of encryption APIs.
• Unsafe deserialization or dynamic execution involving untrusted input.
• Security-sensitive misconfiguration, such as permissive defaults, disabled protections, or unsafe debug behavior.

The intent is not to flag everything. The command is tuned toward findings that are likely to be useful and actionable, with an emphasis on higher-confidence results.

How does it fit with other security tools?

This is a Copilot-powered security review experience. It does not replace dedicated security tools such as code scanning, secret scanning, dependency scanning, or manual security review.

Instead, it complements them by moving an additional layer of feedback earlier in the developer workflow: a fast first pass while the developer still has the full context of the change in mind.

For now, try /security-review in Copilot CLI and let us know what kind of security feedback helps you move faster with more confidence.

[moisesz10]

This is a really strong direction for bringing security earlier into the developer workflow. Having security review directly inside the CLI makes a lot of sense, especially for validating AI-generated code before it reaches a pull request.

I like the focus on high-confidence findings instead of overwhelming developers with noise. The categories covered already address many of the most common and impactful security issues developers face day to day.

A few ideas that could make this even more useful in the future:

1 Support for custom organizational or repository-specific security rules
2 Deeper integration with GitHub Advanced Security workflows
3 More detailed remediation guidance with secure code examples
4 Options to export findings into CI/CD pipelines or PR comments
5 Language/framework-specific recommendations to improve accuracy

Overall, this feels like a valuable step toward making secure development more accessible and developer-friendly.

[coadaflorin]

Thanks for the feedback @moisesz10 !
4. Can easily be achieved today by asking the agent to save the detection, and store that as a comment.

I'm curious about:

2 Deeper integration with GitHub Advanced Security workflows

What kind of integration are you thinking of here?