Искусственный интеллект меняет скорость разработки радикально — ИИ-ассистенты позволяют писать код в 2-4 раза быстрее. Однако скорость создаёт новый класс рисков: более 40% ИИ-сгенерированного кода содержит уязвимости безопасности, ошибки обработки исключений встречаются в 1,91× чаще, а уязвимости межсайтового скриптинга — в 2,74× чаще, чем в коде человека. Отдельный вектор угроз — галлюцинированные зависимости, т.е. языковые модели предлагают несуществующие пакеты в ~20% случаев, а злоумышленники регистрируют эти имена с вредоносным содержимым.

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

Чек-лист выстроен в виде трёх взаимодополняющих уровней защиты: автоматизированная проверка (сканеры и конвейер сборки) покрывает весь код, но не улавливает контекст; участие человека (проверка кода и аудит) восполняет архитектурные слепые пятна; организационные процессы (управление ИИ и лимиты изменений) определяют условия, при которых работают первые два уровня. Уровни не взаимозаменяемы — каждый обнаруживает то, что пропускают другие.

Категория 1: Методы автоматизированной проверки (CI/CD, сканеры)

Статический анализ кода

• Настройте статический анализатор с правилами для ИИ-кода (Semgrep, SonarQube, CodeQL) с отдельными наборами правил для кода, сгенерированного языковыми моделями
  ⚠ Риск: традиционные сканеры пропускают уязвимости, типичные для ИИ-кода — жёстко прописанные секреты, конкатенация строк в SQL-запросах и т.п.
• Добавьте рейтинг безопасности «A» и покрытие тестами ≥ 80% как обязательные условия слияния
  ⚠ Риск: ИИ-код проходит в продакшн с незакрытыми уязвимостями (внедрение кода, нарушение аутентификации), поскольку языковые модели по умолчанию не генерируют валидацию входных данных
• Включите сканирование в редакторе кода в реальном времени (при наборе и при сохранении)
  ⚠ Риск: уязвимость обнаруживается на этапе проверки кода или позже, когда цена исправления многократно выше
• Разверните сканирование теневого ИИ для выявления несанкционированного использования ИИ-библиотек и утечки чувствительных данных
  ⚠ Риск: разработчики подключают неодобренные ИИ-инструменты, которые передают данные репозитория внешним провайдерам

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

• Добавьте проверки с атакующими нагрузками на внедрение промптов, межсайтовый скриптинг и внедрение SQL
  ⚠ Риск: ИИ-код содержит уязвимости межсайтового скриптинга в 2,74× чаще, чем человеческий, а внедрение промптов открывает возможность управления поведением системы через внешний ввод
• Внедрите агенты интерактивного тестирования для трассировки потока данных от вывода языковой модели до базы данных и внешних систем
  ⚠ Риск: архитектурно скрытые дефекты — код выглядит корректно при статическом анализе, но нарушает инварианты безопасности во время выполнения (подмена криптографических библиотек, удаление контроля доступа)
• Запускайте динамическое тестирование по расписанию (например, каждые 6 часов), а не только при отправке изменений
  ⚠ Риск: новые уязвимости появляются в транзитивных зависимостях после развёртывания, и проверки только в конвейере сборки их не обнаружат

Управление зависимостями

• Проверяйте каждую зависимость, предложенную ИИ, через Dependabot и Snyk
  ⚠ Риск: по данным USENIX Security 2025 (576 000 образцов, 16 моделей), в среднем 19,7% пакетов, предложенных ИИ-ассистентами, не существуют — прямой вектор атак через подставные пакеты
• Заблокируйте автоматическую установку пакетов, предложенных ИИ (auto_install: false) — любая новая зависимость требует ручного одобрения
  ⚠ Риск: злоумышленники регистрируют пакеты под галлюцинированными именами; коммерческие языковые модели галлюцинируют в ~5% случаев, модели с открытым кодом — в ~21,7%; 58% вымышленных имён появляются стабильно от сессии к сессии
