30 мая 2025 года на Global AppSec EU в Барселоне OWASP выкатил ASVS v5.0.0 - первый мажорный релиз Application Security Verification Standard за шесть лет. Около 350 требований, 17 глав вместо 14, полная перенумерация каждого контрола и четыре новые главы, которые затаскивают в стандарт целые области - от OAuth до WebRTC. Для тех, кто строил процесс тестирования на v4.0.3, это не инкрементальный патч с правками формулировок. Это пересборка стандарта с нуля. Разбираю, что конкретно поменялось и как это бьёт по повседневной работе пентестера.
Каждый контрол из v4.0.3 либо получил новый номер, либо объединён с другим, либо удалён. Ссылки вида
v4.0.3-2.1.1 в отчётах и чеклистах больше не валидны. В v4 инъекции располагались в другой главе и под другим номером. Точные номера контролов - на asvs.dev.Количество глав выросло с 14 до 17. Появились отдельные главы для четырёх областей, которых в v4 не было как самостоятельных разделов:
- V3 Web Frontend Security - безопасность фронтенда (SPA, CSP, DOM-атаки)
- V9 Self-Contained Tokens - работа с JWT и аналогичными токенами
- V10 OAuth and OIDC - авторизация через OAuth 2.0 и OpenID Connect
- V17 WebRTC - безопасность real-time коммуникаций
Для навигации OWASP запустил отдельный сайт asvs.dev - можно просматривать текущую и предыдущие версии. Данные доступны в CSV и JSON для интеграции с инструментами автоматизации. Маппинг-документ v4.0.3 → v5.0 лежит в репозитории OWASP ASVS на GitHub - в нём видно, что произошло с каждым конкретным контролом.
ASVS уровни безопасности: как ребалансировка влияет на пентест
Ребалансировка уровней - пожалуй, самое болезненное обновление ASVS 5.0 для тех, кто проводит аудит безопасности приложений. В v4.0.3 уровень L1 определялся как «bare minimum» и содержал около 130 контролов. Идея была в том, что L1 полностью покрывается тестированием чёрным ящиком - пентестом без доступа к исходному коду и документации. На практике 131 контрол «минимального уровня» оказался настолько высоким порогом входа, что многие организации либо отказывались от ASVS вовсе, либо закрывали часть L1 и застревали на этом навсегда.В ASVS v5.0 уровни перераспределены. По оценке OWASP-сообщества (данные Codific), распределение выглядит так:
| Уровень | Доля требований | Примерное количество | Назначение |
|---|---|---|---|
| L1 | ~20% | ~70 контролов | Базовый уровень, доступный большинству приложений |
| L2 | ~50% | ~175 контролов | Рекомендуемый по умолчанию для приложений с конфиденциальными данными |
| L3 | ~30% | ~105 контролов (из них ~90 новых сверх L2) | Высоконадёжные системы: финансы, здравоохранение, критическая инфраструктура |
L1 сократился почти вдвое - с ~130 до приблизительно 70 контролов. Зато L3 вырос радикально: с ~20 дополнительных требований сверх L2 до ~90, причём более половины новых L3-требований - полностью новые, не перенесённые с других уровней (по данным маппинга v4→v5 от Softwaremill).
Что это значит на практике
Три вещи, которые надо учитывать при скоупинге проектов:Black-box тестирования больше недостаточно. В v4 L1 позиционировался как уровень, который «можно покрыть пентестом». В v5.0 OWASP это утверждение прямо снял. Стандарт заявляет: полноценная верификация безопасности веб-приложений требует доступа к внутренним артефактам - исходному коду, документации, конфигурации. Если заказчик ставит целью «соответствие ASVS L1» - пентест чёрным ящиком не закрывает этот вопрос. Точка.
Разрыв между L1 и L2 увеличился. При L1 = 70 контролов трудоёмкость базовой проверки снижается. Но L2 теперь покрывает ~175 контролов - в 2,5 раза больше L1. При планировании проекта уточняйте целевой уровень на берегу, потому что в v5 разница между L1 и L2 куда ощутимее, чем в v4.
L3 стал реальным. В v4 разница между L2 и L3 составляла около 20 контролов - многие команды воспринимали L3 как «L2 плюс формальности». Теперь L3 - это ~90 дополнительных требований, включая проверки sender-constrained токенов через mTLS и DPoP, постквантовую криптографию и расширенное логирование. Это серьёзный объём работы, который нужно закладывать в сроки и бюджет.
OWASP также допускает смешение уровней по компонентам: публичный API может таргетировать L2, а модуль identity management - L3. Гибкость, которой в v4 формально не было.
Новые главы OWASP ASVS: требования к OAuth, WebRTC и фронтенду
Четыре новые главы - не перегруппировка существующего, а расширение покрытия стандарта на области, которых в v4 либо не было, либо они были размазаны по другим разделам.V10 OAuth and OIDC
Самая содержательная из новых глав. По данным Softwaremill, только раздел V10.4 (OAuth Authorization Server) содержит 16 новых требований, распределённых по всем трём уровням, 5 из которых - L3. Среди проверок:- Фиксированный и клиент-специфичный
response_mode - Выпуск sender-constrained access tokens через mTLS или DPoP (Demonstration of Proof of Possession)
redirect_uri и проверке CSRF в authorization flow, теперь ASVS требует верификации привязки токена к конкретному клиенту на криптографическом уровне. Другой масштаб задачи.С точки зрения MITRE ATT&CK: некорректная реализация OAuth - вектор для Modify Authentication Process (T1556, Credential Access / Persistence) и Valid Accounts (T1078, Initial Access / Privilege Escalation). Глава V10 по сути формализует проверки, которые закрывают эти техники на уровне приложения.
V3 Web Frontend Security
Отдельная глава для фронтенда - ответ на повсеместный переход к SPA-архитектурам (React, Vue, Angular). В v4 фронтенд-специфичные требования были разбросаны по разным главам: часть в валидации, часть в конфигурации. Теперь всё собрано в одном месте - при построении чеклиста для тестирования фронтенда не нужно скакать между главами.V9 Self-Contained Tokens
JWT используются повсеместно, но в v4 требования к ним были рассеяны между главами аутентификации и управления сессиями. Новая глава структурирует проверки: валидация подписи, обработкаalg: none, срок жизни, защита от replay-атак. Для пентестера - единый чеклист вместо выборочных проверок из разных разделов. Удобно.V17 WebRTC
Нишевая глава для приложений с real-time коммуникациями: видеозвонки, стриминг, peer-to-peer. WebRTC-приложения имеют специфические поверхности атаки (SRTP, ICE candidates, TURN-серверы), которых нет в классическом веб-тестировании. Если ваш проект не затрагивает WebRTC - глава пропускается. Но если затрагивает - раньше вы проверяли это без формального стандарта, теперь он есть.Documented Security Decisions: новый тип требований ASVS v5
Концептуальное нововведение v5.0 (по данным Codific) - разделение требований на два типа в каждой главе:- Documented Security Decisions (DSD) - фиксация архитектурных решений по безопасности: почему выбрана конкретная схема аутентификации, как определена политика хранения секретов, по какому принципу реализована авторизация
- Implementation Requirements - конкретные поведенческие требования, которые можно протестировать через code review или целенаправленный пентест
Влияние на процесс тестирования
При ASVS-based assessment на уровне L2 и выше пентестер обязан проверить не только «работает ли RBAC», но и «задокументировано ли, почему выбран RBAC, а не ABAC, какие risk decisions стояли за этим выбором». Это меняет формат взаимодействия с заказчиком: до начала технического тестирования нужно запросить документацию по security decisions. Если её нет - это несоответствие стандарту, даже если код безупречен.На уровне зрелости процессов это сближает OWASP ASVS с подходом OWASP SAMM, который оценивает не отдельные контролы, а зрелость организационных процессов безопасности. DSD создают мост между «что мы проверяем в коде» и «как организация принимает решения по безопасности» - требования к безопасности ПО теперь включают требования к документированию этих решений.
С точки зрения ATT&CK: отсутствие документированных решений по хранению секретов - предпосылка для Unsecured Credentials (T1552, Credential Access). Если решение не задокументировано - велика вероятность, что оно и не реализовано системно.
Ключевые ASVS v5 изменения конкретных контролов
Помимо структурных перемен, изменились отдельные требования. Ниже - те, которые напрямую влияют на практику тестирования.Минимальная длина пароля: с 12 до 8 символов
В v4.0.3 требованиеv4.0.3-2.1.1 устанавливало минимум 12 символов. В v5.0 соответствующий контрол (L1, предположительно v5.0.0-6.2.1) снижает порог до 8 символов, одновременно рекомендуя минимум 15. Для пентестера: если приложение принимает пароли от 8 символов - формально оно соответствует L1. В рекомендациях отчёта ссылайтесь на рекомендацию в 15+ символов.С точки зрения MITRE ATT&CK: короткие пароли увеличивают эффективность Brute Force (T1110, Credential Access). При тестировании парольной политики по ASVS v5 проверяйте не только минимальную длину, но и компенсирующие механизмы - rate limiting, MFA, breach detection (проверка по базам скомпрометированных паролей).
Постквантовая криптография
В главе по управлению криптографическими ключами появилось требование L3 о плане миграции на постквантовые криптографические алгоритмы (точный номер контрола - на asvs.dev). Приложение не обязано уже использовать Kyber или Dilithium - требуется документированный план: когда и как будет проведена миграция. На L3-проверке пентестер запрашивает этот план и убеждается, что он существует и содержит конкретные шаги. Нет плана - нет соответствия.Логирование: пример понижения уровня
Контролv4.0.3-9.2.5 (L3), требовавший логирования ошибок TLS-соединений на backend, понижен до L2 и переформулирован. В v5.0 он стал предположительно v5.0.0-16.3.4 (L2, точный номер - на asvs.dev) - логирование неожиданных ошибок и сбоев контролов безопасности, включая TLS-ошибки. Редкий случай, когда требование стало доступнее: OWASP решил, что базовое логирование ошибок безопасности обязано быть на L2, а не прятаться за порогом L3.Отвязка от CWE и NIST
В v4.0.3 каждое требование маппировалось на CWE-идентификаторы. В v5.0 прямые ссылки удалены. Причина: часть маппингов была неточной - одно требование ASVS не всегда чисто ложилось на один CWE. Будущие кросс-ссылки реализуются через проект OWASP Common Requirement Enumeration (CRE), который обеспечит более гибкое соответствие между OWASP стандартами безопасности, CWE и другими фреймворками.Для пентестера, привыкшего ставить CWE в отчёт через ASVS-маппинг, это дополнительный шаг: CWE-привязку придётся делать самостоятельно или ждать публикации CRE-данных. Зависимость от NIST Digital Identity Guidelines (SP 800-63) вынесена в отдельную секцию за пределами основного списка требований.
AI-требования: осознанное отсутствие
В ASVS v5.0 нет контролов по безопасности AI/ML-систем. По позиции разработчиков стандарта, AI-безопасность заслуживает отдельного стандарта. Проект AISVS (Artificial Intelligence Security Verification Standard) запущен в рамках OWASP, но пока не имеет официального релиза и таймлайна. Правильное решение - впихивать AI в общий стандарт сейчас означало бы кучу сырых контролов, которые устареют через полгода.ASVS vs OWASP Top 10: когда стандарт верификации нужен вместо Top 10
Вопрос, который всплывает при скоупинге с завидной регулярностью: «Мы проверяем по OWASP Top 10 - зачем нам ASVS?»Разница принципиальная. OWASP Top 10 - список из 10 наиболее распространённых рисков: Broken Access Control, Injection, Cryptographic Failures. Это awareness-документ: он указывает, что бывает плохо. ASVS - каталог контролов, которые предотвращают эти риски. Он говорит, что конкретно проверить.
Конкретный пример: OWASP Top 10 A03:2021 (Injection) говорит, что инъекции - серьёзный риск. ASVS v5.0 содержит тестируемое требование в главе V2 (Encoding and Sanitization), требующее, чтобы приложение было защищено от OS command injection, а системные вызовы использовали параметризованные запросы или контекстное экранирование (точный номер контрола - на asvs.dev). Это можно проверить через code review или целенаправленный тест - конкретный чекпоинт, а не абстрактный риск.
Другой пример: A01:2021 (Broken Access Control) - по данным OWASP, 94% приложений были протестированы на эту категорию. Но что именно проверять? Top 10 не отвечает. ASVS содержит десятки контролов по авторизации, каждый с указанием уровня.
При скоупинге проекта по OWASP compliance - уточняйте у заказчика. Top 10 - ориентир для расстановки приоритетов. ASVS - стандарт для верификации с измеримым результатом. Первый работает на осведомлённость, второй - на secure development lifecycle с конкретными метриками.
OWASP ASVS чеклист: адаптация пентест-процесса под v5.0.0
- Запрашивать Documented Security Decisions до начала теста. При L2+ проверке - запросить у заказчика документацию по архитектурным решениям безопасности. Отсутствие документации = несоответствие стандарту. Включить этот пункт в pre-engagement checklist.
- Пересмотреть парольную политику в чеклисте. Минимум 8 символов (L1) вместо 12 (v4). Если заказчик таргетирует L1 - формально допустимо. В рекомендациях - ссылаться на ASVS-рекомендацию 15+ символов и необходимость компенсирующих мер.
- Уточнить целевой уровень с заказчиком. В v5 разрыв между L1 и L2 вырос, L3 стал значительно объёмнее. Формулировка «проверка по ASVS» без указания уровня не имеет практического смысла.
- Перестроить CWE-маппинг в отчётах. Прямых ссылок ASVS→CWE в v5 нет. Если отчёт требует CWE - маппить вручную или использовать OWASP CRE, когда он станет доступен.
- Интегрировать свежие данные в инструменты. ASVS v5.0 опубликован в JSON и CSV. Если в workflow используется Burp Suite, OWASP ZAP или semgrep - импортировать свежий JSON для маппинга находок на контролы v5.0. На бумаге формула понятна, но разница в workflow реально ощущается только когда прогоняешь проверки на живых приложениях. Если хочется потренироваться в безопасной среде, готовые стенды есть на HackerLab.pro - это российская CTF-платформа экосистемы Codeby с категориями web, crypto и другими, нужна регистрация, после неё доступны задачи всех уровней.
Вторая мысль, которая не даёт покоя: снижение минимальной длины пароля с 12 до 8 символов - шаг назад, обёрнутый в прагматизм. OWASP аргументирует это тем, что завышенный порог отталкивал организации от внедрения стандарта. Но когда GPU-кластеры перебирают 8-символьные хеши за часы, понижение минимума выглядит как компромисс в пользу adoption rate за счёт реальной безопасности. Рекомендация 15+ символов - отлично, но аудитор ставит галочку «соответствует» по формальному требованию, а не по рекомендации. Организация, выбирая между «соответствует L1» и «следует рекомендациям, но формально делает больше необходимого», всегда выберет первое. Это проблема любого стандарта, где минимум воспринимается как потолок.
