Agentic Autofix de GitHub ya está disponible: de una alerta de seguridad a una corrección revisada

Una alerta de seguridad te indica que hay algo que requiere atención. No necesariamente explica cómo modificar la aplicación sin estropearla. Para quien mantiene una aplicación pequeña y está empezando, esa distancia puede impedir que llegue a plantear una corrección; para un desarrollador, puede convertirse en una cola creciente de avisos conocidos.

GitHub anunció la disponibilidad general de Agentic Autofix para las alertas de análisis de código el 15 de octubre de 2026. Asigna una alerta a Copilot y un agente investiga el código, propone cambios, intenta validarlos y abre una solicitud de cambios en borrador. Lo útil empieza ahí: recibes una reparación propuesta que puedes inspeccionar, en lugar de encontrarte ante un editor vacío. Anuncio de disponibilidad general de GitHub, 15 de octubre de 2026

Esta guía te lleva desde un repositorio apto hasta la primera corrección revisada y después explica cómo tratar alertas relacionadas, analizadores personalizados, costes e intentos fallidos. Nuestra recomendación: considera al agente autor del parche, no responsable de aprobar una publicación. Antes de que el cambio forme parte de tu aplicación, todavía tienes que entenderlo.

El diagrama inicial distingue la reparación propuesta por el agente de la decisión humana de integrar el cambio.

Empieza con una alerta, no con toda la cola

El primer éxito debería ser un cambio que puedas explicar, probar y revisar. Una solicitud de cambios propone combinar cambios con la rama principal de un proyecto; si está en borrador, indica que aún no está lista. CodeQL es el motor de análisis de código de GitHub: genera alertas sobre código potencialmente vulnerable.

Sigue esta secuencia antes de intentar una limpieza de gran alcance:

1. Elige un repositorio que administres. Antes de iniciar una sesión de agente, confirma que cumple los requisitos, que se ha aprobado el acceso y quién es responsable de la facturación.
2. Comprueba primero el análisis de CodeQL. Si el repositorio ya tiene un análisis que funciona, conserva esa configuración y comprueba su ejecución satisfactoria más reciente. Para una instalación nueva, ve a Settings > Advanced Security > Code Security, busca CodeQL analysis, selecciona Set up > Default, revisa la configuración y pulsa Enable CodeQL. Espera a que el análisis termine correctamente. Instrucciones de configuración de GitHub, consultadas el 18 de octubre de 2026
3. Activa Agentic Autofix mediante las políticas aplicables. Un ajuste del repositorio no puede anular una prohibición de la organización o de la empresa.
4. Elige una alerta existente en la rama predeterminada. Abre Security and quality > Code scanning, entra en la alerta y, bajo Assignees, selecciona Assign to Copilot. Procedimiento de alertas de GitHub, consultado el 18 de octubre de 2026
5. Inspecciona la solicitud de cambios en borrador y el registro de la sesión. Lee las diferencias, ejecuta las pruebas pertinentes y vuelve a analizar el código con la configuración que informó del problema.
6. Integra el cambio solo después de la revisión humana y las comprobaciones obligatorias. Después, confirma el estado de la alerta tras analizar la rama predeterminada actualizada.

Para ver la interfaz, consulta la demostración oficial de la interfaz de GitHub en el anuncio de disponibilidad general. Usa esa referencia junto a tu repositorio, en vez de dar por hecho que un diagrama reproduce todas las pantallas actuales.

¿Puede utilizarlo tu repositorio público o privado?

El anuncio de lanzamiento destaca a los clientes empresariales. La documentación de acceso vigente de GitHub abarca más casos: incluye repositorios públicos en GitHub.com y repositorios propiedad de organizaciones con GitHub Code Security o GitHub Advanced Security. No se necesita una licencia de Copilot. Documentación de acceso de GitHub, consultada el 18 de octubre de 2026

El acceso público no significa que las sesiones del agente sean gratuitas. Distingue la aptitud del repositorio de los costes de uso antes de invitar a colaboradores a probar la función.

Habilita el acceso empezando por la política de mayor nivel aplicable

En una organización propiedad de una empresa, primero un propietario de la empresa o un responsable de seguridad debe permitir la función en Policies > Advanced Security > Agentic Autofix. Ese permiso por sí solo no la activa. Después, un propietario de la organización o responsable de seguridad debe habilitarla en Settings > Advanced Security > Global settings; los repositorios aptos heredan la configuración. Los administradores de cada repositorio pueden excluirlo o volver a habilitarlo solo si las políticas de niveles superiores lo permiten. Las organizaciones independientes omiten el paso empresarial; los repositorios públicos personales aptos se configuran directamente desde el repositorio. Quienes usaban la versión preliminar deben habilitarla de nuevo. Procedimiento de políticas de GitHub, consultado el 18 de octubre de 2026

