Skip to main content

О автофиксе для сканирования кода CodeQL

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

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

Автофикс для code scanning доступен только для пользователей GitHub Enterprise Cloud, у которых есть GitHub Advanced Security. Дополнительные сведения см. в разделе Сведения о GitHub Advanced Security.

Note

Автофикс GitHub для code scanning находится в бета-версии. Функциональные возможности и документация могут быть изменены. На этом этапе функция ограничена оповещениями, определенными CodeQL для частных и внутренних репозиториев. Если у вас есть корпоративная учетная запись и используется GitHub Advanced Security, у вашей организации есть доступ к бета-версии.

О автофиксе для CodeQL code scanning

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

Note

Хотя автофикс code scanning работает с помощью GitHub Copilot, ваше предприятие не нуждается в подписке на GitHub Copilot для использования автофикса. Если у вашей организации есть GitHub Advanced Security, у вас будет доступ к автофиксу.

Автофикс Code scanning создает потенциальные исправления, относящиеся к существующему исходному коду, и преобразует описание и расположение оповещения в изменения кода, которые могут исправить оповещение. Autofix использует внутренние API -интерфейсы GitHub Copilot, взаимодействующие с большой языковой моделью GPT-4o из OpenAI, которая имеет достаточные возможности для создания предлагаемых исправлений в коде и пояснительных текстах для этих исправлений.

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

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

Режим разработчика

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

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

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

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

Автофикс Code scanning поддерживает создание исправлений для подмножества запросов, включенных в наборы запросов по умолчанию и расширенным безопасностью для C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python и Ruby. Дополнительные сведения об этих наборах запросов см. в разделе "Наборы запросов CodeQL".

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

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

GitHub отправляет LLM различные данные из анализа CodeQL.

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

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

Процесс создания исправлений не собирает или не использует данные клиента за пределами указанной выше области. Поэтому использование этой функции регулируется существующими условиями, связанными с GitHub Advanced Security. Кроме того, данные, обрабатываемые автофиксом code scanning, строго не используются для обучения LLM. Дополнительные сведения об условиях GitHub Advanced Security см. в разделе "Условия GitHub для дополнительных продуктов и функций в документации по бесплатной, pro и команде.

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги