Т1 Иннотех о том, кто отвечает за уязвимости, когда код помогает писать ИИ
Максим Щедрин, начальник Управления тестирования безопасности Т1 Иннотех, объясняет, почему проверок перед релизом недостаточно и как встроить безопасность в разработку с ИИ.
Сегодня разработчик может за несколько минут сгенерировать с помощью ИИ готовую функцию, тест или скрипт развертывания. Команды пишут и обновляют код заметно быстрее, и это уже не эксперимент отдельных энтузиастов, а массовая практика: хотя бы один ИИ-инструмент в работе используют больше 80% разработчиков в мире. При этом проверка безопасности часто устроена по-старому: разработчики создают код, а перед выпуском продукта его анализирует служба ИБ. С ростом скорости эта схема работает все хуже, и дело не только в объеме изменений, но и в качестве самого сгенерированного кода.
Код, который генерирует модель, может выглядеть рабочим и даже успешно проходить базовые проверки. Но корректный синтаксис еще не означает, что решение правильно выполняет задачу и безопасно. Модели учатся в том числе на далеко не идеальных примерах, поэтому воспроизводят ошибки и классические уязвимости, например, из списка OWASP Top 10: в тестах на типовых задачах примерно в 44% случаев сгенерированный код содержит уязвимость, и за последний год этот показатель почти не изменился. Кроме того, модель не знает контекста, в котором будет работать код: внутренних требований компании, отраслевых стандартов, требований регуляторов и законодательства. Еще один риск связан с зависимостями. ИИ может посоветовать подключить несуществующую библиотеку. Если разработчик добавит ее в список зависимостей, а злоумышленник успеет опубликовать в публичном реестре вредоносный пакет с таким именем, при установке зависимостей в проект может попасть чужой код.
Проверка перед выпуском помогает найти уязвимости, но при ИИ-разработке она перестает успевать за объемом изменений: модели пишут код в десятки раз быстрее человека. Если вручную проверять только релизы, большая часть кода рискует уйти в продакшн непроверенной и с потенциально большим числом уязвимостей. К тому же базовое правило никуда не делось: чем позже найдена уязвимость, тем дороже ее исправить. К моменту выпуска архитектура определена, сторонние компоненты встроены в продукт, и изменение одного решения может потребовать доработки нескольких частей системы. А когда тщательная проверка все же начинает задерживать релизы, возникает конфликт: бизнесу важно соблюдать сроки, требования ИБ воспринимаются как помеха, и проверки могут свестись к формальности.
Поэтому требования к защите стоит формулировать еще при проектировании архитектуры и постановке задачи, так же как требования к производительности или отказоустойчивости. Еще до начала работы команда выясняет, какие данные будет обрабатывать сервис, кто и с какими правами получит к ним доступ, где будут храниться пароли и ключи доступа и что произойдет, если скомпрометируют внешнюю зависимость или учетную запись подрядчика. Полноценное моделирование угроз требуется не для каждого изменения, а прежде всего для тех, которые существенно влияют на безопасность, например, при добавлении внешнего API, интеграции с партнером или начале работы с персональными данными.
Теперь у этих требований есть еще один адресат — сама модель. Без такой вводной она вполне может, например, записать пароль прямо в исходный код или подставить пользовательские данные в SQL-запрос без безопасной обработки. Значит, в запрос к модели нужно закладывать то же, что и в техническое задание: требования к безопасности, сведения об угрозах, актуальных для сервиса, внутренние правила компании и внешние требования, включая регуляторные. Чем ближе промпт к классическому ТЗ, тем меньше модели приходится додумывать самой.
При этом одних инструкций модели недостаточно. Чтобы, например, конфиденциальные данные не попадали в исходный код, в процесс разработки встраивают защищенное хранилище: приложения и скрипты сборки получают пароли и ключи из него, что снижает риск утечек и несанкционированного доступа к системам.
Для многих организаций эти меры уже не рекомендация, а обязательство. С 1 марта 2026 года действует приказ ФСТЭК России № 117 о защите информации в государственных информационных системах, а также в иных информационных системах госорганов, ГУПов и госучреждений. Если оператор такой системы разрабатывает ПО самостоятельно, он должен реализовать меры из разделов 4 и 5 ГОСТ Р 56939-2024, причем раздел 5 описывает 25 процессов безопасной разработки. Если же к работе привлекают подрядчика, требования к безопасной разработке могут включить в техническое задание по решению руководителя или ответственного лица. Эти требования задают необходимую основу, но сами по себе документы безопасность не гарантируют: важно, какие меры компания применяет и как они работают на практике.
Чтобы этот подход работал, нужно четко распределить ответственность. Использование ИИ ее не снимает, так же, как ее не снимает копирование готового фрагмента кода с чужого сайта. За изменение отвечает разработчик, который отправил его в репозиторий. Перед тем как принять изменение, ревьюер проверяет не только логику кода, но и новые зависимости, права доступа и работу с чувствительными данными, а архитектурные решения остаются за техническим руководителем.
Служба ИБ в такой системе не вычитывает каждую строку. Она задает правила, выбирает и настраивает инструменты контроля и помогает командам в сложных случаях, но не подменяет собой ответственность тех, кто пишет и принимает код. Отдельно определяют, кто в компании вправе принять риск, если продукт выпускают с известной уязвимостью: такое решение согласует уполномоченный руководитель, а причину исключения и срок устранения уязвимости фиксируют.
Со сторонними компонентами разделить ответственность сложнее, ведь одна неудачная библиотека попадает сразу во многие продукты, поэтому здесь нужны единые правила на уровне компании. И риски только растут: к началу 2026 года в проектах с открытым исходным кодом накопилось больше 20 тысяч вредоносных пакетов. Что лучше сделать: зависимости брать из проверенного внутреннего репозитория, фиксировать их версии, автоматически проверять на известные уязвимости и обновлять перечень компонентов (SBOM) при каждой сборке. Тогда при появлении новой уязвимости в популярной библиотеке можно за минуты понять, в каких продуктах она используется. Особого внимания требуют зависимости, предложенные ИИ: прежде чем добавлять их в проект, стоит убедиться, откуда взялся пакет, кто его поддерживает и тот ли это компонент, который нужен.
Проверять каждое изменение вручную при таких объемах не получится. Модель — это алгоритм, который выдает код в огромном объеме, и проверять такой код логично тоже алгоритмически, за счет максимальной автоматизации конвейера разработки. На каждой стадии работают Security Gates — контрольные точки с гибко настраиваемыми, но четкими и однозначными политиками. При каждом изменении автоматически анализируют сам код на типовые уязвимости, проверяют конфигурации и зависимости на соответствие правилам компании, а также ищут в исходниках пароли и ключи доступа, которые должны храниться в защищенном хранилище. Разработчик исправляет проблему, пока задача еще свежа в памяти, и тратит на это минуты, а не возвращается к ней через месяц.
Политики заранее определяют и то, какие находки блокируют сборку: например, конфиденциальные данные в коде или критическая уязвимость в подключенной библиотеке, для которой уже известен способ эксплуатации. Остальные замечания включают в план исправлений с установленными сроками. Правила приходится регулярно пересматривать: если проверки срабатывают на каждую мелочь и часто ошибаются, разработчики быстро привыкают пропускать предупреждения.
Часть рутины можно поручить тому же ИИ — как и в генерации, но уже на приемке: провести первичное ревью изменений, объяснить, чем опасна найденная конструкция, и предложить исправление, оставив решение о принятии изменения за ревьюером. Пентест по-прежнему нужен для критичных систем и крупных изменений: он дополняет встроенные проверки, помогая найти то, что они пропустили, и проверить, можно ли обойти действующие меры защиты.
Об эффективности такого подхода говорят сами цифры: как быстро устраняют уязвимости, повторяются ли одни и те же ошибки и как часто команды запрашивают исключения из правил безопасности. Но главный сдвиг здесь не в метриках, а в ответственности. Модель ускоряет написание кода, однако граница ответственности при этом не двигается: за каждое изменение отвечает тот, кто его написал, принял и выпустил. ИИ — мощный инструмент в руках команды, но не новый владелец этой зоны.
Автор: Максим Щедрин, начальник Управления тестирования безопасности Т1 Иннотех
