Skip to main content

Ответственное использование Автофикса Copilot для сканирования кода

Узнайте, как GitHub использовать ИИ для предложения возможных исправлений code scanning оповещений и как лучше всего смягчить ограничения в предложениях ИИ.

Кто может использовать эту функцию?

GitHub Copilot Автофикс для code scanning доступен для следующих типов репозитория:

  • Общедоступные репозитории для GitHub.com
  • Репозитории, принадлежащие организации для GitHub Team с GitHub Code Security включено

О Автофикс второго пилотаcode scanning

          GitHub Copilot Автофикс — это расширение code scanning , которое предоставляет пользователям целенаправленные рекомендации для устранения code scanning оповещений и предотвращения новых уязвимостей безопасности. Потенциальные исправления генерируются автоматически крупными языковыми моделями (LLM) с использованием данных из кодовой базы и анализа code scanning . 
          GitHub Copilot Автофикс доступна для CodeQL анализа.

Примечание.

Подписка на GitHub Copilot не требуется для использования GitHub Copilot Автофикс. Автофикс второго пилота доступен для всех общедоступных репозиториев на GitHub.com, а также внутренние или частные репозитории, принадлежащие организациям и предприятиям, имеющим лицензию на GitHub Code Security.

          Автофикс второго пилота генерирует потенциальные исправления, релевантные существующему исходному коду, и переводит описание и местоположение оповещения в изменения кода, которые могут исправить оповещение. 
          Автофикс второго пилота использует внутренние GitHub Copilot API, взаимодействующие с большой языковой моделью ГПТ-5.1 OpenAI, которая обладает достаточными генеративными возможностями для создания как предлагаемых исправлений в коде, так и объяснительного текста для этих исправлений.

          Автофикс второго пилота разрешено по умолчанию и включено для каждого репозитория, использующего CodeQL, но вы можете выбрать отключение и отключение Автофикс второго пилота. Чтобы узнать, как отключить Автофикс второго пилота на корпоративном, организационном и репозиториевом уровнях, см. [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/disabling-autofix-for-code-scanning).

На панели мониторинга обзора безопасности организации можно просмотреть общее количество предложений кода, созданных при открытых и закрытых запросах на вытягивание в организации в течение заданного периода времени. Дополнительные сведения см. в разделе Просмотр аналитических сведений о безопасности.

Опыт разработчика

          Code scanning Пользователи уже могут видеть оповещения безопасности для анализа своих pull request. Однако разработчики часто имеют мало обучения в безопасном коде, поэтому исправление этих оповещений требует значительных усилий. Сначала они должны прочитать и понять расположение и описание оповещений, а затем использовать это понимание для изменения исходного кода для устранения уязвимости.

          Автофикс второго пилота снижает барьер доступа для разработчиков, объединяя информацию о лучших практиках с деталями кодовой базы и предупреждениями, чтобы предложить разработчику возможное исправление. Вместо того чтобы начать поиск информации об уязвимости, разработчик начинается с предложения кода, демонстрирующего потенциальное решение для базы кода. Разработчик оценивает потенциальное исправление, чтобы определить, является ли оно лучшим решением для базы кода и обеспечить поддержание предполагаемого поведения.

После фиксации предлагаемого исправления или изменения разработчик всегда должен убедиться, что непрерывное тестирование интеграции (CI) для базы кода продолжает передаваться и что оповещение отображается как разрешенное перед слиянием запроса на вытягивание.

