Что меняется в профиле риска
Генерация кода моделью — не то же самое, что написание человеком, и не «просто автоматизация». Три сдвига. Первый: объём. Скорость производства кода растёт, а пропускная способность код-ревью — нет; разрыв давит на качество и рождает соблазн пропустить проверки. Второй: происхождение. Модель обучена на миллионах репозиториев; её ответ — сплав чужих решений, иногда с уязвимыми паттернами прошлых лет, иногда с защищёнными фрагментами. Третий: канал данных. Репозиторий, открытый в ассистенте, — это передача исходников во внешний контур со всеми вопросами конфиденциальности.
Отдельно зафиксируем границу: эта страница — про безопасность процесса разработки с ИИ, а не про услугу разработки ИИ-приложений; коммерческая линейка — на странице разработки ИИ-приложений.
Четыре класса рисков
Уязвимые паттерны. Модель уверенно воспроизводит и устаревшие практики: склейка SQL-запросов, слабая валидация входных данных, самодельная криптография, обработка ошибок с раскрытием деталей. Статистика багов смещается: меньше опечаток, больше логических дыр, которые линтер не видит.
Секреты в коде. Разработчик просит ассистента «подключиться к базе» — и модель предлагает код с ключом прямо в тексте, а человек вставляет его вместе с настоящим секретом. Промпты сами становятся каналом утечки: вставленный в чат фрагмент с токеном уходит в логи сервиса.
Лицензионная неопределённость. Сгенерированный фрагмент может воспроизводить код с копилефт-лицензией. Юридический статус «похожего на чужое» кода не всегда ясен, а процессы комплаенса ПО к генерациям часто не применяют: крупные совпадения стоит проверять инструментами обнаружения дубликатов.
Конфиденциальность исходников. Индексация репозиториев, облачные режимы по умолчанию, расширения с доступом к файлам — исходный код утекает так же, как документы через чаты, только с последствиями для интеллектуальной собственности. Общая механика канала разобрана в материале об утечках через публичные нейросети.
Контур мер: SSDLC с ассистентами
Защита строится не запрета ради, а как обновлённый безопасный цикл разработки.
- Классификация репозиториев. Публичные, внутренние, содержащие секреты или критичную логику — для каждого класса свои правила работы с ассистентами. Всё критичное — только в контуре с выключенным обучением и без внешней индексации.
- Политика ассистентов. Список разрешённых инструментов, корпоративные аккаунты, обязательные настройки приватности. Как это выглядит для конкретных продуктов — в разборах GitHub Copilot в компании, Cursor в корпоративной разработке и Claude Code.
- Автоматические проверки на входе. Секреты — сканерами перед коммитом; уязвимости — SAST/DAST в пайплайне. ИИ-код проходит те же ворота, что и человеческий, без скидок на скорость.
- Код-ревью с повышенным вниманием. Ревью остаётся обязательным; на ассистентский код смотрят с приоритетом на логику ввода-вывода, права доступа и обработку ошибок — там, где модели ошибаются системно.
- Обучение команд. Практические правила: не вставлять секреты в промпты, проверять зависимости, помечать сгенерированные фрагменты в ревью. Основа — общий регламент использования LLM, дополненный приложением для разработчиков.
Приоритеты устранения находок
Когда SAST находит проблему в сгенерированном коде, работает общий приоритет серьёзности: критические уязвимости закрываются первыми. Ориентир задают и регуляторные требования: ФСТЭК России в 2025 году определил срок устранения критических уязвимостей — 24 часа. Планировать пайплайн стоит так, чтобы критические находки останавливали сборку, а не копились в бэклоге.
Метрики зрелости
Три вопроса для самооценки команды. Какая доля кода ассистируется — и знаем ли мы её вообще? Проходит ли сгенерированный код те же проверки, что и написанный руками? Уверены ли мы, что секреты не покидают контур через промпты? Ответы «не знаем / нет / не уверены» — это и есть план работ на квартал. Быструю самопроверку контура компании в целом даёт тест зрелости защиты ИИ.
Как управлять долей ассистированного кода
Слепое разрешение и слепой запрет одинаково слабы: в первом случае компания не знает, что и насколько генерируется, во втором — теряет скорость и выталкивает команды в тень. Рабочая модель — измерение и границы. Команды помечают значимые сгенерированные фрагменты, метрика доли ассистированных изменений попадает в дашборд рядом с плотностью находок сканеров. Для критичных модулей — свои правила: повышенное ревью, запрет автономных правок, обязательные тесты. Для остального — общие ворота качества. Такая конструкция превращает вопрос «разрешать ли ИИ в коде» в управляемый диапазон, а не бинарную веру, и даёт руководству язык для обсуждения рисков без программистского жаргона.
Короткий финальный тест для любой команды: назовите три механизма, которые остановят утечку секрета через ассистента, уязвимый паттерн в сгенерированном коде и сомнительную зависимость. Если механизмы называются с порога — контур собран; если ответы размыты — перед вами дорожная карта на ближайший квартал, и лучше пройти её до того, как её пройдёт атакующий.