OWASP Top 10 снова переписали под реальность, в которой код все чаще собирают не руками, а через промпты. В версии 2025 список не просто обновили косметически: на третье место вышли сбои в цепочке поставок ПО, а рядом с основным рейтингом команда отдельно подсветила memory safety и vibe coding как темы, которые уже нельзя считать экзотикой. Для русскоязычной IT-аудитории сигнал простой: проверять теперь нужно не только код, но и весь путь, которым он попал в прод.
Об этом сообщает Stack Overflow Blog в заметке по итогам разговора Райана Донована с Таней Янкой, которая теперь входит в команду OWASP Top 10. Главный сдвиг в новой редакции виден сразу: прежняя категория про уязвимые и устаревшие компоненты из версии 2021 разрослась до более широкой рамки Software Supply Chain Failures. Идея понятна без лишней теории: проблема давно уже не сводится к пакету с известной CVE. Риск теперь лежит во всем контуре зависимостей, сборки и доставки артефактов, включая компрометацию инфраструктуры, подмену пакетов и ошибки доверия к внешним источникам кода.
По данным OWASP, в выпуске 2025 сохранилось 10 категорий, но внутри них многое поменялось. Broken Access Control удержал первое место: в среднем 3,73% протестированных приложений имели хотя бы одну проблему из этой группы, а SSRF в этот раз включили внутрь той же категории. Security Misconfiguration поднялась с пятого места на второе, и это, пожалуй, самый приземленный вывод для любой команды, которая живет в Kubernetes, CI/CD и десятках YAML-файлов: чем больше поведение системы задается конфигами, тем выше шанс, что уязвимость появится не в бизнес-логике, а в криво выставленном флаге. На третьем месте теперь OWASP Top 10 фиксирует именно провалы software supply chain, а не просто старые библиотеки.
Есть и еще один новый пункт: A10 Mishandling of Exceptional Conditions. Это свежая категория, собранная вокруг некорректной обработки ошибок, логических сбоев, fail-open-сценариев и других ситуаций, которые система встречает в ненормальном состоянии. Для разработчика это неприятное, но честное напоминание: инциденты часто начинаются не там, где код делает что-то сложное, а там, где он не понимает, что делать в случае сбоя. Если AI-ассистент быстро нагенерировал happy path, а команда не продумала ветки отказа, OWASP Top 10 прямо говорит, что это уже не мелкая небрежность, а полноправный класс риска.
Отдельно важен способ, которым OWASP пришел к этим выводам. Версия 2025 опирается не только на исторические находки, но и на голосование практиков AppSec. В анализ попали 589 CWE, из которых 248 распределили по десяти категориям. Для расчета использовали почти 175 тысяч записей CVE, связанных с CWE, а набор данных по приложениям вырос до более чем 2,8 млн. Это уже не список «по ощущениям», но и не сухая математика: в OWASP прямо признают, что автоматизированные тесты всегда смотрят в прошлое, а новые классы проблем появляются раньше, чем инструменты учатся их стабильно ловить. Поэтому часть категорий и подсвечивается через опрос сообщества, а не только через голую статистику.
На этом фоне разговор о memory safety и vibe coding звучит не как дань моде, а как попытка заранее встроить новые риски в профессиональную гигиену. В веб-разработке тема memory safety долго казалась чужой территорией из мира системного программирования, но границы давно размылись: веб-стек сидит на нативных рантаймах, расширениях, библиотеках и инфраструктуре, написанной на языках с разной моделью памяти. А vibe coding добавляет другой тип угрозы: код появляется быстрее, чем у команды формируется понимание, что именно сгенерировано, какие зависимости подключены и кто вообще отвечает за безопасность результата. Проще говоря, если разработчик уже не пишет каждую строку сам, то обязан как минимум понимать, что он принимает в кодовую базу от модели.
Для бизнеса тут тоже нет ничего абстрактного. Старый подход «прогоним SAST и успокоимся» работает все хуже, когда существенная часть риска живет в пайплайне сборки, конфигурации, разрешениях, подписывании артефактов и политике обновлений. Командам придется усиливать SBOM, проверку provenance, контроль зависимостей и правила для AI-генерации кода. Иначе получится знакомый жанр: разработка ускорилась, демо красивое, а через пару недель выясняется, что половина продакшена держится на пакете неизвестного происхождения, открытом бакете и ошибке в обработке исключений. OWASP Top 10 в этой редакции полезен именно тем, что возвращает разговор о безопасности из области банальных чеклистов в область инженерной дисциплины.
Самый неприятный, но, возможно, самый полезный вывод здесь такой: эпоха AI-кодинга не убирает старые уязвимости, а просто упаковывает их в более быстрый конвейер. Чем дешевле стало производить код, тем дороже становится способность отсеивать плохой код, сомнительные зависимости и хрупкие архитектурные решения еще до релиза. Поэтому следующий спор в индустрии, похоже, будет не о том, можно ли доверить модели написание фичи, а о том, кто и как будет нести ответственность за ее безопасность. Разобрать логику обновления подробнее можно в заметке .