• Задайте порог доверия к пакету: возраст ≥ 30 дней, число загрузок ≥ 1000, наличие двухфакторной аутентификации у разработчика
  ⚠ Риск: ИИ предлагает устаревшие или недавно зарегистрированные пакеты с уязвимостями, опубликованными уже после даты отсечения обучающих данных модели
• Формируйте реестр компонентов программного обеспечения (SBOM) для каждой сборки
  ⚠ Риск: без инвентаризации зависимостей невозможно подтвердить соответствие требованиям (SOC 2, Акт ЕС об ИИ) и провести ретроспективу при инциденте
• Проверяйте на атаки через подставные пакеты — пакеты, зарегистрированные под галлюцинированными именами языковых моделей
  ⚠ Риск: в январе 2026 исследователь Чарли Эриксен (Aikido Security) в ходе исследования занял имя несуществующего пакета react-codeshift и обнаружил, что оно уже присутствовало в 237 репозиториях через файлы агентских навыков, сгенерированных ИИ — без участия злоумышленников

Конвейер сборки и качество кода

• Установите порог качества: минимальное покрытие тестами 60% (базовый уровень) — 80% для нового ИИ-кода
  ⚠ Риск: ИИ систематически пропускает граничные случаи (пустые значения, пустые массивы, пограничные условия), которые не проявляются без тестового покрытия
• Помечайте коммиты с ИИ-кодом меткой ai-generated
  ⚠ Риск: без маркировки невозможно отделить человеческий и ИИ-код при аудите, применить избирательные правила и оценить реальную степень воздействия
• Настройте проверку времени выполнения конвейера < 10 минут
  ⚠ Риск: ИИ-код накапливает скрытый технический долг — избыточные зависимости и дублирующую логику, которые замедляют конвейер как ранний сигнал деградации
• Настройте политику контроля в виде кода: запросы на слияние с критическими уязвимостями или жёстко прописанными секретами блокируются автоматически
  ⚠ Риск: языковые модели регулярно генерируют жёстко прописанные учётные данные (CWE-798) и нарушения аутентификации (CWE-306) при отсутствии явных требований безопасности в запросе; частота некорректной обработки паролей в ИИ-коде в 1,88× выше

Категория 2: Методы участия человека (проверка кода, аудит)

Структура проверки кода

• Требуйте предварительной проверки ИИ перед проверкой человеком — разработчик сначала прогоняет код через Copilot или аналогичный инструмент, затем передаёт коллеге
  ⚠ Риск: перегрузка проверяющих при большом объёме запросов на слияние с ИИ-кодом снижает внимательность и создаёт иллюзию проверки — без снятия нагрузки качество проверки деградирует
• Обучайте проверяющих навыку поиска скрытых проблем — находить критичные ошибки внутри больших ИИ-сгенерированных изменений
  ⚠ Риск: архитектурные ошибки маскируются синтаксически правильным кодом; проверяющий склонен доверять «чистому» выводу сканера как окончательной проверке
• Явно предупреждайте проверяющих об эффекте подтверждения предвзятости
  ⚠ Риск: небольшое число замечаний от ИИ воспринимается как сигнал «код хороший», хотя ИИ может просто не обнаружить контекстозависимые уязвимости
• Применяйте стратегическое переключение инструментов: веб-интерфейс системы контроля версий — для небольших изменений, среда разработки — для архитектурной проверки
  ⚠ Риск: поверхностный просмотр разницы изменений в браузере не позволяет оценить влияние на смежные модули и систему в целом
• Требуйте заполнения поля охвата в шаблоне запроса на слияние: «что меняет этот запрос» и «что он явно НЕ меняет» — до начала проверки
  ⚠ Риск: ИИ-агенты расширяют охват незаметно (рефакторинг + новая функциональность + обновление зависимостей в одном запросе), проверяющий не замечает незапрошенных изменений

Проверка функциональности и безопасности

• Проверяйте соответствие архитектурным решениям, документации и стандартам оформления кода проекта
  ⚠ Риск: архитектурный дрейф — ИИ постепенно подменяет паттерны проекта сторонними, более «популярными» в обучающих данных, что нарушает внутреннюю согласованность