Diagrama de acceso: permiso, activación y elección del repositorio son decisiones distintas. Fuente: documentación de acceso de GitHub, consultada el 18 de octubre de 2026.

Antes de desplegarlo en toda la organización, identifica los repositorios que deben permanecer excluidos y acuerda quién revisará los parches generados. Un piloto razonable reúne a una persona responsable del repositorio y a otra de seguridad. Anota la alerta, el comportamiento esperado, quién revisa y quién controla el presupuesto para evitar que un borrador desatendido se convierta en una responsabilidad ajena y sin explicación.

Comprueba que CodeQL haya analizado realmente el código

La configuración predeterminada requiere GitHub Actions y visibilidad pública o Code Security. Revisa los lenguajes y el conjunto de consultas seleccionados, no solo si el control aparece como activado. Si ya tienes una configuración avanzada que funciona, no cambies sin más: la configuración predeterminada la sustituye, desactiva el flujo existente y bloquea las cargas a través de la API de análisis de CodeQL. Documentación de configuración predeterminada de GitHub, consultada el 18 de octubre de 2026

Antes de seleccionar una alerta, comprueba el resultado del análisis más reciente. Pregúntate si se incluyó el servicio afectado y si su compilación o sus dependencias hicieron fallar el análisis. Que un ajuste figure como activado no demuestra que se hayan analizado correctamente los archivos pertinentes. Resuelve el problema de configuración antes de pedirle a un agente que corrija hallazgos de una línea base poco fiable.

Para el primer intento, elige un problema acotado con un comportamiento esperado claro, como una consulta a la base de datos o una ruta concreta de generación de contenido. No empieces por un rediseño integral de las autorizaciones. Si no hay ninguna alerta pertinente, no introduzcas una vulnerabilidad deliberadamente en un repositorio activo solo para crear una demostración.

¿Qué ocurre desde la asignación hasta la solicitud de cambios en borrador?

GitHub describe un agente que explora los archivos pertinentes, genera una corrección, vuelve a ejecutar CodeQL e itera antes de abrir una solicitud de cambios en borrador. La propuesta incluye un resumen de la reparación y detalles de validación. Ese es el flujo de Agentic Autofix, no una integración automática en la rama predeterminada. Flujo de trabajo de GitHub, 15 de octubre de 2026

Tras asignar la alerta, sigue esta secuencia de revisión:

1. Vuelve a leer el hallazgo original. Identifica la entrada no confiable, la operación sensible y la protección esperada. Anota el identificador de la alerta y la configuración que la detectó.
2. Lee todos los archivos modificados. Busca cambios ajenos a la tarea, controles eliminados, pruebas desactivadas, nuevas dependencias y modificaciones en el comportamiento ante errores.
3. Inspecciona las pruebas de la sesión. Distingue un análisis completado de un comando fallido o de un aviso que diga que no se pudo validar. Puedes solicitar otra iteración desde la sesión o mencionar a Copilot en un comentario de la solicitud. Guía de sesiones de GitHub, consultada el 18 de octubre de 2026
4. Ejecuta las pruebas de la aplicación y el analizador pertinente. Usa los comandos de prueba documentados por el proyecto en un entorno de desarrollo apropiado. Antes de ejecutar código desconocido, inspecciona los scripts de configuración y los cambios en los flujos.
5. Solicita aprobación humana. Mantén bloqueado el borrador si no se han resuelto el comportamiento, la cobertura del análisis o la responsabilidad. Márcalo como listo solo cuando las pruebas se puedan revisar.

Ciclo de revisión: el borrador generado por un agente es un resultado intermedio, no una prueba de que la aplicación sea segura. Fuentes: anuncio y documentación de resolución de alertas de GitHub.

Las solicitudes de cambios de GitHub muestran las diferencias en Files changed y los resultados automatizados en Checks. Consulta ambos: un resumen en verde no explica si un control de permisos modificado sigue aplicando las reglas de tu aplicación. Conceptos de solicitudes de cambios de GitHub, consultados el 18 de octubre de 2026

Flujo 1: corrige una consulta pequeña a la base de datos sin cambiar su significado

Imagina un servicio ficticio de Python que busca un artículo del inventario por su etiqueta. La implementación actual inserta la etiqueta proporcionada en SQL mediante interpolación de cadenas y una alerta de análisis de código señala la construcción de esa consulta. Una corrección útil separa la instrucción SQL del valor, en vez de intentar eliminar caracteres de puntuación uno por uno.

Una implementación ilustrativa más segura con la interfaz sqlite3 de Python sería:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

