Как безопасно использовать ИИ в разработке: руководство для команды

ИИ уже пишет ваш код. Вопрос в том, кто несёт ответственность за то, что он написал

Почему это важно именно сейчас

По данным Stack Overflow Developer Survey 2024, 76% разработчиков уже используют или планируют использовать ИИ-инструменты в своей работе, а 62% делают это ежедневно [1]. GitHub Copilot вырос до 1,8 миллиона платных подписчиков [2]. Cursor сообщал о генерации одного миллиарда строк кода в сутки к апрелю 2025 года [3].

Скорость — реальная. Исследования GitHub показывают ускорение рутинных задач до 55% [1]. Но ускорение создания кода не тождественно ускорению создания безопасного кода. Модели обучены на огромных массивах публичного кода, который сам по себе содержит ошибки и уязвимости. Когда модель предсказывает следующий токен, она оптимизирует синтаксис и функциональность, а не безопасность [4].

Отчёт Veracode за 2025 год проверил более ста LLM на четырёх языках программирования и обнаружил уязвимости в 45% сгенерированного кода [5]. Другие исследования называют диапазон от 25% до 75% в зависимости от языка и методологии [6]. Важно понимать: это не edge case. Это норма текущего состояния технологии.

При этом ни один из ведущих вендоров не обещает, что их инструмент пишет безопасный код. Пользовательские соглашения прямо перекладывают ответственность на разработчика и компанию [7].

Карта рисков: что именно может пойти не так

1. Небезопасные паттерны в коде

Модели воспроизводят паттерны из обучающих данных. Если в интернете много небезопасного кода — а его там много — модель будет предлагать небезопасный код с уверенным видом. Исследование NYU Tandon (2022), ставшее классическим в области, протестировало Copilot на 89 сценариях из CWE Top 25 и зафиксировало уязвимости в 40% случаев [5].

Особенно высок риск в следующих зонах:

• аутентификация и управление сессиями
• криптография (использование устаревших алгоритмов или неправильная реализация)
• обработка пользовательского ввода (SQL-инъекции, XSS)
• управление доступом и авторизация
• обработка ошибок и логирование

Ключевая проблема: ИИ понимает структуру и синтаксис кода, но не понимает архитектурный контекст вашей системы — где проходят границы доверия, какие данные чувствительны, какие процессы требуют особой защиты [4]. Именно здесь возникает разрыв, который нельзя закрыть инструментом: его закрывает только человек, который знает систему.

2. Утечка секретов и чувствительных данных

Одна из наиболее распространённых и болезненных проблем: ИИ-ассистент предлагает фрагмент, в котором API-ключ или токен захардкожен прямо в коде. Разработчик быстро принимает suggestion, не дочитав до конца — и секрет попадает в репозиторий.

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

Кроме того, согласно совместному отчёту ANSSI и BSI (2024), облачные ИИ-сервисы создают риски конфиденциальности: код и контекст передаются на серверы третьих сторон, что критично для коммерческих проектов с чувствительной логикой [9].

Для российских команд, работающих с Copilot Free через личные GitHub-аккаунты, риск особенно актуален: корпоративного договора, ограничивающего передачу данных, в этом случае нет [10].

3. Галлюцинированные зависимости и slopsquatting

Это новый и недооценённый вектор атаки на цепочку поставок. Исследование, опубликованное на USENIX Security Symposium 2025, проанализировало 576 000 кодовых примеров от 16 LLM и обнаружило, что почти 20% рекомендованных пакетов не существует ни в одном публичном реестре [11].

Опенсорсные модели галлюцинируют чаще — около 22%, коммерческие инструменты вроде GPT-4 — примерно в 5% случаев [12]. Проблема не только в количестве: 43% галлюцинированных имён пакетов повторяются при повторных запросах, то есть они предсказуемы [12].

Этим пользуются злоумышленники. Явление получило название slopsquatting: атакующий регистрирует пакет с именем, которое LLM часто придумывает, — и разработчик, следуя совету ИИ, устанавливает вредоносный пакет. Один скомпрометированный install — и в сборку попадает произвольный код.