• Вручную проверяйте каждую предложенную зависимость и функцию интерфейса программирования
  ⚠ Риск: галлюцинированные интерфейсы и несуществующие методы приводят к ошибкам во время выполнения в продакшне, которые не воспроизводятся в тестовой среде
• Проверяйте граничные случаи вручную: пустые значения, пустые массивы, пограничные условия
  ⚠ Риск: ИИ систематически оптимистичен — генерирует основной сценарий без защитного программирования, что даёт ошибки только на реальных данных
• Проверяйте обработку ошибок: нет ли общих исключений вместо специализированных классов ошибок проекта
  ⚠ Риск: частота пробелов в обработке ошибок в ИИ-коде в 1,91× выше, чем в коде человека; это маскирует сбои и усложняет реагирование на инциденты
• Проводите аудит совместимости лицензий (анализ зависимостей + ручная проверка)
  ⚠ Риск: ИИ предлагает код под лицензией AGPL-3.0 в проектах с лицензией MIT — это открывает компанию к судебным претензиям и лицензионному заражению

Специализированный аудит

• Проводите регулярный аудит безопасности ИИ-инструментов силами выделенного сотрудника по управлению ИИ-рисками
  ⚠ Риск: без систематического аудита накапливается «тихий» технический долг и скрытые риски, которые не попадают ни в один из регулярных процессов проверки
• Организуйте имитацию атак на внедрение промптов и состязательные входные данные
  ⚠ Риск: системы, принимающие внешние данные, могут быть переориентированы через специально сформированный ввод — логика языковых моделей не различает легитимный и враждебный контекст
• Документируйте все решения об отклонении предупреждений с обоснованием при принятии кода вопреки сигналу сканера
  ⚠ Риск: без записи таких решений невозможно провести аудит и найти источник уязвимости после инцидента; это также сигнал о нездоровой культуре обхода средств контроля
• Проводите парную проверку для модулей аутентификации, платёжной логики и уровня доступа к данным
  ⚠ Риск: нарушения контроля доступа и аутентификации — наиболее частые уязвимости ИИ-кода при автоматической генерации полностековых сервисов с минимальными инструкциями

Категория 3: Организационные процессы (управление ИИ, лимиты изменений)

Лимиты и политика изменений

• Введите лимиты размера запроса на слияние: мягкий лимит — 400 строк, жёсткий лимит — 800 строк; превышение требует второго проверяющего
  ⚠ Риск: по данным нескольких независимых исследований (SmartBear, Google, Graphite), качество проверки резко падает после 400 строк — вероятность пропустить дефект возрастает с 87% до 28%
• Ограничьте количество файлов в запросе на слияние с ИИ-кодом до 20
  ⚠ Риск: более 20 файлов почти всегда означает неконтролируемое расширение охвата — агент «решил» больше, чем требовалось, и вносит незапрошенные изменения в несвязанные модули
• Соблюдайте правило атомарного охвата: один запрос на слияние — одна задача; смешение новой функциональности, рефакторинга и обновления зависимостей запрещено
  ⚠ Риск: смешанные запросы скрывают связанные изменения между функциональными блоками, делая частичный откат невозможным без регрессий
• Настройте многоуровневую маршрутизацию проверок: запросы на слияние > 400 строк автоматически направляются к старшему разработчику или специалисту по безопасности
  ⚠ Риск: младшие разработчики не имеют контекста для оценки архитектурных последствий крупных изменений; ИИ-код особенно опасен именно своей «правдоподобностью»
• Используйте поэтапное развёртывание для изменений с ИИ-кодом: ≤ 5–10% трафика с мониторингом метрик перед полным выводом в продакшн
  ⚠ Риск: поведенческие аномалии ИИ-кода (нетипичная нагрузка, утечки памяти, неожиданные коды ответа) проявляются только под реальным трафиком

Управление ИИ

