Чтобы проверить код, сгенерированный ИИ, до запуска, изучите полный diff и каждую предложенную команду, а затем проверьте рамки задачи, зависимости, права доступа, секреты, внешние эффекты, тесты и план отката. Не выполняйте патч только потому, что в объяснении модели он «компилируется» или сопровождается уверенным резюме.

Этот чек-лист начинается после того, как код уже сгенерирован. Для постановки задачи и безопасной передачи контекста используйте процесс программирования с ИИ. Если есть конкретный сбой, сначала пройдите отладку на основе доказательств, а уже потом решайте, нужен ли патч.

Ключевые выводы

Прежде чем читать детали реализации, сравните diff с разрешённой задачей.

Изменения зависимостей, lock-файла, хуков сборки, прав доступа и миграций — отдельные решения о риске.

Ищите секреты и недоверенные данные, пересекающие границы команд, запросов, путей, URL и шаблонов.

Проверяйте команды до выполнения и начинайте в ограниченной одноразовой среде.

Требуйте тестов, независимого проверяющего там, где этого требует риск, и работоспособного пути отката.

Проверяйте снаружи внутрь: границы задачи, список файлов, цепочка поставок, интерфейсы, поток данных, эффекты, поведение при сбоях, тесты и план выполнения. В рекомендациях GitHub по ответственному использованию сказано, что сгенерированный код может быть неточным или небезопасным и его нужно тщательно проверять и тестировать.［1］

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

Что зафиксировать до начала проверки?

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

Запишите, к чему у модели был доступ: пути в репозитории, переменные окружения, сеть, внешние инструменты и учётная запись. Этот контекст помогает объяснить, откуда в результате взялся неожиданный файл или команда.

Шаг 1: Проверьте рамки задачи и назначение файлов

Перечислите все добавленные, изменённые, переименованные и удалённые файлы. Для каждого напишите одну строку о том, зачем он нужен для разрешённой задачи. Необъяснимый файл — сигнал остановиться, а не повод для уборки.

Спросите себя:

Решает ли патч запрошенное поведение или перепроектирует более крупную подсистему?
Не смешаны ли сгенерированные файлы с исходниками, отредактированными вручную?
Не переписало ли форматирование посторонние строки, скрыв смысловые изменения?
Согласованно ли изменены тесты, документация, конфигурация и схемы?
Не удалил ли патч защитную проверку, ветку валидации, ошибку или событие аудита?

Отклоняйте рефакторинг «заодно», если его явно не одобряли. Меньший diff не гарантирует правильности, но упрощает оценку намерения и отката.

Читайте конфигурацию до прикладного кода

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

Обращайте внимание на значение по умолчанию, сменившееся с «запретить» на «разрешить», команду валидации, удалённую из CI, или расширенный шаблон пути. Они могут нести больше риска, чем основное изменение кода.

Шаг 2: Изучите зависимости и цепочку поставок

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

Не принимайте довод «библиотека популярна» как доказательство. Спросите, нет ли в репозитории уже подходящей зависимости и не будет ли понятнее несколько строк на стандартной библиотеке. После проверки запустите принятый в проекте аудит зависимостей в правильной среде.

Подсказки ИИ могут совпадать с публичным кодом. В документации GitHub о code referencing объясняется, что поддерживаемые интерфейсы Copilot могут показывать совпадающие репозитории и найденные сведения о лицензии, и там же описаны ограничения индекса и охвата.［2］ Считайте уведомление о совпадении поводом проверить происхождение и лицензию, а отсутствие уведомления — не доказательством оригинальности кода.

Проверьте поведение сборки и установки

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

Шаг 3: Проследите данные, секреты и права

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

Проверьте, куда попадает ввод:

Приёмник	Вопросы
Оболочка или дочерний процесс	Отделены ли аргументы от синтаксиса оболочки? Зафиксирован ли исполняемый файл?
Запрос к базе данных	Параметризовано ли значение? Нельзя ли обойти фильтры авторизации?
Путь в файловой системе	Нормализуется ли путь внутри разрешённого корня? Безопасно ли обрабатываются ссылки?
URL или сетевой вызов	Ограничены ли схема, хост, перенаправления, учётные данные и размер ответа?
Шаблон или средство отрисовки	Экранируется ли недоверенное содержимое для реального контекста вывода?
Десериализатор	Ограничены ли типы, глубина, размер и неожиданные поля?

Ищите в изменённых строках и соседнем коде учётные данные, токены, закрытые ключи, cookie, строки подключения и подписанные URL. Затем проверьте, не записывает ли патч чувствительные значения в журнал, не возвращает ли, не кэширует ли и не отправляет ли их новому адресату. Сканеры секретов полезны, но значение, собранное во время выполнения, может не совпасть со статическим шаблоном.

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

