Чек-лист выживания для команд, которые включили в разработку ИИ-агентов
Искусственный интеллект меняет скорость разработки радикально — ИИ-ассистенты позволяют писать код в 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% трафика с мониторингом метрик перед полным выводом в продакшн.
⚠ Риск: поведенческие аномалии ИИ-кода (нетипичная нагрузка, утечки памяти, неожиданные коды ответа) проявляются только под реальным трафиком
Аудит, журналирование и соответствие требованиям
- Фиксируйте все взаимодействия с ИИ-агентами: запросы, ответы, одобрения, действия в системах.
⚠ Риск: без полного журнала невозможно восстановить цепочку принятия решений при аудите или выяснить, какой именно запрос привёл к уязвимому коду. - Отслеживайте долю решений об отклонении предупреждений; аномальный показатель — сигнал операционной проблемы.
⚠ Риск: высокий показатель указывает на «усталость от предупреждений», разработчики отключают средства контроля под давлением сроков; низкий показатель — на чрезмерное и некритическое доверие ИИ. - Внедрите мониторинг поведения с эталонным состоянием: зафиксируйте ожидаемое распределение выводов при развёртывании; отклонения → оповещение.
⚠ Риск: дрейф модели или тихая замена версии модели провайдером могут незаметно изменить поведение системы; без зафиксированного эталона это невозможно обнаружить. - Разработайте план реагирования на ИИ-инциденты (отдельный от общего плана реагирования на инциденты в ИТ).
⚠ Риск: ИИ-инцидент может затронуть сотни решений до обнаружения.