По данным Endor Labs, только один из пяти пакетов, предложенных ИИ-инструментами, одновременно существует и не содержит известных уязвимостей [6]. То есть 80% рекомендаций несут тот или иной риск.

4. Атаки через конфигурационные файлы ИИ-инструментов

В марте 2025 года исследователи Pillar Security раскрыли вектор атаки Rules File Backdoor, затрагивающий GitHub Copilot и Cursor [13]. Злоумышленник встраивает скрытые unicode-символы в файлы конфигурации (.cursorrules, .github/copilot-instructions.md), которые ИИ-ассистент читает как инструкции по написанию кода. В результате ассистент начинает генерировать код с уязвимостями или бэкдорами — при этом сгенерированный код выглядит нормально при обычном ревью.

Последствия: утечка API-ключей, логические ошибки в проде, заражение цепочки поставок через форки и зависимости. Когда исследователи сообщили об уязвимости вендорам, ответ был: «это не наша проблема, а ваша» [13].

Файлы правил для ИИ-инструментов в репозитории — это новая attack surface. Скомпрометированный файл правил на GitHub может быть скачан сотнями разработчиков, и каждый их проект становится потенциальной точкой входа.

5. Воспроизведение уязвимостей из контекста

Исследование Snyk показало: если разработчик добавил в соседний файл уязвимый код (даже по невнимательности), Copilot, используя этот код как контекст, с высокой вероятностью воспроизведёт ту же уязвимость в новом фрагменте [14]. Это означает, что ошибки в кодовой базе могут распространяться не постепенно — а скачкообразно.

Что говорят регуляторы и стандарты

NIST SSDF v1.2 и SP 800-218A

В декабре 2025 года NIST выпустил первый публичный черновик SSDF версии 1.2 (SP 800-218r1), включающий обновлённые практики для современной разработки [15]. Параллельно действует SP 800-218A — SSDF Community Profile специально для генеративного ИИ [16].

NIST SP 1800-44A (июль 2025) прямо указывает: команды должны идентифицировать, где в исходном коде используется ИИ, — включая код от сторонних моделей и агентов, — и обеспечивать верификацию и мониторинг ИИ-генерированного контента человеком [17].

ANSSI + BSI: совместные рекомендации

В октябре 2024 года французское агентство ANSSI и немецкий BSI опубликовали совместный документ с рекомендациями по безопасному использованию ИИ-ассистентов в разработке [9].

Ключевые тезисы документа:

• ИИ-ассистенты не заменяют опытных разработчиков; неограниченное использование инструментов несёт риски.
• Перед внедрением необходимо провести систематический анализ рисков, включая оценку надёжности провайдера и привлечённых третьих сторон.
• Генерированный контент должен быть проверен и понят разработчиком; «деконструкция» AI-кода в публичных ревью внутри компании помогает распространять знания и опыт.
• Прирост производительности должен сопровождаться соразмерным масштабированием мер безопасности.

OpenSSF: инструкции для ИИ-ассистентов

Open Source Security Foundation опубликовал руководство по написанию security-focused инструкций для ИИ-ассистентов [18]. Основная идея: если в системных инструкциях явно задать требования по безопасности (OWASP Top 10, SAFECode, запрет на hardcoded secrets, обязательная обработка ошибок), ассистент будет генерировать более безопасный код. Инструкции можно сохранить в .cursorrules, .github/copilot-instructions.md или аналогичных файлах конфигурации проекта.

Практическое руководство: как организовать безопасный AI-assisted workflow

Шаг 1. Определите политику допустимого использования

Прежде всего команда должна зафиксировать письменно:

• Какие ИИ-инструменты разрешены и на каких тарифах (облачный vs. on-prem, корпоративный договор с запретом обучения на коде vs. личный аккаунт).
• В каких зонах кодовой базы использование ИИ ограничено или запрещено. Wiz рекомендует минимум: запретить ИИ в аутентификации, авторизации, криптографии и регуляторной логике; разрешить для boilerplate, internal tooling и scaffolding [4].
• Как маркируется ИИ-генерированный код в репозитории — хотя бы на уровне комментария или поля в PR-шаблоне.