Поддерживаемые языки для CodeQLcode scanning

          Автофикс второго пилота Поддерживает генерацию исправлений для подмножества запросов, включённых в стандартные и расширенные CodeQL наборы запросов для C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python, Ruby, и Rust. Дополнительные сведения об этих наборах запросов см. в разделе [AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/codeql-query-suites#built-in-codeql-query-suites).

Процесс создания предложений

При Автофикс второго пилота включении репозитория идентифицированные code scanning оповещения отправляют входные данные в LLM. Если LLM может создать потенциальное исправление, исправление отображается как предложение.

          GitHub отправляет LLM различные данные из анализа code scanning . Рассмотрим пример.

* CodeQL данные оповещений в формате SARIF. Дополнительные сведения см. в разделе Поддержка SARIF для проверки кода.

  • Код из текущей версии ветви.
    • Короткие фрагменты кода вокруг каждого исходного расположения, расположения приемника и любого расположения, на которое ссылается оповещение или включены в путь потока.
    • Первые 10 строк из каждого файла, участвующих в любом из этих расположений.
  • Текст помощи для CodeQL запроса, который выявил проблему. Например, см. CodeQL помощь с запросами.

Любые Автофикс второго пилота предложения генерируются и хранятся внутри code scanning бэкенда. Они отображаются в виде предложений. Взаимодействие пользователя не требуется, кроме включения code scanning в кодовой базе и создания pull-запроса.

Процесс создания исправлений не собирает или не использует данные клиента за пределами указанной выше области. Таким образом, использование этой функции регулируется существующими условиями, связанными с Advanced Security. Кроме того, обработка Автофикс второго пилота данных строго не используется для целей обучения LLM. Для получения дополнительной информации об Advanced Security условиях см. Условия #REF! для дополнительных продуктов и функций.

Ограничения и недетерминированность Автофикс второго пилота

          Автофикс второго пилота Потому code scanning что оповещения не смогут создать исправление для каждого оповещения в каждой ситуации. Функция работает на основе наилучших усилий и не гарантируется успешной 100% времени.

Когда Автофикс второго пилота предложение не может быть сгенерировано

Несколько факторов могут помешать Автофикс второго пилота успешному получению предполагаемого решения.

  •         _Недетерминированность:_ базовая большая языковая модель является генерирующей моделью и поэтому недетерминирована. Это означает, что даже с тем же оповещением и кодом, он может не создавать жизнеспособные предложения, или предложение может отличаться между попытками.
    
  •         _Сложность проблемы и контекст:_ некоторые оповещения системы безопасности, такие как те, которые требуют трассировки потока данных в сложной многофайловой базе кода или те, которые представляют тонкие недостатки логики, могут быть трудными для решения модели.
    
  •         _Размер файла:_ если затронутый код находится в очень большом файле или репозитории, контекст, предоставленный LLM, может быть усечен. Модель нуждается в достаточном контексте, чтобы понять окружающую логику кода и безопасно применить исправление; Если этот контекст ограничен, функция не попытается исправить.
    
  •         _Язык и охват фреймворков:_ Хотя Автофикс второго пилота поддерживает растущий список языков и оповещений CodeQL, он не охватывает все возможные типы или языки оповещений.
    

Качество предложений

          GitHub использует автоматизированный тестовый жгут для непрерывного мониторинга качества предложений из Автофикс второго пилота. Это позволяет понять, как предложения, созданные llM, изменяются при разработке модели.

Тестовая ремня включает набор из более чем 2300 оповещений из разнообразного набора общедоступных репозиториев, где выделенный код имеет тестовое покрытие. Предложения для этих оповещений проверяются, чтобы узнать, насколько они хороши, то есть сколько разработчику потребуется изменить перед фиксацией их в базе кода. Для многих тестовых оповещений предложения, созданные LLM, могут быть зафиксированы как есть, чтобы исправить оповещение, продолжая успешно проходить все существующие тесты CI.

Кроме того, система проверяет наличие любого потенциального вреда (часто называемого красным командированием), а система фильтрации на LLM помогает предотвратить потенциально опасные предложения, отображаемые пользователям.

Как GitHub тестирует предложения

Мы проверяем эффективность предложений, объединяя все предлагаемые изменения, не отредактированные, перед запуском code scanning и модульные тесты репозитория на полученном коде.

  1.        code scanning Был ли предупреждение исправлено благодаря предложению?
    
  2. Вводили ли исправления новые code scanning оповещения?
  3. Вводил ли исправление синтаксические ошибки, которые code scanning могут обнаружить?
  4. Изменило ли исправление выходные данные любого из тестов репозитория?

Кроме того, мы проверяем множество успешных предложений и проверяем, что они исправляют оповещение, не вводя новые проблемы. Когда одна или несколько этих проверок завершилась сбоем, наша ручная проверка показала, что во многих случаях предлагаемое исправление было почти правильно, но потребовалось некоторые незначительные изменения, которые пользователь может идентифицировать и вручную выполнить.

Эффективность других проектов

Набор тестов содержит широкий спектр различных типов проектов и оповещений. Мы прогнозируем, что предложения для других проектов с использованием языков, поддерживаемых , Автофикс второго пилота должны следовать аналогичной схеме.

  •         Автофикс второго пилота скорее всего, добавит предложение кода к большинству оповещений.
    
  • Когда разработчики оценивают предложения, мы ожидаем, что большинство исправлений может быть зафиксировано без редактирования или незначительных обновлений, чтобы отразить более широкий контекст кода.
  • Небольшой процент предлагаемых исправлений отражает значительное недоразумение базы кода или уязвимости.

Однако каждый проект и база кода уникальны, поэтому разработчикам может потребоваться изменить больший процент предлагаемых исправлений перед фиксацией. Автофикс второго пилота предоставляет ценную информацию для решения code scanning оповещений, но в конечном итоге ваша ответственность — оценить предлагаемые изменения и обеспечить безопасность и точность вашего кода.

Примечание.

Создание исправлений для поддерживаемых языков зависит от операционной емкости LLM. Кроме того, каждое предлагаемое исправление проверяется перед добавлением в запрос на вытягивание. Если предложение недоступно или если предлагаемое исправление завершается сбоем внутреннего тестирования, то не отображается никаких предложений.

Ограничения предложений

Когда вы рассматриваете предложение от Автофикс второго пилота, вы всегда должны учитывать ограничения ИИ и редактировать изменения по мере необходимости, прежде чем принимать изменения. Также стоит рассмотреть возможность обновления тестирования CI и управления зависимостями репозитория перед включением Автофикс второго пилота для code scanning. Дополнительные сведения см. в разделе "Устранение ограничений предложений".

Ограничения предложений кода

  •         _Человеческие языки:_ система в основном использует английские данные, в том числе запросы, отправленные в систему, код, видимый LLM в своих наборах данных, и тестовые варианты, используемые для внутренней оценки. Предложения, созданные LLM, могут иметь более низкую скорость успешного выполнения для исходного кода и комментариев, написанных на других языках и использующих другие наборы символов.
    
  •         _Синтаксические ошибки:_ система может предлагать исправления, которые не синтаксически исправляют изменения кода, поэтому важно выполнять проверки синтаксиса при запросах на вытягивание.
    
  •         _Ошибки расположения:_ система может предложить исправления, которые синтаксически правильный код, но предлагаются в неправильном расположении, что означает, что если пользователь принимает исправление без редактирования расположения, которое они будут вводить синтаксическую ошибку.
    
  •         _Семантические_ ошибки: система может предлагать исправления, которые синтаксически допустимы, но изменяют семантику программы. Система не понимает намерения программиста или базы кода в том, как должен вести себя код. Наличие хорошего покрытия тестов помогает разработчикам убедиться, что исправление не изменяет поведение базы кода.
    
  •         _Уязвимости системы безопасности и вводящие в заблуждение исправления:_ система может предложить исправления, которые не исправляют базовую уязвимость безопасности и /или вводят новые уязвимости безопасности.
    
  •         _Частичные исправления._ Система может предложить исправления, которые только частично устраняют уязвимость безопасности или только частично сохраняют предполагаемые функции кода. Система видит только небольшое подмножество кода в базе кода и не всегда создает глобально оптимальные или правильные решения.
    

Ограничения предложений зависимостей

Иногда предлагаемое исправление включает изменение зависимостей базы кода. Если вы используете систему управления зависимостями, все изменения будут выделены автоматически для просмотра разработчиком. Перед слиянием запроса на вытягивание всегда убедитесь, что все изменения зависимостей защищены и поддерживают предполагаемое поведение базы кода.

  •         _Новые или обновленные зависимости:_ система может предложить добавление или обновление зависимостей программного обеспечения в рамках предлагаемого исправления. Например, предлагая изменить `package.json` файл для проектов JavaScript, чтобы добавить зависимости из npm.
    
  •         _Неподдерживаемые или небезопасные зависимости:_ система не знает, какие версии существующей зависимости поддерживаются или защищены.
    
  •         _Структура зависимостей:_ система имеет неполные знания о зависимостях, опубликованных в более широкой экосистеме. Это может привести к предложениям, которые добавляют новую зависимость от вредоносного программного обеспечения, которое злоумышленники опубликовали под статистически вероятным именем зависимости.
    

Устранение ограничений предложений

Лучший способ уменьшить ограничения предложений Автофикс второго пилота — следовать лучшим практикам. Например, при тестировании CI запросов на вытягивание для проверки функциональных требований не влияет и используются решения для управления зависимостями, такие как API проверки зависимостей и действие. Дополнительные сведения см. в разделе Сведения о проверке зависимостей.

Важно помнить, что автор запроса на вытягивание сохраняет ответственность за то, как они реагируют на комментарии и предлагаемые изменения кода, будь то предложенные коллегами или автоматизированными средствами. Разработчики всегда должны внимательно смотреть на предложения по изменению кода. При необходимости они должны изменить предложенные изменения, чтобы гарантировать правильность и безопасность полученного кода и приложения, обеспечить соответствие критериям производительности и удовлетворять всем другим функциональным и нефункциональным требованиям для приложения.

Дальнейшие шаги

  •         [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts)
    
  •         [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests#working-with-autofix-suggestions-for-alerts-on-a-pull-request)
    
  •         [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/resolving-code-scanning-alerts#generating-suggested-fixes-for-code-scanning-alerts)
    
  •         [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/disabling-autofix-for-code-scanning)