El marcador enlaza el valor por separado del texto SQL, de acuerdo con las instrucciones oficiales de Python sobre cómo enlazar valores con parámetros, consultadas el 18 de octubre de 2026. Es un patrón de corrección ficticio, no un resultado de Agentic Autofix ni una prueba realizada. La consulta, el esquema y las reglas de autorización exactas de un servicio real requieren su propia revisión.

Para este ejemplo, pide pruebas que cubran una etiqueta normal, otra con apóstrofo, como Maker's Kit, y un artículo inexistente. Comprueba que la función conserve el comportamiento esperado de devolver una fila o None. Después prueba las reglas de acceso existentes del endpoint que la invoca: usar una consulta parametrizada no determina quién puede leer el inventario.

Un comentario de revisión útil sería: «Mantén intacto el comportamiento de la búsqueda, enlaza la etiqueta como dato y añade pruebas de regresión para apóstrofos y artículos inexistentes». Describe el contrato en lugar de limitarse a decirle al agente que haga desaparecer el aviso. Vuelve a analizar el parche real antes de aceptarlo.

Flujo 2: agrupa alertas relacionadas, no avisos arbitrarios

Supón que un servicio web ficticio tiene tres alertas asociadas al mismo helper que genera las respuestas. Revísalas juntas para decidir si conviene una única corrección compartida. GitHub permite seleccionar hasta 25 alertas pendientes desde la lista o una campaña de seguridad; una asignación inicia una sesión y crea una solicitud de cambios. Instrucciones de asignación masiva de GitHub, consultadas el 18 de octubre de 2026

El límite es un máximo permitido, no el tamaño de lote recomendado. Puede ser más fácil revisar tres hallazgos relacionados con una persona responsable que veinte hallazgos distintos sobre autenticación, manejo de archivos y acceso a bases de datos. Antes de asignarlos, enumera cada endpoint afectado y el comportamiento habitual que debe conservarse.

En este flujo ilustrativo, revisa el helper compartido y prueba a cada consumidor. Si la propuesta modifica el escape de la salida, comprueba los contextos de salida previstos en vez de aprobarla porque un ejemplo ahora se ve bien. Divide el trabajo si distintos hallazgos requieren revisores o calendarios de publicación diferentes. No permitas que una alerta sin resolver oculte qué correcciones sí tienen pruebas.

Flujo 3: un analizador personalizado necesita su propia confirmación

Agentic Autofix solo cubre alertas pendientes de la rama predeterminada. Las alertas que aparecen únicamente en una solicitud de cambios u otra rama quedan fuera de ese flujo de asignación. Si una solicitud nueva introduce un hallazgo, corrígelo allí en vez de integrar código vulnerable solo para poder asignarlo. Alcance declarado por GitHub, 15 de octubre de 2026

Hay otro límite: GitHub indica que la validación del agente no puede confirmar correcciones de consultas personalizadas de CodeQL, el conjunto security-extended de CodeQL ni alertas de análisis de código de terceros. La validación integrada vuelve a ejecutar el conjunto de consultas de análisis de código, con carácter no garantizado. Límites de validación de GitHub, consultados el 18 de octubre de 2026

Imagina una organización ficticia con una consulta personalizada que aplica una regla interna de tratamiento de datos. Aunque el agente proponga un parche verosímil, el revisor debe ejecutar ese análisis personalizado e inspeccionar el resultado. Anota la versión de la consulta, la configuración, la revisión analizada y el resultado. Que se ejecute correctamente el conjunto predeterminado no sustituye la consulta que informó del problema.

Mantén activado el analizador más estricto. Reducir la cobertura para obtener un estado en verde cambia la medición, no la seguridad de la aplicación. Si no puedes reproducir el análisis requerido, deja la propuesta pendiente de validación e indica quién puede ejecutarlo.

No tener licencia de Copilot no significa que no haya factura

Agentic Autofix consume créditos de IA de Code Security y minutos de GitHub Actions. La documentación de facturación de GitHub dice explícitamente que los créditos de IA se consumen incluso en repositorios públicos que no necesitan licencias para colaboradores activos. Si la cuenta facturada tiene una asignación aplicable, primero se usan los créditos de IA incluidos; el consumo adicional se factura por uso. Las cuentas sin créditos incluidos pagan por uso desde el principio. Facturación de créditos de IA de GitHub, consultada el 18 de octubre de 2026

Para repositorios de una organización, los cargos corresponden a la organización o a la cuenta empresarial que paga. Antes de habilitarlo ampliamente, revisa la asignación de esa cuenta y el presupuesto de créditos de IA de Code Security. El anuncio también exige configurar un método de facturación de Copilot; eso no significa que cada usuario necesite una licencia de Copilot. Requisitos de facturación del lanzamiento de GitHub, 15 de octubre de 2026

