GitHub agregó el 10 de junio de 2026 un comando pequeño, pero muy alineado con el uso real de agentes de coding: /security-review en Copilot CLI. Sale como función experimental en public preview y analiza cambios locales para señalar hallazgos de seguridad con severidad, confianza y sugerencias accionables.

La lectura útil para builders no es “Copilot ahora hace seguridad”. La lectura útil es que la seguridad empieza a entrar en el mismo lugar donde ya ocurre buena parte del trabajo agentic: la terminal, antes del commit y antes de abrir un pull request.

Flujo editorial con cambios locales, una revisión de seguridad en terminal y una compuerta antes del commit

Qué cambia en el flujo diario

Hasta ahora, muchas revisiones de seguridad llegaban tarde: en el PR, en el escaneo de la rama o después de que el agente ya produjo una solución completa. El nuevo comando mueve una parte de esa revisión al momento en que el builder todavía puede corregir rápido.

Según el changelog, /security-review busca clases de vulnerabilidad comunes y de alto impacto: inyección, XSS, manejo inseguro de datos, path traversal y criptografía débil. Ese alcance importa porque no intenta revisar arquitectura completa ni cumplimiento. Intenta detectar errores de seguridad probables en el diff que ya tienes frente a ti.

La intención de búsqueda es bastante clara:

Copilot CLI security-review;
GitHub Copilot CLI security review;
security review before commit AI;
Copilot CLI vulnerability scan.

No hay tooling SEO conectado en esta corrida, así que la demanda se infiere por el changelog oficial, la documentación de Copilot CLI y la presión práctica de equipos que ya dejan a agentes tocar código con permisos reales.

No reemplaza CodeQL ni secret scanning

GitHub es explícito en el matiz: este comando no depende de code scanning, Dependabot ni secret scanning. Eso lo vuelve útil, pero también marca su límite. Un resultado limpio de /security-review no significa que el repo esté seguro.

Yo lo pondría como una capa de fricción temprana:

el agente escribe o modifica código;
el builder corre tests y revisa el diff;
Copilot CLI ejecuta /security-review;
si aparecen hallazgos, se corrigen antes del commit;
el PR todavía pasa por CodeQL, secret scanning, Dependabot y revisión humana.

Mapa editorial con Copilot CLI, CodeQL, secret scanning y revisión humana como capas distintas de seguridad

La trampa sería vender esto como “seguridad automática”. En flujos con agentes, lo correcto es tratarlo como lint de seguridad asistido por IA, no como auditoría final.

Cómo probarlo sin generar ruido

La forma sana de probarlo no es correrlo sobre una rama gigante. Empieza con cambios pequeños donde el riesgo sea visible: validación de inputs, endpoints nuevos, manejo de archivos, permisos, tokens o lógica de autorización.

Un buen piloto tendría tres criterios:

medir cuántos hallazgos fueron verdaderamente útiles;
registrar falsos positivos que distraen;
comparar si el comando atrapa algo antes de que CodeQL o revisión humana lo encuentren.

Si usas agentes como Codex, Claude Code o Copilot CLI, el punto no es agregar otro ritual. Es cerrar el loop entre generación y revisión en la misma sesión. Ahí encaja bien con el curso gratis, porque la base no es “confiar más en el agente”, sino diseñar mejores compuertas.

Decisión práctica

Yo activaría /security-review en flujos de trabajo donde:

los agentes cambian código de backend, auth, pagos, archivos o datos personales;
el equipo ya trabaja desde terminal;
el PR suele llegar tarde para corregir vulnerabilidades simples;
hay repos pequeños sin un equipo de AppSec dedicado.

No lo usaría como gate único para merges ni como excusa para relajar pruebas. La lectura final es sobria: Copilot CLI está convirtiéndose en una estación de revisión antes del commit, y eso vale más cuando el código viene de un agente que puede producir cambios rápido, pero no siempre entiende el riesgo completo.