Отягощённое интеллектом. Сложности испытательной лаборатории при оценке защищённости программного обеспечения, разработанного с использованием ИИ

Отягощённое интеллектом. Сложности испытательной лаборатории при оценке защищённости программного обеспечения, разработанного с использованием ИИ

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

Введение

Сегодня практика разработки стремительно меняется под влиянием ИИ-ассистентов и распространения вайбкодинга. По данным исследования «Т-технологий» [1], 58% опрошенных инженеров уже пишут код с использованием ИИ, а доля такого кода в крупных организациях достигает 20–30% от общего объёма. Число пользователей одного лишь GitHub Copilot превысило 26 миллионов. Практическое подтверждение связанных с этим рисков даёт исследование компании Escape.tech, проанализировавшей свыше 1400 продакшн-приложений, созданных преимущественно с помощью ИИ, в котором 65% приложений содержали проблемы безопасности, 58% — ​как минимум одну критичную уязвимость, а в совокупности было обнаружено более 400 раскрытых секретов и 175 случаев раскрытия персональных данных [2].

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

Поиск секретов в исходном коде

Поиск секретов представляет собой вид работ, направленный на выявление в исходном коде и истории коммитов «хардкоженных» учётных данных, ключей доступа к API, токенов и паролей, как правило, с использованием сигнатурного и энтропийного анализа строк средствами наподобие gitleaks или TruffleHog.

Использование ИИ увеличивает количество секретов в коде по двум независимым причинам. Во-первых, языковая модель способна воспроизводить реальные учётные данные, встреченные в обучающей выборке. Так, 1/3 предложений автодополнения GitHub Copilot содержала валидные по формальным признакам секреты, часть из которых оказалась действующими ключами доступа [3]. Во-вторых, при генерации примеров конфигурации или кода подключения к внешним сервисам модель по умолчанию склонна подставлять значение секрета непосредственно в код, а не использовать переменные окружения или менеджер секретов, поскольку такой упрощённый вариант чаще встречается в обучающих данных, и не предлагает более безопасную альтернативу, если разработчик не запросил её явно.

Совокупный эффект этих механизмов подтверждается отраслевой статистикой. Репозитории с включённым Copilot содержат утечки секретов с частотой 6,4% против 4,6% в среднем по всем публичным репозиториям, а частота утечек в коммитах с участием ИИ примерно вдвое выше базовой: 3,2% против 1,5% [4]. Отдельно отмечен рост на 81% за год числа утечек ключей доступа к самим ИИ-сервисам, а в конфигурационных файлах для протокола MCP обнаружено свыше 24 тысяч уникальных секретов, из которых более двух тысяч оказались действующими.

Для испытательной лаборатории данная динамика не меняет принципиальную работоспособность инструментов поиска секретов, поскольку хардкоженная строка обнаруживается независимо от того, кто её написал. Сложность заключается в ином. Резко растёт объём находок, подлежащих ручному триажу при том же согласованном бюджете времени, а появление новых типов секретов, в первую очередь ключей ИИ-сервисов и конфигураций MCP, требует отдельного расширения используемых сигнатур детектора, поскольку данные форматы могут не входить в стандартный набор правил на момент его последнего обновления.

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

Статический анализ исходного кода (SAST) представляет собой вид работ, направленный на поиск дефектов в коде без его фактического выполнения, включая поиск небезопасных конструкций, таких как SQL-инъекции, межсайтовый скриптинг, небезопасная десериализация и слабая криптография, по заранее определённым правилам.

В исследовании [5], охватившем свыше ста языковых моделей и более восьмидесяти тестовых задач на языках Java, Python, C# и JavaScript, при выборе между безопасным и небезопасным способом реализации функции модель в среднем выбирала небезопасный вариант почти в половине случаев, критичные недостатки были выявлены в 45% протестированных случаев. Наиболее уязвимым языком оказалась Java с долей неудачных проверок свыше 70%, а для межсайтового скриптинга доля неудачных проверок достигла 86%, что примерно в 2,74 раза выше частоты аналогичного недостатка в коде, написанном человеком. Существенно, что отчёт не выявил связи между размером и датой выпуска модели и качеством генерируемого кода с точки зрения безопасности, а обновление отчёта весной 2026 года подтвердило, что доля успешных проверок остаётся на стабильном уровне около 55%, то есть проблема носит структурный, а не временный характер.

