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 и вижу в ИИ большую ценность для разработки. Но важно помнить, что ИИ остается инструментом. Однако ответственность за код — на живых людях, и именно инженерные решения, процессы и ревью по-прежнему определяют, будет ли система безопасной.
А еще я веду телеграм-канал Flexible Coding, где делюсь своими инженерными инсайтами. Подписывайтесь, буду рад!