• Назначьте ответственного руководителя и операционного владельца для каждого ИИ-инструмента в процессе разработки
  ⚠ Риск: без именованного владельца ответственность размыта — при инциденте некому принимать решения; для провайдеров высокорисковых ИИ-систем это также нарушение требований Акта ЕС об ИИ об ответственности
• Ведите реестр сценариев использования ИИ с уровнем риска, поставщиком и статусом по Акту ЕС об ИИ (Приложение III)
  ⚠ Риск: «теневой ИИ» — неучтённые инструменты в командах — создаёт неконтролируемые точки утечки данных и неаудируемые решения
• Создайте матрицу решений: что ИИ делает автоматически, что требует одобрения человека, что остаётся в режиме только для чтения
  ⚠ Риск: без чёткого разграничения ИИ-агенты получают избыточные права и могут вносить изменения в области, для которых не предназначены
• Задокументируйте и протестируйте механизм аварийного отключения любого ИИ-агента
  ⚠ Риск: отсутствие проверенного механизма принудительной остановки означает, что при инциденте невозможно быстро изолировать агента, пока он продолжает действовать
• Определите путь эскалации для исключений, сбоев и нештатных выводов
  ⚠ Риск: без заранее определённого маршрута эскалации инциденты решаются хаотично — каждая команда действует по-своему, теряется время и контекст

Аудит, журналирование и соответствие требованиям

• Фиксируйте все взаимодействия с ИИ-агентами: запросы, ответы, одобрения, действия в системах
  ⚠ Риск: без полного журнала невозможно восстановить цепочку принятия решений при аудите или выяснить, какой именно запрос привёл к уязвимому коду
• Обеспечьте журнал аудита, защищённый от подделки, с криптографической подписью записей
  ⚠ Риск: незащищённые журналы могут быть изменены или удалены, что делает их непригодными как доказательство при регуляторных проверках (SOC 2, HIPAA, Акт ЕС об ИИ)
• Отслеживайте долю решений об отклонении предупреждений; аномальный показатель — сигнал операционной проблемы
  ⚠ Риск: высокий показатель указывает на «усталость от предупреждений» — разработчики отключают средства контроля под давлением сроков; низкий показатель — на чрезмерное и некритическое доверие ИИ
• Внедрите мониторинг поведения с эталонным состоянием: зафиксируйте ожидаемое распределение выводов при развёртывании; отклонения → оповещение
  ⚠ Риск: дрейф модели или тихая замена версии модели провайдером могут незаметно изменить поведение системы; без зафиксированного эталона это невозможно обнаружить
• Разработайте план реагирования на ИИ-инциденты (отдельный от общего плана реагирования на инциденты в ИТ)
  ⚠ Риск: ИИ-инцидент может затронуть сотни решений до обнаружения; Статья 73 Акта ЕС об ИИ обязывает провайдеров высокорисковых систем (Приложение III) уведомлять национальных регуляторов — без отдельного плана выполнить это требование в срок невозможно

Культура и обучение

• Назначьте ответственных за развитие культуры ИИ в командах; они обновляют руководство по участию в проекте с требованиями к ИИ-коду
  ⚠ Риск: без ролевой ответственности лучшие практики не распространяются, а онбординг новых сотрудников формирует небезопасные привычки с первого дня
• Обновите процесс ввода в должность и документацию: правила работы с ИИ-инструментами до первого коммита
  ⚠ Риск: 65% разработчиков принимают ИИ-сгенерированный код без полного понимания его логики — это системная проблема знаний, которую нельзя закрыть только инструментами
• Проводите ежемесячные учения по откату изменений: команда должна уметь быстро отменить изменения, внесённые ИИ
  ⚠ Риск: процедуры отката без регулярной отработки дают сбои в самый неподходящий момент — под давлением инцидента команда действует медленно и допускает ошибки
• Собирайте метрики эффективности: среднее время обнаружения < 5 мин, доля ложных срабатываний < 15%, охват ИИ-кода проверками > 95%, доля ускользнувших дефектов < 1%
  ⚠ Риск: без измерений невозможно понять, работают ли средства контроля — организация тратит ресурсы на проверки, не зная их реальной отдачи