Привет, Хабр! Меня зовут Дмитрий Бахтенков. С 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
Как проектировать биометрические системы с защитой от утечек
Роль человеческого фактора в безопасности облачных систем
Ситуации из практики, которые показывают, как поведение пользователей может свести на нет любые меры безопасности