Шаг 4: Проверьте внешние и разрушительные эффекты

Отделяйте вычисление от эффекта. Код, который готовит запрос, отличается от кода, который его отправляет; код, проверяющий миграцию, — от кода, который её применяет.

Это контролируемый локальный пример проверки с синтетическим diff и списком команд. В нём нет рабочего кода или секретов, и он не утверждает, что пример был одобрен или выполнен.

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

OpenAI описывает песочницу, политики одобрения, ограниченный сетевой доступ, управление учётными данными и телеметрию как отдельные меры контроля для агентов программирования.［3］ Проверьте, использует ли предложенный запуск реальные меры контроля проекта: комментарий «запускать в песочнице» песочницу не создаёт.

Проверяйте миграции отдельно

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

Шаг 5: Проверьте поведение при сбоях и допущения о параллельности

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

Не придумывайте сложности с параллельностью для локального одноразового скрипта, но проверьте реальную модель выполнения. Если с одним и тем же состоянием могут работать несколько обработчиков, вебхуков, развёртываний или пользователей, проверьте блокировки, уникальность, идемпотентность, чтение устаревших данных и то, кто отвечает за повторные попытки. Последовательность «проверить, затем записать» может быть корректной в одном процессе и небезопасной в общем сервисе.

Для многошагового изменения, созданного агентом, полезно объяснение устройства ИИ-агента: оно показывает, почему права инструментов, состояние, условия выхода и передача управления важны независимо от ответа модели.

Шаг 6: Прочитайте тесты до запуска

Читайте тесты как утверждения. Убедитесь, что они падают на старом поведении, проверяют публичный контракт и не «заглушают» тот самый риск, который якобы покрывают.

Требуйте подходящих сценариев:

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

Ищите удалённые проверки (assertions), массовое обновление снимков, пропущенные тесты, ослабленные тайм-ауты или суженную команду запуска, скрывающую сбои. Сгенерированные тесты могут повторять реализацию и всё равно не проверять требование.

NIST Secure Software Development Framework также рассматривает ревью, анализ и тестирование кода как часть более широкой практики проверки.［4］ Поэтому читаемый diff и независимые результаты тестов дополняют друг друга, а не заменяют.

Шаг 7: Спланируйте ограниченный запуск и откат

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

До выполнения запишите:

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

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

Получите профильную проверку

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

Как проверить код, сгенерированный ИИ, перед решением о первом запуске?

Не запускайте код, если хотя бы на один пункт нет ответа:

Задача и список изменённых файлов совпадают.
Новые зависимости и совпадения с публичным кодом понятны.
Секреты и недоверенные данные не попадают в небезопасные приёмники.
Права доступа и внешние эффекты ограничены и разрешены.
Поведение при сбоях, повторных попытках, миграциях и откате приемлемо.
Тесты покрывают контракт и риск, а не только реализацию.
Первая среда выполнения ограничена и по возможности одноразова.
У решения о значимом изменении есть названный ответственный человек.

Прохождение списка означает, что код готов к контролируемому тестированию, а не к рабочей среде.

Итоги

Проверьте разрешённые рамки задачи и полный diff до деталей реализации.
Изучите конфигурацию, зависимости, lock-файлы, хуки установки и происхождение кода.
Проследите недоверенный ввод, секреты, права доступа и внешние эффекты.
Изучите поведение при сбоях, повторных попытках, параллельной работе, миграциях и откате.
Читайте тесты до запуска и сохраняйте независимую проверку.
Начинайте выполнение в ограниченной среде, а проверку в рабочей среде держите отдельно.

Часто задаваемые вопросы (FAQ)

Код ИИ опаснее человеческого?

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

Можно ли запускать код ИИ, если он компилируется?

Компиляция проверяет синтаксис и часть контрактов типов. Она не доказывает правильность авторизации, безопасность данных, надёжность зависимостей, поведение при сбоях или корректность бизнес-логики.

Принимать ли новую зависимость, предложенную ИИ?

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

Как проверить код ИИ на секреты?

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

Что проверить перед запуском сгенерированной команды?

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

Доказывают ли тесты в песочнице, что код безопасен для рабочей среды?

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

Когда нужно привлекать специалиста по безопасности?

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

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

Источники:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
GitHub Docs — GitHub Copilot code referencing — https://docs.github.com/en/copilot/concepts/completions/code-referencing
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 24 августа 2026 г.

Рекомендуемые статьи:

Как проверить код, сгенерированный ИИ, до запуска