La IA de GitHub ya encuentra, corrige y vuelve a probar vulnerabilidades. Aún no bloquea un merge ni aprobarlo
AI Scan y Agentic Autofix llegaron a disponibilidad general el 15 de octubre. Uno asesora, el otro abre pull requests en borrador. Lea los límites como diseño: el pull request marca el límite.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
El 15 de octubre GitHub llevó dos funciones de seguridad con IA a disponibilidad general (GA) el mismo día, y ambas llegan con un límite deliberado. AI Scan encuentra vulnerabilidades en los pull requests, y sus hallazgos no pueden bloquear un merge. Agentic Autofix investiga y corrige alertas, y solo puede abrir un pull request en borrador. Los límites son la parte más útil del lanzamiento, porque muestran dónde cree GitHub que termina el criterio de la IA y dónde empieza el control efectivo.
Dos funciones, dos tareas
AI Scan usa un modelo para buscar vulnerabilidades en los cambios de un pull request, dirigido al código que CodeQL no cubre hoy: PHP, Shell y Bash, Terraform HCL, Dockerfiles, JSP y Blazor, entre otros. Los hallazgos aparecen junto a los resultados de CodeQL, marcados con un indicador “AI”, y pueden incluir una explicación y una corrección sugerida. Se ejecuta automáticamente cuando el code scanning y la configuración de AI Scan del repositorio están habilitados. Los repositorios públicos lo obtienen; los repositorios privados e internos necesitan GitHub Code Security o Advanced Security. No se requiere una licencia de Copilot. No se ejecuta en pull requests de forks ni de Dependabot.
Agentic Autofix trabaja sobre alertas que ya existen. Asigne una alerta de code scanning en la rama por defecto a Copilot, o seleccione hasta 25 alertas para corregir en un solo pull request, o establezca la persona asignada a través de la API REST. Copilot explora los archivos relevantes, propone una corrección, vuelve a ejecutar CodeQL para confirmar que la alerta se cierra, itera si es necesario y abre un pull request en borrador con un resumen y los pasos de validación que siguió. Está disponible para clientes de Code Security y Advanced Security en GitHub Enterprise Cloud, incluida la residencia de datos, una vez que un administrador de la empresa habilita la política y existe un método de facturación de Copilot. Las alertas que solo se encuentran en otras ramas o en pull requests no se pueden asignar.
| ¿Cambia el código? | ¿Puede bloquear un merge? | Verificado por | |
|---|---|---|---|
| CodeQL | No | Sí, a través de rulesets | Reglas deterministas |
| AI Scan | Sugiere una corrección | No, solo orientativo | Una persona leyendo el hallazgo |
| Agentic Autofix | Sí, en un pull request en borrador | No, es el autor | Nueva ejecución de CodeQL y después revisión humana |
Por qué un hallazgo de la IA no debería bloquear un merge
Una barrera de merge tiene que ser predecible. Los desarrolladores necesitan saber por qué falló una verificación, reproducirlo y corregirlo; los equipos de seguridad necesitan saber que la barrera se comportará igual mañana. Los hallazgos de un modelo son probabilísticos y cambian con el modelo. Dejar que bloqueen merges haría que la entrega dependiera de una varianza que nadie puede auditar. La decisión de GitHub de mantener AI Scan como orientativo es la correcta, y los equipos deberían resistir la tentación de reconstruir sobre él una barrera que bloquee con automatización propia.
Eso convierte a AI Scan en un insumo de triaje. Su valor se mide por si los desarrolladores actúan sobre sus hallazgos, y por eso las métricas de AI Scan de GitHub, anunciadas dos días antes, importan más ahora que la función es GA: la tasa de remediación y la aceptación de autofix por repositorio, desglosadas por severidad, son la forma de decidir dónde merece atención.
Por qué una nueva ejecución que pasa no es una aprobación
El paso de validación de Autofix es un avance real: el agente comprueba su propia corrección contra la misma consulta de CodeQL que generó la alerta. Pero demuestra una sola cosa: que esta alerta ya no se dispara. No demuestra que el cambio preserve el comportamiento, que no introduzca otra debilidad distinta, ni que coincida con cómo lo habría corregido el equipo propietario. Un lote de 25 alertas en un solo pull request hace esa revisión más difícil, no más fácil.
Así que el pull request en borrador es el límite de control, y quien revisa está haciendo una revisión de código de un cambio escrito por un agente. Trátelo como cualquier cambio de un colaborador nuevo: las pruebas deben pasar, una persona propietaria que conoce el código lo aprueba, y el autor y quien aprueba son identidades distintas. Ese es el marco de gestión del cambio que aplicamos a los agentes que escriben cambios, y aquí viene ya integrado.
Presupueste el trabajo en ambos lados
Ambas funciones consumen Code Security AI Credits, y Autofix además consume minutos de GitHub Actions. GitHub permite a las empresas establecer presupuestos por SKU para esos créditos; establézcalos antes de habilitar la política, no después de la primera factura.
El costo menos visible es el tiempo de revisión. Si Autofix convierte un backlog de 2,000 alertas en 80 pull requests, alguien tiene que revisar 80 pull requests. Un despliegue gradual sensato empieza por una clase de alerta con un patrón de corrección bien conocido, mide con qué frecuencia los borradores se fusionan sin retrabajo y se amplía por clase a partir de ahí. La experiencia de Google con agentes de seguridad en la revisión de código apunta en la misma dirección: estas herramientas se ganan su lugar dentro del flujo de trabajo donde las personas ya deciden, y ese lugar sigue siendo el pull request.