Nota: La corrección automática de GitHub para code scanning está en versión beta. La funcionalidad y la documentación están sujetas a cambios. Durante esta fase, la función está restringida a las alertas de JavaScript, TypeScript y Python, así como las alertas de Java identificadas por CodeQL. Si tiene una cuenta de empresa y usa GitHub Advanced Security, la empresa tiene acceso a la versión beta.
Sobre la autocorrección para CodeQL code scanning
La autocorrección de Code scanning es una expansión con tecnología de GitHub Copilot de code scanning que proporciona a los usuarios recomendaciones dirigidas para ayudarles a corregir las alertas de code scanning en las solicitudes de incorporación de cambios para que puedan evitar nuevas vulnerabilidades de seguridad. Los modelos de lenguaje grandes (LLM) generan automáticamente las posibles correcciones mediante datos del código base, la solicitud de incorporación de cambios y del análisis de CodeQL.
Nota: Aunque la autocorrección de code scanning tiene tecnología de GitHub Copilot, la empresa no necesita una suscripción a GitHub Copilot para usar la autocorrección. Siempre que la empresa tenga GitHub Advanced Security, tendrá acceso a la autocorrección.
La autocorrección de Code scanning genera posibles correcciones que son relevantes para el código fuente existente y traduce la descripción y ubicación de una alerta en los cambios de código que pueden corregirla. La autocorrección usa las API internas de GitHub Copilot y las instancias privadas de modelos de lenguaje grande de OpenAI, como GPT-4, que tienen suficientes funcionalidades generativas para generar correcciones sugeridas en el código y texto explicativo para esas correcciones.
En el panel de información general de seguridad de una organización, puede ver el número total de sugerencias de autocorrección generadas en solicitudes de incorporación de cambios abiertas y cerradas en la organización durante un período de tiempo determinado. Para más información, consulta "Visualización de información de seguridad" en la documentación de GitHub Enterprise Cloud.
Experiencia del desarrollador
Los usuarios de GitHub Advanced Security ya pueden ver las alertas de seguridad detectadas por code scanning con CodeQL para analizar sus solicitudes de incorporación de cambios. Sin embargo, los desarrolladores suelen tener poco entrenamiento en la seguridad del código, por lo que la corrección de estas alertas requiere un esfuerzo considerable. Primero deben leer y comprender la ubicación y la descripción de la alerta y luego usar esa comprensión para editar el código fuente y así corregir la vulnerabilidad.
La autocorrección de Code scanning reduce la barrera de entrada a los desarrolladores a partir de la combinación de información sobre procedimientos recomendados con detalles del código base y la alerta para sugerir una posible corrección al desarrollador. En lugar de empezar con una búsqueda de información sobre la vulnerabilidad, el desarrollador comienza con una sugerencia de código que muestra una posible solución para el código base. El desarrollador evalúa la posible corrección para determinar si es la mejor solución para el código base y para asegurarse de que mantiene el comportamiento previsto.
Después de confirmar una corrección sugerida o modificada, el desarrollador siempre debe comprobar que las pruebas de integración continua (CI) del código base se siguen aprobando y que la alerta se muestra como resuelta antes de combinar su solicitud de incorporación de cambios.
Idiomas compatibles
La autocorrección Code scanning admite la generación de correcciones para un subconjunto de consultas incluidas en el conjunto de consultas predeterminado para JavaScript, TypeScript, Python, Java y C#. Para más información sobre la configuración predeterminada, consulte "Conjuntos de consultas codeQL".
Proceso de generación de autocorrección
Cuando la autocorrección está habilitada para un repositorio, las alertas de code scanning identificadas en una solicitud de incorporación de cambios por consultas de CodeQL admitidas envían la entrada al LLM. Si el LLM puede generar una posible corrección, esta se muestra en la solicitud de incorporación de cambios como comentario de sugerencia.
GitHub envía al LLM una variedad de datos de la solicitud de incorporación de cambios y del análisis de CodeQL.
- Datos de alerta de CodeQL en formato SARIF. Para más información, consulta "Soporte de SARIF para escaneo de código".
- Código de la versión actual de la rama de solicitud de incorporación de cambios.
- Fragmentos cortos de código alrededor de cada ubicación de origen, ubicación del receptor y cualquier ubicación a la que se haga referencia en el mensaje de alerta o que esté incluida en la ruta de acceso del flujo.
- Primero 10 líneas (aproximadamente) de cada archivo implicado en cualquiera de esas ubicaciones.
- Texto de ayuda de la consulta de CodeQL que identificó el problema. Para obtener ejemplos, consulta "Ayuda de la consulta de CodeQL".
Las sugerencias de autocorrección se generan y almacenan dentro del back-end de code scanning. Se muestran como comentarios de sugerencias en la solicitud de incorporación de cambios. No se necesita ninguna interacción del usuario más allá de habilitar code scanning en el código base y crear la solicitud de incorporación de cambios.
El proceso de generación de correcciones no recopila ni utiliza ningún dato de cliente más allá del ámbito descrito anteriormente. Por lo tanto, el uso de esta función se rige por los términos y condiciones existentes asociados a los datos GitHub Advanced Security. Además, los datos administrados por la autocorrección code scanningno se emplean estrictamente para fines de entrenamiento de LLM. Para obtener más información sobre los términos y condiciones de GitHub Advanced Security, diríjase a "Términos de GitHub para productos y funciones adicionales en la documentación Gratis, Pro y Equipo.
Calidad de sugerencias de detección automática
GitHub usa una herramienta de ejecución de pruebas automatizada para supervisar continuamente la calidad de las sugerencias de autocorrección. Esto nos permite comprender cómo se desarrollan las sugerencias de autocorrección generadas por el cambio de LLM a medida que se desarrolla el modelo.
La herramienta de ejecución de pruebas incluye más de 1870 alertas de un conjunto diverso de repositorios públicos en los que el código resaltado tiene cobertura de pruebas. Las sugerencias de autocorrección para estas alertas se prueban para comprobar su calidad, es decir, qué tanto tendría que editarlas un desarrollador antes de confirmarlas en el código base. Para muchas de las alertas de prueba, las autocorrecciones generadas por el LLM podrían confirmarse tal cual para corregir la alerta sin dejar de aprobar todas las pruebas de CI existentes.
Además, el sistema se somete a pruebas de esfuerzo para comprobar posibles daños (a menudo denominados formación de equipos rojos). Además, un sistema de filtrado en el LLM ayuda a evitar que se muestren sugerencias potencialmente perjudiciales a los usuarios.
Cómo prueba GitHub sugerencias de autocorrección
Probamos la eficacia de las sugerencias de autocorrección con la combinación de todos los cambios sugeridos, sin editar, antes de ejecutar code scanning y las pruebas unitarias del repositorio en el código resultante.
- ¿Se corrigió la alerta de code scanning mediante la sugerencia?
- ¿Se ha introducido alguna nueva alerta de code scanning?
- ¿La corrección introdujo errores de sintaxis que pueda detectas code scanning?
- ¿Ha cambiado la corrección la salida de cualquiera de las pruebas del repositorio?
Además, detectamos muchas de las sugerencias correctas y comprobamos que corrigen la alerta sin introducir nuevos problemas. Cuando se produjo un error en una o varias de estas comprobaciones, nuestra evaluación de prioridades manual mostró que, en muchos casos, la corrección propuesta era casi correcta, pero necesitaba modificaciones menores que un usuario podría identificar y hacer manualmente.
Eficacia en otros proyectos
El conjunto de pruebas contiene una amplia gama de distintos tipos de proyectos y alertas. Se predice que las autocorrecciones para otros proyectos que usan lenguajes admitidos por autocorrección deben seguir un patrón similar.
- Es probable que la autocorrección agregue una sugerencia de código a la mayoría de alertas.
- Cuando los desarrolladores evalúen las sugerencias de autocorrección, esperamos que la mayoría de las correcciones se puedan confirmar sin editar o con actualizaciones secundarias para reflejar el contexto más amplio del código.
- Un pequeño porcentaje de correcciones sugeridas reflejará un malentendido significativo del código base o la vulnerabilidad.
Sin embargo, cada proyecto y código base es único, por lo que es posible que los desarrolladores necesiten editar un porcentaje mayor de correcciones sugeridas antes de confirmarlas. La autocorrección ofrece información valiosa para ayudarte a resolver las alertas de code scanning, pero en última instancia sigue siendo tu responsabilidad evaluar el cambio propuesto y garantizar la seguridad y la precisión del código.
Nota: La generación de correcciones para los idiomas admitidos está sujeta a la capacidad operativa de LLM. Además, cada corrección sugerida se prueba antes de agregarla a una solicitud de incorporación de cambios. Si no hay ninguna sugerencia disponible o si la corrección sugerida produce un error en las pruebas internas, no se muestra ninguna sugerencia de autocorrección.
Limitaciones de las sugerencias de autocorrección
Al revisar una sugerencia de autocorrección, siempre debes tener en cuenta sus limitaciones y editar los cambios según sea necesario antes de aceptarlos. También debes considerar la posibilidad de actualizar las pruebas de CI y la administración de dependencias de un repositorio antes de habilitar la autocorrección para code scanning. Para obtener más información, consulta "Mitigación de las limitaciones de las sugerencias de autofijo".
Limitaciones de las sugerencias de autocorrección de código
- Lenguajes de programación: se admite un subconjunto de lenguajes de programación. Se agregará compatibilidad con idiomas adicionales, pero no hay intención de proporcionarla con todos los idiomas de CodeQL.
- Idiomas humanos: el sistema usa principalmente datos en inglés, incluidos las solicitudes envíadas al sistema, el código visto por los LLM en sus conjuntos de datos y los casos de prueba usados para la evaluación interna. Las sugerencias generadas por el LLM pueden tener una tasa de éxito menor para el código fuente y los comentarios escritos en otros lenguajes y usando otros juegos de caracteres.
- Errores de sintaxis: el sistema puede sugerir correcciones que no sean cambios de código sintácticamente correctos, por lo que es importante ejecutar comprobaciones de sintaxis en las solicitudes de incorporación de cambios.
- Errores de ubicación: el sistema puede sugerir correcciones que sean código sintácticamente correcto, pero se sugieran en la ubicación incorrecta, lo que significa que si un usuario acepta una corrección sin editar la ubicación, introducirá un error de sintaxis.
- Errores semánticos: el sistema puede sugerir correcciones que sean válidas sintácticamente, pero que cambien la semántica del programa. El sistema no entiende la intención del programador o del código base sobre cómo debe comportarse el código. Tener una buena cobertura de pruebas ayuda a los desarrolladores a comprobar que una corrección no cambia el comportamiento del código base.
- Vulnerabilidades de seguridad y correcciones engañosas: el sistema puede sugerir correcciones que no solucionen la vulnerabilidad de seguridad subyacente o introduzcan nuevas vulnerabilidades de seguridad.
- Correcciones parciales: el sistema puede sugerir correcciones que solo aborden parcialmente la vulnerabilidad de seguridad o que solo conserven parcialmente la funcionalidad de código prevista. El sistema solo ve un pequeño subconjunto del código en el código base y no siempre produce soluciones óptimas o correctas globalmente.
Limitaciones de las sugerencias de dependencia de autocorrección
A veces, una corrección sugerida incluye un cambio en las dependencias del código base. Si usas un sistema de administración de dependencias, los cambios se resaltarán automáticamente para que el desarrollador los revise. Antes de combinar una solicitud de incorporación de cambios, comprueba siempre que los cambios de dependencia sean seguros y mantengan el comportamiento previsto del código base.
- Dependencias nuevas o actualizadas: el sistema puede sugerir agregar o actualizar dependencias de software como parte de una corrección sugerida. Por ejemplo, si se sugiere cambiar el archivo
package.jsonde los proyectos de JavaScript para agregar dependencias desde npm. - Dependencias no admitidas o no seguras: el sistema no sabe qué versiones de una dependencia existente son compatibles o seguras.
- Dependencias fabricadas: el sistema tiene conocimientos incompletos de las dependencias publicadas en el ecosistema más amplio. Esto puede provocar sugerencias que agreguen una nueva dependencia de software malintencionado que los atacantes han publicado con un nombre de dependencia estadísticamente probable.
Mitigación de las limitaciones de las sugerencias de autocorrección
La mejor manera de mitigar las limitaciones de las sugerencias de autocorrección es seguir los procedimientos recomendados. Por ejemplo, el uso de pruebas de CI de solicitudes de incorporación de cambios para comprobar que los requisitos funcionales no se ven afectados y usan soluciones de administración de dependencias, como la API y la acción de revisión de dependencias. Para más información, consulta "Acerca de la revisión de dependencias".
Es importante recordar que el autor de una solicitud de incorporación de cambios conserva la responsabilidad sobre cómo responden a los comentarios y a los cambios de código sugeridos, ya sean propuestos por compañeros o herramientas automatizadas. Los desarrolladores siempre deben examinar de forma crítica las sugerencias de los cambios de código. Si es necesario, deben editar los cambios sugeridos para asegurarse de que el código y la aplicación resultantes sean correctos, seguros, cumplan los criterios de rendimiento y con todos los demás requisitos funcionales y no funcionales de la aplicación.