Привет, Хабр! Меня зовут Дмитрий Бахтенков. С 2020 я занимаюсь коммерческой разработкой на .NET, а также пишу для медиа «вАЙТИ». В сфере информационной безопасности существует множество уязвимостей, и разработчикам сложно понять, какие из них важнее учитывать при обучении или отладке процессов безопасной разработки.
Часть этой неопределенности снимает OWASP — организация, которая системно исследует безопасность приложений и формирует наиболее значимые категории рисков. Их проект OWASP Top Ten — это ориентир для индустрии: список наиболее критичных уязвимостей, на которые стоит обращать внимание в первую очередь.
В 2025 году опубликована новая версия рейтинга (пока в статусе Release Candidate), и я предлагаю рассмотреть ключевые изменения, причины их появления и то, как компании могут адаптировать свои процессы для уменьшения рисков.
OWASP (Open Web Application Security Project) — это независимая некоммерческая организация, цель которой — повышение безопасности программного обеспечения. OWASP разрабатывает открытые стандарты, руководства и инструменты для разработчиков, архитекторов и специалистов по ИБ по всему миру. Наиболее известный проект — Top Ten — определяет самые критичные риски безопасности веб-приложений.
Проект Top Ten
Проект OWASP Top Ten — это список наиболее распространенных уязвимостей, ранжированных по частоте и критичности. Он служит базой для обучения разработчиков безопасной разработке и проведения аудитов. Обычно выпуск происходит раз в несколько лет: последний был за 2021 год, а сейчас опубликован Release Candidate Top Ten 2025.
Обзор изменений и новых категорий
В 2025 году OWASP Top Ten представляет следующий рейтинг:
Broken Access Control (нет изменений).
Security Misconfiguration (поднялась с 5-го места на 2-е).
Supply Chain Failures (что-то новое!).
Cryptographic Failures (упала со 2-го места).
Injection (упала с 3-го места).
Insecure Design (упала с 4-го места).
Authentication Failures (нет изменений).
Software and Data Integrity Failures (нет изменений).
Logging And Alerting Failures (изменилась формулировка: добавился Alerting).
Mishandling of Exceptional Conditions (что-то новое!).
Начнем с новых категорий.
Похожая категория была и раньше: A9: Using Components with Known Vulnerabilities, но теперь ее расширили. Сюда входят:
Использование уязвимых версий библиотек.
Отсутствие сканирования на уязвимости в пайплайнах.
Ошибки CI/CD — от некорректных прав до Cache Poisoning и захватов раннера.
Mishandling of Exceptional Conditions
Эта категория включает в себя некорректную обработку исключений и ошибок, логические ошибки и прочие сложности кода, в котором есть проблемы с качеством.
Такие уязвимости могут привести как к отказу сервиса (DoS), так и к порче или краже данных, проблемам с авторизацией из-за Race Conditions и т. д.
Почему именно так?
OWASP не заявляет прямой связи изменений с ИИ, но мне кажется, что подобное содержание рейтинга является прямым следствием повсеместного внедрения LLM в процессы разработки. Причем дело не только во внедрении, но и в излишнем доверии этому инструменту.
Если явно не говорить LLM о безопасности, она будет генерировать код, который просто работает. Контроль доступа, корректные настройки и другие нефункциональные требования в такой модели оказываются вторичными. Именно поэтому в верхней части топа находятся Security Misconfiguration и Broken Access Control.
При этом уязвимости, связанные с криптографией и инъекциями, сместились ниже. Современные фреймворки и библиотеки берут на себя большую часть сложности этих областей и предлагают безопасные механизмы «по умолчанию». В результате количество подобных ошибок растет медленнее по сравнению с теми, что связаны с архитектурой, конфигурацией и интеграцией компонентов.
Новые категории — атаки на цепочку поставок и некорректная обработка ошибок — напрямую связаны с галлюцинациями ИИ. LLM склонны придумывать корректно выглядящий, но концептуально неверный код, зависимости и архитектурные решения. У меня был кейс, когда в приложении на .NET Codex сгенерировал использование одного экземпляра DbContext в многопоточном контексте, что привело к поломке бизнес-логики уже на этапе интеграционных тестов. Если бы тестов не было, результатом стало бы повреждение данных в продакшене!
Проблема здесь в том, что ИИ не обладает глубоким пониманием технологических ограничений, если они явно не заданы в контексте. Он не делает выводов о потокобезопасности, жизненном цикле объектов или особенностях фреймворков — отсюда ошибки в многопоточности, управлении состоянием, обработке исключений и, как следствие, рост системных уязвимостей.
Новые векторы атак
Слоупсквоттинг
ИИ часто генерирует несуществующие библиотеки. А еще эти названия довольно часто повторяются…
Далее хакеры выясняют названия этих библиотек и добавляют их в Package Registry. Ничего не подозревающие разработчики получают библиотеку, которая выглядит правдоподобно, а внутри содержит malware. Эту концепцию подмены библиотек исследователи ИБ назвали слоупсквоттинг.
Как избежать?
Используйте свои Package Registry — это наиболее надежный способ защититься от подмены пакетов.
Верифицируйте устанавливаемые библиотеки и их зависимости: количество звезд на GitHub, дата публикации и т. д.
Prompt Injection
Когда ИИ не только используется как инструмент разработки, но и интегрируется в само приложение, появляется новый класс атак — Prompt Injection. В этом случае злоумышленник воздействует не на код напрямую, а на контекст, в котором работает модель.
Простейший пример — подмена или расширение пользовательского ввода таким образом, чтобы ИИ начал выполнять нежелательные инструкции: игнорировать бизнес-правила, раскрывать внутренние данные или принимать решения в пользу атакующего. В коммерческих сценариях это может выглядеть как попытка получить более выгодное торговое предложение, обойти ограничения или повлиять на логику рекомендаций.
Best practices для ИИ в компаниях
При внедрении LLM в процессы коммерческой разработки важно минимизировать риски безопасности. Для этого нужно проработать два направления: процессы и технологии.
Процессные изменения
Внедрение обязательного код-ревью, особенно для сгенерированного кода.
Определите общий набор инструментов для компании и используйте Team-подписки для мониторинга, ограничений доступов и аналитики использования.
Настройка Content Exclusion для конкретной утилиты, например GitHub Copilot. Нужно исключить env, appsettings и другие настройки, которые могут содержать секреты.
Внутреннее обучение промпт-инжинирингу.
Технологические изменения
Внедрение статического анализа кода, например SonarQube.
Настройка своего Registry для библиотек: Artifactory, Nexus и т. д.
Вывод
Новый рейтинг OWASP хорошо иллюстрирует, как изменилась природа проблем безопасности. Сегодня они реже связаны с отсутствием фреймворков и библиотек: большая часть технической сложности инкапсулирована на уровне платформ. Зато на первый план выходят более простые вещи: обработка ошибок, понимание используемых технологий и осознанное отношение к стороннему коду, в том числе и сгенерированному.
Я сам активно использую GitHub Copilot и вижу в ИИ большую ценность для разработки. Но важно помнить, что ИИ остается инструментом. Однако ответственность за код — на живых людях, и именно инженерные решения, процессы и ревью по-прежнему определяют, будет ли система безопасной.
вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение.
Больше статьей по теме #Инфобез
Что важно знать специалисту по цифровой трансформации об управлении рисками
Три самых острых камня, которые тормозят внедрение новых технологий
Атаки через удаленные подключения подрядчиков. Как защищаться?
Что делать, чтобы злоумышленники не могли подключиться к вашей инфраструктуре через доверенных партнеров
Как разработчику защитить биометрию пользователей: принципы Privacy-by-Design
Как проектировать биометрические системы с защитой от утечек
Роль человеческого фактора в безопасности облачных систем
Ситуации из практики, которые показывают, как поведение пользователей может свести на нет любые меры безопасности