Для испытательной лаборатории конкретный небезопасный паттерн остаётся тем же самым паттерном независимо от того, кем он написан, и обнаруживается тем же набором правил SAST. Сложность здесь схожа с описанной для поиска секретов: объём находок на тот же объём кода заметно растёт, что увеличивает трудозатраты на присвоение критичности и подготовку описания каждой находки с указанием Common Weakness Enumeration (CWE), класса типовых дефектов безопасности. Дополнительно проявляется системный характер предпочтений модели: конкретные классы уязвимостей повторяются с высокой и предсказуемой частотой, что в перспективе может использоваться для приоритизации правил анализа, однако требует целенаправленного пересмотра используемого набора сигнатур.

Композиционный анализ

Композиционный анализ (SCA) представляет собой вид работ, основанный на формировании перечня зависимостей программного обеспечения и выявлении в них известных уязвимостей и иных недостатков, как правило на основе SBOM-файла и сверки его содержимого с базами данных уязвимостей.

Использование ИИ формирует для данного вида проверки риск, не сводящийся к уязвимостям в существующих компонентах. Явление, получившее название slopsquatting, состоит в том, что модель при генерации кода предлагает правдоподобное, но несуществующее имя пакета (см. рис. 1).

Рисунок 1. Схема атаки slopsquatting

Злоумышленник, заранее зарегистрировавший такое имя с вредоносным содержимым, получает возможность скомпрометировать проект в момент установки зависимости. Согласно исследованию [6] на выборке из 576 тысяч фрагментов кода на Python и JavaScript, сгенерированных шестнадцатью распространёнными моделями, частота галлюцинированных зависимостей сильно различалась между моделями, от менее 5% у GPT‑4 и GPT‑4 Turbo до более 15% у DeepSeek и свыше 25% у Code Llama 7B, при этом код на JavaScript содержал вымышленные зависимости заметно чаще, чем код на Python (21% против 16%). Отдельного внимания заслуживает воспроизводимость эффекта: при повторной генерации одного и того же запроса 43% галлюцинированных названий повторялись при каждом из десяти прогонов, что делает такие названия предсказуемыми и пригодными для целенаправленной регистрации злоумышленником заранее.

Отдельно от галлюцинации названий существует смежная проблема, при которой модель рекомендует реально существующий, но устаревший или уязвимый пакет. Знания модели ограничены датой отсечения обучающих данных, поэтому она не осведомлена об уязвимостях, опубликованных позднее, и продолжает предлагать версию, для которой уже вышел патч. При этом выбор смещён в худшую сторону: среди уязвимых версий, рекомендованных моделями, критичные и высокие по опасности типовые уязвимости (Common Vulnerabilities and Exposures, CVE) составляют 63–75%, тогда как в общем массиве известных уязвимостей их доля около 29% [7].

Для испытательной лаборатории риск галлюцинации названий затрагивает саму методологическую основу композиционного анализа. Инструменты, такие как OWASP Dependency Track, Trivy, Grype и другие, сверяют состав всех компонентов (пакетов, библиотек), используемых в разрабатываемом ПО или необходимых для его работы (Software Bill of Materials, SBOM), с базами данных известных уязвимостей в существующих пакетах, но не отвечают на вопрос, существует ли пакет вообще и заслуживает ли он доверия. Это означает, что типовая методика композиционного анализа должна быть дополнена отдельным шагом верификации фактического существования и репутации каждой зависимости в официальном реестре, чего процесс SCA на основе одного лишь SBOM-файла не предусматривает.