En un piloto, registra el consumo por sesión y de Actions, el tiempo de revisión y si se aceptó el parche. No prometas un precio fijo por alerta corregida: un lote, una iteración o una propuesta fallida también deben entrar en la revisión de costes. Compara el coste de las correcciones aceptadas con el flujo actual, en lugar de contar las solicitudes generadas como correcciones terminadas.

El Copilot Autofix clásico es distinto: ofrece un cambio sugerido de un solo paso, no el flujo de investigación y borrador del agente, y sus sugerencias no consumen créditos de IA. Cuando está disponible, sigue siendo una opción si Agentic Autofix no está habilitado. Comparación de GitHub, consultada el 18 de octubre de 2026

Antes de integrar, responde estas siete preguntas

Nuestra lista de revisión busca conservar el comportamiento y eliminar la debilidad detectada:

• Causa raíz: ¿El parche corrige la operación insegura o simplemente oculta el aviso?
• Alcance: ¿Están justificados los cambios de refactorización ajenos a la tarea, las nuevas dependencias y las modificaciones de configuración?
• Comportamiento: ¿Siguen comportándose correctamente las entradas válidas e inválidas, los errores y los permisos?
• Pruebas: ¿Hay una prueba de regresión que detectaría el problema original?
• Análisis: ¿El analizador que informó del problema examinó la revisión propuesta con la configuración requerida?
• Aprobación: ¿Una persona responsable ha revisado las diferencias y las notas pendientes del agente?
• Después de integrar: ¿El análisis de la rama predeterminada confirmó el estado esperado de la alerta sin generar nuevos hallazgos?

Considera «no se pudo validar» trabajo pendiente, no una aprobación. GitHub indica que el agente puede informar en su solicitud de que no pudo validar o de que sospecha que la alerta es un falso positivo. Ninguna de esas afirmaciones sustituye la evaluación de quien mantiene el proyecto. Comportamiento de mejor esfuerzo de GitHub, consultado el 18 de octubre de 2026

¿Qué ocurre si no aparece el botón o el resultado es incorrecto?

¿Por qué veo una alerta, pero no puedo asignarla? Comprueba que pertenezca a la cola de la rama predeterminada, que el repositorio cumpla los requisitos, que la función esté habilitada y que tengas los permisos necesarios. Para asignarla necesitas acceso de escritura. Si un ajuste está bloqueado, pregunta al administrador correspondiente en vez de activar y desactivar repetidamente el control del repositorio. Requisitos de asignación de GitHub, consultados el 18 de octubre de 2026

¿Un análisis limpio demuestra que la aplicación es segura? No. Responde a las preguntas incluidas en ese análisis y configuración. Las reglas de negocio, la autorización, el comportamiento en ejecución y los hallazgos que no se admiten aún requieren pruebas y revisión adecuadas.

¿Debería volver a intentarlo muchas veces si una sesión falla? Primero inspecciona el registro y las diferencias propuestas. Determina si falta configurar el análisis, ejecutar las pruebas o proporcionar contexto del proyecto, o si el problema está en la propia propuesta. Aporta una corrección precisa o resuelve el problema de configuración antes de otro intento; repetir asignaciones sin información nueva no es una estrategia de corrección.

¿Puedo aceptar una alerta que parece un falso positivo? Investiga el hallazgo por separado y deja constancia del razonamiento. No confundas descartar una alerta con corregir código vulnerable ni dejes que la confianza del agente decida una excepción de riesgo.

En resumen: una corrección propuesta es el comienzo de la revisión

Agentic Autofix adelanta trabajo útil: recibes en conjunto la investigación, un parche candidato y la validación disponible. La ventaja práctica es reducir la distancia entre detectar una vulnerabilidad y poder revisar una reparación concreta. Empieza con un caso acotado, conserva tus analizadores y basa la aceptación en las pruebas, no en quién escribió el cambio.

Fuentes

Fuentes primarias consultadas el 18 de octubre de 2026.

Los enlaces de esta guía llevan al anuncio de disponibilidad general del 15 de octubre, las políticas de acceso actuales, los conceptos y límites de Autofix, los procedimientos para resolver alertas, la configuración de CodeQL y la documentación de facturación. La documentación es una instantánea fechada de acceso, no una garantía sobre la configuración de cada cuenta. Los tres flujos son ilustrativos, no resultados de pruebas prácticas.

Un lugar para tus notas de revisión: conserva juntos los enlaces de origen, las referencias a las alertas, los resultados de las pruebas y las decisiones en Telli.sh. Te ayuda a organizar tus notas; no analiza repositorios ni aprueba correcciones. Crea una cuenta de Telli.sh.