Checkmarx в своём CISO-руководстве 2025 года указывает: «AI-кодинг сегодня — это новый Shadow IT». Инструменты используются — с разрешения или без, с достаточным контролем или без него [19].

Шаг 2. Настройте security-инструкции для ИИ-ассистента

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

• Следовать OWASP Top 10; никогда не отключать XML entity security, type checking при десериализации.
• Никогда не хардкодить секреты, ключи, токены — использовать переменные окружения или secrets manager.
• Обязательная обработка ошибок; не логировать чувствительные данные.
• При использовании сторонних библиотек — только существующие, активно поддерживаемые пакеты с известными версиями.
• Добавлять TODO-комментарии для мест, требующих security-ревью.

Такие инструкции не заменяют проверки и не гарантируют безопасного кода — разработчик может переопределить любое предложение, — но они снижают процент небезопасных suggestions [18].

При этом файлы конфигурации ИИ-инструментов в репозитории сами нуждаются в защите. Правило: конфиг ИИ-ассистента — часть кодовой базы. Ревью .cursorrules и аналогичных файлов обязательно. Никаких файлов правил из непроверенных источников [13].

Шаг 3. Проверяйте зависимости отдельно и всегда

Каждую зависимость, предложенную ИИ, нужно верифицировать вручную:

• Пакет существует? Поиск в реестре (PyPI, npm, crates.io).
• Пакет активно поддерживается? Дата последнего коммита, количество мейнтейнеров.
• Нет известных уязвимостей? Проверка через OSV, Snyk Advisor, NIST NVD.
• Версия зафиксирована в lock-файле? Никаких плавающих версий в production.
• SBOM (Software Bill of Materials) генерируется в CI/CD? Это один из ключевых элементов контроля supply chain.

Никогда нельзя предполагать, что пакет, упомянутый ИИ, существует и безопасен. Из-за slopsquatting одно автоматическое pip install по совету ИИ может закончиться выполнением произвольного кода в сборке [12].

Шаг 4. Выстройте security gate на уровне PR

Pull request — критическая точка, где ИИ-генерированный код переходит в общую кодовую базу. Именно здесь уязвимость либо останавливается, либо наследуется всеми.

Минимальный чек-лист при ревью PR с ИИ-кодом:

1. Все зависимости проверены вручную — не предполагаем, что ИИ знает актуальные версии.
2. Нет хардкоженных секретов, ключей, токенов, URL с credentials.
3. Sensitive-зоны (auth, крипто, миграции БД) отрецензированы human reviewer, не только автоматикой.
4. SAST-инструмент прошёл без critical/high-severity findings.
5. Файлы конфигурации ИИ-инструментов не изменялись (или изменения отдельно ревьюнуты).
6. Новые или обновлённые зависимости — с lock-файлом и без known CVE.

OpsMX рекомендует в качестве политики: ни один PR не должен мёрджиться, если он вносит уязвимость critical или high severity. Если ИИ предложил библиотеку с известной RCE-уязвимостью, PR должен упасть автоматически [20].

Стоит добавить в шаблон PR отдельный раздел: использовался ли ИИ, какие находки были, как они были устранены или задокументированы [21]. Это не бюрократия — это аудитабельность.

Именно здесь инструменты вроде HighVibe могут стать практичным дополнением к существующим SAST/SCA. HighVibe анализирует конкретное изменение в PR — код, конфиги, зависимости — и даёт короткий сигнал: можно ли принять это изменение сейчас, что критично, что можно исправить. Без длинного отчёта, без вала ложных срабатываний: команда видит конкретный следующий шаг перед merge.

Шаг 5. Не игнорируйте служебный код

Конфигурационные файлы, CI/CD-пайплайны, миграции баз данных, internal tools — именно их читают хуже всего при ревью. Между тем именно здесь ИИ нередко предлагает отладочные настройки с широкими правами, незакрытые CORS-заголовки, debug-флаги, которые не предназначены для production.

Правило: любое изменение в .github/workflows/, Dockerfile, terraform/, миграционных файлах с ИИ-участием требует отдельного, осознанного ревью — не быстрого глаза.

