Как использовать /security-review в GitHub Copilot App до Pull Request

Частая ошибка — считать, что команда /security-review превращает GitHub Copilot App в полноценную систему AppSec и автоматически подтверждает безопасность проекта. На практике это более узкий инструмент: он помогает быстро проверить текущие изменения в активной Agent-сессии, пока Pull Request ещё не создан. Поэтому важно не только знать, как использовать /security-review в GitHub Copilot App, но и понимать, какие выводы команда действительно позволяет сделать, а какие требуют других проверок.

Ниже разберём рабочий процесс на 24 июля 2026 года: подготовку локального проекта, запуск анализа, интерпретацию серьёзности и уверенности, исправление находок и повторную проверку. Отдельно сопоставим этот механизм с CodeQL, Dependabot и secret scanning, чтобы вы не пытались решить одной AI-командой задачи разных классов.

Роль /security-review в рабочем процессе

/security-review — slash-команда GitHub Copilot App, которую можно запустить внутри активной Agent-сессии с текущими изменениями. GitHub описывает её как проверку рабочей ветки на уязвимости с высокой вероятностью, результатом которой становятся приоритизированные находки, оценки серьёзности и уверенности, а также предложения по исправлению. Функция находится в публичном предварительном доступе и может измениться. (docs.github.com)

Практически команда полезнее всего в трёх точках:

1. после реализации чувствительного участка — авторизации, загрузки файлов, обработки вебхуков или SQL-запросов;
2. перед коммитом, когда изменения ещё легко откатить;
3. перед созданием Pull Request, чтобы убрать очевидные проблемы до подключения ревьюеров и CI.

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

Для разработчика это быстрый слой предварительной проверки. Для руководителя команды — дополнительная точка контроля перед PR. Для специалиста по AppSec — источник гипотез, которые необходимо подтвердить инструментами и ручным анализом.

Ограничения до запуска

Перед тем как вводить команду, проверьте четыре условия.

Активная Agent-сессия. В быстрых чатах без рабочей сессии команда может быть недоступна, потому что ей нужен конкретный проект и рабочее состояние. В GitHub Copilot App каждая Agent-сессия работает в изолированном рабочем пространстве, поэтому параллельные задачи не должны смешивать изменения друг друга. (docs.github.com)

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

Достаточный контекст. Если уязвимость зависит от маршрутизации, схемы базы данных, middleware или переменных окружения, одной изменённой функции может быть недостаточно. Добавьте в запрос сведения о точке входа, источнике данных и ожидаемом поведении, но не вставляйте реальные токены и пароли.

Понимание статуса функции. Публичный предварительный доступ означает, что интерфейс, качество результатов и доступность команды могут меняться. Не включайте /security-review как единственный блокирующий критерий релиза без независимой проверки и согласованной процедуры отклонения результата.

Запуск проверки изменений

Надёжный сценарий занимает пять последовательных шагов.

1. Подготовка ветки

Откройте проект в GitHub Copilot App и переключитесь на ветку, где находятся ваши изменения. Перед анализом выполните локальную проверку состояния:

git status
git diff --stat
git diff -- src/auth

Первой командой вы подтверждаете наличие изменений, второй — оцениваете их объём, третьей — смотрите содержимое чувствительного участка. Если изменения уже закоммичены, убедитесь, что активная Agent-сессия действительно работает с нужной веткой и рабочим деревом.

2. Создание или открытие Agent-сессии

В панели сессий выберите проект и рабочее пространство. Документация GitHub указывает, что при создании сессии можно использовать локальный репозиторий, проект из GitHub, рабочее дерево или изолированную облачную среду предварительного доступа. (docs.github.com)

Для проверки локального кода выбирайте именно тот вариант, где присутствует ваша текущая ветка. Ошибка на этом шаге приводит к типичной ситуации: команда запускается, но анализирует не тот снимок проекта.

3. Формулировка области аудита

В поле запроса сначала опишите, что изменилось. Например:

Проверь изменения в обработчике загрузки файлов, включая проверку имени,
пути сохранения, MIME-типа и прав доступа. Учитывай связанные тесты
и конфигурацию маршрута.