Риск устаревших и уязвимых версий, в отличие от галлюцинации названий, не выходит за рамки классической методики. Инструменты SCA по определению сопоставляют версию пакета с базой известных CVE и обнаружат такую уязвимость тем же способом, что и внесённую человеком. Сложность здесь не методологическая, а связана со смещением распределения находок, поскольку модель непропорционально часто предлагает версии именно с критичными и высокими по степени опасности уязвимостями, что увеличивает долю находок, требующих немедленной эскалации, и соответствующую нагрузку на приоритизацию в рамках уже упомянутого возросшего общего объёма.

Обобщённая картина по трём рассмотренным видам проверок представлена в таблице 1.

Таблица 1

Направления снижения рисков

Рассмотренные сложности не означают неприменимость ИИ при разработке. Они лишь демонстрируют, что такое использование должно сопровождаться дополнительными мерами контроля.

Со стороны разработки должна проводиться обязательная верификация сгенерированного кода. На практике она сводится к применению взаимодополняющих мер из лучших практик жизненного цикла разработки безопасного ПО (Secure Software Development Life Cycle, SSDLC): безопасному хранению секретов в специализированных решениях и переменных окружения вместо их размещения в коде, проверке каждой предложенной моделью зависимости на факт существования и репутацию до установки, встраиванию инструментов сканирования секретов и композиционного анализа в конвейер Continuous Integration/Continuous Delivery/Deployment (CI/CD), следованию правилам безопасного кодирования [8] и многому другому. Важным элементом цикла безопасной разработки ПО остаётся и динамический анализ кода, в том числе фаззинг-тестирование, позволяющее выявлять уязвимости, недоступные статическим методам [9].

Со стороны проверяющего адаптация методики сводится к нескольким направлениям. Во-первых, это регулярное расширение набора используемого инструментария, а также сигнатур детекторов под новые типы потенциальных проблем безопасности. Во-вторых, дополнение методики композиционного анализа шагом верификации существования и репутации зависимостей. В-третьих, приоритизация правил статического анализа с учётом предсказуемо повторяющихся классов уязвимостей и обоснованный выбор инструментов под конкретную задачу. Также немаловажно закладывать дополнительное время триажа с поправкой на возросший объём находок.

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

Заключение

Использование искусственного интеллекта разработчиком отражается на всех трёх рассмотренных видах проверок, но не одинаковым образом. Общий вывод состоит в том, что рост доли ИИ-сгенерированного кода не снижает применимость инструментария испытательной лаборатории, но существенно увеличивает нагрузку на неё и обнажает пробелы в методике, изначально рассчитанной на код, написанный человеком. Дальнейшая работа в этом направлении может быть связана с обновлением типовых программ и методик испытаний с явным учётом рассмотренных рисков.

[1] https://www.vedomosti.ru/technologies/industries_and_markets/articles/2026/06/30/1210109-rinok-ii

[2] https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/

[3] Your Code Secret Belongs to Me: Neural Code Completion Tools Can Memorize Hard-Coded Credentials. Y Huang, Y Li, W Wu, J Zhang, MR Lyu. Proceedings of the ACM on Software Engineering, 2024

[4] https://www.gitguardian.com/state-of-secrets-sprawl-report‑2026

[5] https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/

[6] Spracklen J., Wijewickrama R., Sakib A. H. M. N., Maiti A., Viswanath B., Jadliwala M. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs // Proceedings of the USENIX Security Symposium. 2025. arXiv:2406.10279

[7] Wang C. et al. Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM Specified Library Versions. 2026. arXiv:2605.06279

[8] Как избежать ошибок при безопасной разработке программного обеспечения / В. В. Вареница, А. С. Марков, В. Л. Цирлов и др. — ​М.: Квантмедиа, 2025. — 344 с. EDN: ZFHEHG

[9] Арустамян С. С., Антипов И. С. Интеллектуальные методы фаззинг-тестирования в рамках цикла безопасной разработки программ.