Шаг 6. Выстройте release gate

Перед релизом нужен короткий ответ на вопрос: что именно блокирует выпуск, — а не ещё один длинный security-отчёт. SBOM для релиза должен генерироваться автоматически. Новые зависимости, добавленные с момента предыдущего релиза, — отдельный пункт чек-листа. Секреты в конфигах релизного окружения — отдельная проверка.

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

Типичные ошибки команд

"Работает — значит безопасно"

Самая опасная ошибка. Функциональность и безопасность — разные свойства кода. ИИ оптимизирует первое и не гарантирует второе. Рабочий PR не равен безопасному PR [18].

Полное доверие к ИИ-ревью

Ряд инструментов позиционирует ИИ как ревьювера кода. Это полезно — но не замена human review в критических зонах. Контекстно-зависимые уязвимости (проблемы авторизации между микросервисами, бизнес-логика, архитектурные решения) ИИ часто не замечает [22].

Отсутствие политики для junior-разработчиков

Исследование Snyk зафиксировало: разработчики без опыта, полагающиеся на ИИ-ассистентов, нередко не осознают допущенных ошибок — потому что предполагают, что ИИ автоматически пишет безопасный код [14]. Это экспоненциально увеличивает риск.

Игнорирование конфигурационных файлов ИИ-инструментов

После раскрытия Rules File Backdoor стало ясно: .cursorrules, .github/copilot-instructions.md и аналогичные файлы — часть attack surface [13]. Они должны ревьюиться как код.

Shadow AI в команде

По данным Checkmarx, ИИ-инструменты используются во многих командах без официального одобрения и без policy [19]. Отсутствие политики не означает отсутствие рисков — оно означает неуправляемые риски.

Кейс: как один PR разрушил цепочку поставок

В августе 2025 года ИИ-генерированный PR в сборочный инструмент NX ввёл уязвимость command injection: заголовок PR использовался напрямую в shell-командах без санитизации. Это позволило атакующему похитить NPM publishing tokens. Скомпрометированное обновление затронуло более 1 400 разработчиков [23].

Механизм типичен: ИИ написал функционально работающий код. Reviewer не заметил уязвимость в безобидном на вид фрагменте. Уязвимость попала в опубликованный пакет — и дальше к тысячам пользователей.

Вывод не в том, что ИИ плохой инструмент. Вывод в том, что у команды не было gate перед merge, который бы заметил проблему.

Тренды и будущее (с оговорками)

Исследование Veracode 2025 года показало: увеличение размера модели (от <20B до >100B параметров) практически не влияет на безопасность генерируемого кода. Исключение — GPT-5, однако тренд в целом не радует: нельзя просто ждать, что следующая версия ИИ «починит» проблему безопасности [5].

Зато разворачиваются несколько значимых сдвигов:

• Появляются контекстно-зависимые инструменты анализа, которые понимают граф вызовов, уровни привилегий, потоки данных — и выдают меньше ложных тревог, чем правило-ориентированные SAST [22].
• OpenAI в октябре 2025 года интегрировал агентный code reviewer в собственный инженерный workflow — инструмент обрабатывал более 100 000 внешних PR в сутки [23].
• NIST продолжает обновлять SSDF с учётом генеративного ИИ [15], а ANSSI и BSI сигнализируют: регуляторный фон будет ужесточаться.
• Будущий AI EU Act добавит требования к прозрачности AI-assisted разработки для ряда категорий ПО.

Что точно: организации, которые выигрывают, — это те, кто строит безопасность вокруг AI-assisted workflow, а не пытается приклеить её сверху после факта.

Заключение: что делать прямо сейчас

ИИ в разработке — не временный тренд и не эксперимент. Это текущая реальность для большинства инженерных команд. Вопрос не «использовать или нет», а «как контролировать».

Конкретный план действий для команды:

1. Принять политику допустимого использования ИИ-инструментов: разрешённые сервисы, запретные зоны кода, требования к тарифам.
2. Добавить security-инструкции в конфигурацию ИИ-ассистентов и поставить эти файлы под обязательный ревью.
3. Встроить в CI/CD: SAST, SCA для зависимостей, secrets detection, генерацию SBOM.
4. Обновить шаблон PR: маркировка ИИ-участия, чек-лист по зависимостям и секретам.
5. Определить mandatory human review для критических зон: auth, крипто, миграции, CI/CD-файлы.
6. Сформулировать release gate: что блокирует выпуск, что нужно проверить перед деплоем.

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

Источники

[1] Stack Overflow — "Stack Overflow Developer Survey 2024" — https://survey.stackoverflow.co/2024/

[2] Built In — "Why AI Coding Tools Are Your Security Team's Worst Nightmare" — https://builtin.com/articles/ai-coding-tools-security-risks

[3] Kusari — "AI Coding Assistants in 2026: 4× Faster, 10× Riskier" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost

[4] Wiz — "AI Code Security Explained" — https://www.wiz.io/academy/application-security/ai-code-security

[5] Хабр / RuVDS — "Ваш ИИ ошибался, ошибается и будет ошибаться" — https://habr.com/ru/companies/ruvds/articles/1031104/

[6] Endor Labs / SDCE — "The Hidden Dependency Risk of AI-Written Code" — https://www.sdcexec.com/software-technology/ai-ar/article/22959921/endor-labs-the-hidden-dependency-risk-of-aiwritten-code

[7] Hostpro — "Этические дилеммы ИИ в веб-разработке: кто отвечает за баг, найденный Copilot?" — https://hostpro.by/blog/eticheskie-dilemmy-ii-v-veb-razrabotke-kto-otvechaet-za-bag-najdennyj-copilot

[8] StackHawk — "AI Security Best Practices: A Developer's Guide" — https://www.stackhawk.com/blog/ai-security-best-practices/

[9] ANSSI + BSI — "AI Coding Assistants" (joint report, October 2024) — https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/ANSSI_BSI_AI_Coding_Assistants.pdf

[10] tproger.ru — "GitHub Copilot обучается на вашем коде: как сделать opt-out" — https://tproger.ru/news/github-copilot-s-24-aprelya-obuchaetsya-na-vawem-kode-po-umolchaniyu

[11] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[12] ActiveState — "Is AI-Generated Code Poisoning Your Software Supply Chain?" — https://www.activestate.com/blog/is-ai-generated-code-poisoning-your-software-supply-chain/

[13] Хабр / Raft — "Rules File Backdoor. Как атакуют GitHub Copilot и Cursor" — https://habr.com/ru/companies/raft/articles/953232/

[14] SecurityLab.ru — "Snyk: ИИ-помощник GitHub Copilot может тиражировать ошибки в коде" — https://www.securitylab.ru/news/546380.php

[15] NIST — "Secure Software Development Framework (SSDF) Version 1.2 is Available for Public Comment" — https://www.nist.gov/news-events/news/2025/12/secure-software-development-framework-ssdf-version-12-available-public

[16] NIST CSRC — "SP 800-218A: Secure Software Development Practices for Generative AI" — https://csrc.nist.gov/pubs/sp/800/218/a/final

[17] NIST NCCoE — "SP 1800-44A: Secure Software Development" — https://www.nccoe.nist.gov/sites/default/files/2025-07/nist-sp-1800-44a-ipd.pdf

[18] OpenSSF — "Security-Focused Guide for AI Code Assistant Instructions" — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html

[19] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

[20] OpsMX — "AI-Generated Code Security Checklist: 7 Policies for CISOs" — https://www.opsmx.com/blog/ai-generated-code-security-checklist-7-policies-every-ciso-needs/

[21] DEV Community — "The AI Code Review Checklist: A Copy-Paste Prompt for Safer Pull Requests" — https://dev.to/suifeng023/the-ai-code-review-checklist-a-copy-paste-prompt-for-safer-pull-requests-3e58

[22] Augment Code — "AI Code Security: Essential Risks and Best Practices" — https://www.augmentcode.com/guides/ai-code-security-essential-risks-and-best-practices

[23] ClackyAI — "Code Review Checklist for AI-Generated Code" — https://clacky.ai/blog/code-review-checklist-ai-generated-code