После этого введите:

/security-review

И нажмите Enter. Официальная последовательность состоит из открытия активной сессии с незавершёнными изменениями, запуска slash-команды и последующего просмотра найденных проблем. (docs.github.com)

4. Проверка результата

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

Удобный порядок:

• сначала изучить критичные и высокосерьёзные пункты;
• затем проверить находки со средней серьёзностью;
• после этого просмотреть рекомендации с высокой уверенностью;
• отдельно отметить подозрительные места с низкой уверенностью для ручного анализа.

5. Фиксация решения

Для каждой находки запишите одно из трёх решений: исправить сейчас, подтвердить вручную и оставить задачу, либо обосновать ложное срабатывание. Такая запись полезна при ревью Pull Request и не даёт команде потерять контекст после обновления ветки.

Серьёзность и уверенность

Серьёзность отвечает на вопрос «насколько опасна проблема, если она реальна». Уверенность отвечает на другой вопрос — «насколько убедительно анализ указывает именно на эту проблему». Эти показатели нельзя смешивать.

Пример: команда может показать высокую серьёзность и среднюю уверенность для потенциальной SQL-инъекции. Это означает не «уязвимость доказана», а «если путь данных подтверждается, последствия могут быть значительными». Вам нужно проверить, поступает ли значение от пользователя, используется ли параметризация и достижим ли конкретный запрос.

При чтении результата смотрите на четыре элемента:

1. Источник данных — откуда приходит значение: HTTP-запрос, заголовок, файл, переменная окружения или внутренний объект.
2. Путь обработки — какие преобразования выполняются до передачи в SQL, shell-команду, шаблонизатор или файловую систему.
3. Точку использования — действительно ли опасное значение попадает в чувствительную операцию.
4. Механизм защиты — есть ли валидация, экранирование, параметризованный API, ограничение прав или безопасная библиотека.

Такая схема помогает не переписывать код механически. Иногда исправление, предложенное AI, снижает видимый риск, но ломает авторизацию, локализацию ошибок или совместимость API. Поэтому рекомендацию следует рассматривать как вариант патча, а не как готовое решение.

Практическое сравнение инструментов

Вопрос «Copilot безопасность и CodeQL — в чём разница?» возникает потому, что названия задач пересекаются. На самом деле инструменты работают на разных этапах.

GitHub прямо позиционирует /security-review как лёгкую проверку, дополняющую code scanning, Dependabot и secret scanning, а не заменяющую их. (docs.github.com) CodeQL предназначен для поиска проблем безопасности в коде, Dependabot сверяет зависимости с базой рекомендаций, а secret scanning ищет чувствительные значения вроде API-ключей и токенов. (docs.github.com)

В результате правильная комбинация выглядит так: /security-review — быстрый анализ локальных изменений, CodeQL — системный анализ кода в CI, Dependabot — контроль сторонних пакетов, secret scanning — отдельный барьер против утечки учётных данных.

Исправление и повторная проверка

После обнаружения проблемы не просите Agent просто «исправить всё». Сначала ограничьте задачу конкретным сценарием.

1. Воспроизведите риск. Опишите минимальный вход, который приводит к небезопасному поведению. Для авторизации это может быть запрос без нужной роли, для файлов — путь с переходом в родительский каталог.
2. Проверьте границу доверия. Установите, какие данные контролирует пользователь, а какие формируются внутри приложения.
3. Выберите защиту. Предпочтительны безопасные API, строгая валидация, параметризация запросов и минимальные права, а не набор разрозненных фильтров.
4. Попросите Agent внести минимальный патч. Укажите затронутые файлы и запретите менять несвязанные участки.
5. Запустите тесты и линтеры. Минимум — тесты изменённого модуля; для критичной логики — интеграционный сценарий.
6. Проверьте diff. Убедитесь, что исправление не удалило проверку авторизации, не ослабило обработку ошибок и не добавило секрет в тестовые данные.
7. Повторно выполните /security-review. Сравните старую и новую выдачу. Исчезновение сообщения ещё не доказывает, что проблема решена: оно показывает только изменение оценки модели.

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

Ошибки, пропуски и ложные срабатывания

Пустой результат

Сначала проверьте git status и git diff. Затем убедитесь, что Agent-сессия открыта на правильном рабочем пространстве. Если изменён только файл конфигурации, а уязвимость находится в другом модуле, расширьте описание задачи и явно укажите связанные файлы.

Ложное срабатывание

Чтобы понять, как обработать ошибочное сообщение /security-review, не удаляйте кодовую защиту сразу. Проверьте, действительно ли значение проходит через опасную операцию, есть ли нормализация ранее и ограничивает ли фреймворк допустимый ввод. После этого сохраните объяснение в Pull Request или внутренней задаче.

Пропущенная проблема

AI-анализ может не увидеть уязвимость, если критичный контекст находится за пределами текущего изменения, в динамической конфигурации или во внешнем сервисе. Сформулируйте дополнительный запрос с конкретным потоком данных, а затем используйте CodeQL, тесты, ручной аудит и проверку конфигурации.

GitHub отдельно предупреждает, что Copilot может выдавать некорректные решения и даже генерировать небезопасный код, поэтому результат необходимо тестировать и проверять до использования в производстве. (docs.github.com)

Безопасный сценарий перед Pull Request

Если вы ищете, как проверить уязвимости до отправки кода, используйте такой порядок:

1. создайте отдельную ветку;
2. внесите изменение и проверьте diff;
3. удалите из рабочей области реальные токены, дампы и персональные данные;
4. запустите /security-review в активной Agent-сессии;
5. подтвердите каждую находку вручную;
6. исправьте код минимальным патчем;
7. выполните тесты, линтеры и проверку зависимостей;
8. повторите /security-review;
9. создайте Pull Request;
10. дождитесь CI, CodeQL и ревью команды.

Такой процесс снижает риск принятия AI-вывода за окончательное заключение. Особенно важно не отправлять в Agent-сессию содержимое .env, приватные ключи, производственные логи и клиентские данные без разрешённой политики обработки.

Тестовый сценарий Kvmzen

Для редакционной проверки Kvmzen такой материал лучше воспроизводить в отдельном тестовом репозитории, а не в рабочем проекте. Создайте откатываемую ветку и добавьте контролируемую проблему: например, небезопасное формирование пути к файлу или отсутствие проверки доступа к тестовому административному маршруту.

Далее зафиксируйте:

• имя ветки и хеш исходного коммита;
• список изменённых файлов;
• текст запроса перед /security-review;
• отображённые серьёзность и уверенность;
• предложенный способ исправления;
• результат тестов до и после патча;
• повторный результат проверки;
• решение человека: исправлено, требует задачи или признано ложным срабатыванием.

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

Если для тестовой ветки нужен постоянно доступный macOS-компьютер, можно использовать аренду Mac mini для удалённой разработки. Для распределённых команд также пригодятся региональные варианты аренды Mac mini в США или аренды Mac mini в Японии, если важны задержка и стабильность подключения.

Текущая схема и Mac-окружение

На локальном Windows или Linux-компьютере такой процесс часто упирается не в саму команду, а в окружение: нестабильные зависимости, различия shell, отсутствие нужной версии инструмента и невозможность оставить тестовую сессию включённой на ночь. Виртуальная машина добавляет расход памяти и отдельный слой сетевых настроек, а временный облачный сервер требует ручной настройки доступа, хранения ключей и очистки рабочего пространства.

Аренда Mac через Kvmzen может быть практичнее для команд, которым нужно постоянное удалённое macOS-окружение для GitHub Copilot App, тестовой ветки и повторяемых проверок. Это не делает /security-review точнее автоматически, но упрощает операционную часть: один подготовленный Mac, стабильный набор инструментов, доступ по удалённому подключению и возможность не смешивать эксперименты с рабочим ноутбуком. В результате вы можете повторять цикл «изменение — анализ — исправление — тест — повторная проверка» без постоянного пересоздания среды.