OWASP: практическое применение и соответствие требованиям РФ

В российских компаниях внедрение OWASP часто сводится к формальной установке ZAP или распечатке Top 10 на стене. В результате в API, мобильных приложениях или цепочке поставок угрозы остаются без внимания, а аудиты фиксируют «пробои» по требованиям ФСТЭК и других регуляторов.

Что такое OWASP и зачем он нужен российским компаниям

OWASP — это международная открытая инициатива по повышению безопасности приложений. Open Web Application Security Project в дословном переводе — Открытый всемирный проект по безопасности приложений.

Это не компания и не коммерческая организация, а международное сообщество специалистов по ИБ, разработчиков и исследователей, которые создают и поддерживают открытые стандарты, методики тестирования и бесплатные инструменты для повышения безопасности приложений. Все материалы находятся в открытом доступе.

Обычно, когда в говорят «OWASP», часто вспоминают лишь топ-10 уязвимостей. На самом деле это целая экосистема проектов. В неё входят:

• стандарты OWASP для формулирования требований к безопасности (ASVS)
• методики тестирования (WSTG, MASVS)
• модели зрелости процессов (SAMM)
• инструменты автоматизированного анализа (OWASP ZAP)
• готовые правила для веб-файрволов (OWASP CRS)
• проекты для контроля цепочки поставок и формирования SBOM

С таким набором инструментов можно закрыть отдельные уязвимости и при этом выстроить системную модель безопасной разработки.

В 2025 году OWASP продолжает развиваться: готовится обновление топ-10 для веб-приложений, расширяются проекты по защите API и мобильных приложений, растёт внимание к уязвимостям искусственного интеллекта (OWASP LLM Top 10). Эти инициативы формируются на основе мирового опыта, но их методики и инструменты легко адаптировать под российские реалии, включая требования ФСТЭК, ГОСТ Р 57580 и СТО БР ИББС.

Хорошее понимание проектов OWASP, умение их применять поможет российским компаниям не изобретать велосипед, а брать проверенные подходы, корректируя их под законодательство и инфраструктуру.

Карта артефактов: какие задачи решают конкретные проекты OWASP

OWASP — это не один документ и не только топ-10 уязвимостей. Проекты OWASP охватывают весь цикл безопасной разработки: от формулировки требований до тестирования и сопровождения.

Чтобы быстро сориентироваться, воспользуйтесь таблицей, где каждый артефакт связан с конкретной задачей. Так вам будет легче понять, с чего начать и какие стандарты OWASP применить в своей работе.

Для работы в российских условиях выбирайте проекты OWASP, которые помогают не только устранять уязвимости, но и подтверждать соответствие требованиям регуляторов. Например, ASVS и WSTG можно прикладывать как доказательную базу при аудите по ФСТЭК, а SBOM и SCA-инструменты CycloneDX/Dependency-Track полезны для контроля цепочки поставок в соответствии с ГОСТ Р 57580.

OWASP Top 10 для веб-приложений

OWASP Top 10 для веб приложений — это ориентир по приоритетам безопасности в веб-разработке, составленный на основе анализа уязвимостей, инцидентов и обратной связи от специалистов по всему миру. В России этот список применяют при аудитах, пентестах и формировании требований к разработке.

Важно чётко разделять OWASP Top 10 для веба и API Security Top-10. Веб-топ описывает угрозы, характерные для пользовательских интерфейсов и серверных частей веб-приложений: ошибки авторизации, инъекции, небезопасная конфигурация.

API-топ охватывает другой набор проблем — авторизацию на уровне объектов и свойств, защиту от массовых запросов, уязвимости в спецификациях и контрактах API. Подмена одного другим в аудите ведёт к пропуску критичных рисков и формальному, а не реальному повышению защищённости.

Краткий разбор Top 10:2021 с фокусом на «болезненные» для РФ кейсы

Broken Access Control — абсолютный лидер по инцидентам. Типовые ситуации в российских проектах:

• IDOR (Insecure Direct Object Reference) в личных кабинетах — смена ID в URL даёт доступ к чужим счетам, заявкам или документам;
• доступ к административным функциям через прямой вызов скрытых URL без проверки роли;
• отключённый серверный контроль прав после интеграции с внешним сервисом.

Криптографические ошибки встречаются реже, но последствия у них критичнее:

• хранение паролей в базе в виде SHA-1 или MD5 без соли — это устаревший и небезопасный подход: одинаковые пароли дают одинаковые хэши, их легко подобрать по готовым таблицам, так как нет случайной строки (соли), которая делала бы хэш уникальным для каждого пользователя
• использование недоверенных /самоподписанных или просроченных сертификатов в боевой среде
• передача персональных данных по HTTP внутри корпоративной сети «для скорости»

Конфигурационные ошибки — стабильный источник проблем:

• публично доступные админ-панели без ограничения по IP
• дефолтные логины и пароли в веб-интерфейсах оборудования
• включённый режим отладки с выводом стек-трейсов и конфигурации сервера

Что можно внедрить в SDLC прямо сейчас:

• строгую валидацию и фильтрацию всех входных данных на серверной стороне
• авторизацию на уровне объектов и свойств, а не только по ролям
• безопасное хранение секретов с регулярной ротацией
• централизованное журналирование доступа и ошибок с мониторингом подозрительных событий

Эти меры дают эффект даже в проектах, где полное внедрение secure SDLC пока нереально: они закрывают наиболее эксплуатируемые в России уязвимости и упрощают последующие аудиты.

Что готовит Top 10:2025

На момент публикации версия OWASP Top 10 2025 не вышла. По анализу последних отчётов OWASP и обсуждений в профильных сообществах ожидаются такие изменения:

• перераспределение акцентов между категориями
• усиление роли угроз цепочки поставок (supply chain)
• больше внимания к журналированию и реагированию на инциденты
• уточнение требований к криптографии

Это не официальная позиция OWASP, а прогнозы. Точные формулировки и порядок категорий станут известны только после официального релиза.

OWASP API Security Top 10:2023

OWASP API Security Top-10 — это специализированный рейтинг из десяти наиболее критичных уязвимостей, характерных именно для API-интерфейсов. Он фокусируется на угрозах в логике взаимодействия сервисов: авторизация на уровне объектов и свойств, контроль доступа, защита от перебора запросов, ошибки в спецификациях.

Список служит ориентиром для приоритизации мер защиты API и не пересекается напрямую с OWASP Top-10 для веб-приложений, где акцент сделан на уязвимостях пользовательских интерфейсов и серверной логики.

Из-за этой разницы при аудите API нельзя опираться только на веб-топ. В API редко встречаются классические XSS или SQL-инъекции, но много логических уязвимостей. Например:

• доступ к чужим объектам через подмену идентификатора в запросе
• массовая отправка данных в обход бизнес-логики
• атаки через нестандартные параметры или последовательности запросов

Если подменить один список другим, то критичные уязвимости на уровне объектов, свойств или сессий просто останутся незамеченными.

Что изменилось в OWASP API Security Top 10 с 2019 года

За последние годы архитектура приложений усложнилась: микросервисы, сложные модели данных, интеграции через внешние API. OWASP учёл эти изменения и обновил рейтинг. Одно из ключевых новшеств — появление категории BOPLA (Broken Object Property Level Authorization).

Это уязвимость в API, при которой проверка прав доступа выполняется только на уровне объекта, но не на уровне его отдельных свойств. Например, если пользователь может видеть свой профиль (объект), но API также отдаёт поля вроде isAdmin или balance, которые он не должен видеть или менять.

Термин BOPLA объединяет две частые ошибки:

• избыточная выдача данных — API отдаёт клиенту поля, которые не нужны для работы и могут раскрывать чувствительную информацию
• mass assignment — возможность изменять свойства объекта, которые не должны редактироваться через публичный интерфейс

BOPLA отражает реальную боль современных API, где проверка прав на уровне свойств часто забывается или реализуется формально.

Типичные антипаттерны в российских проектах

В российских проектах уязвимости из OWASP API Security Top-10 встречаются регулярно, причём в одних и тех же сценариях. Чаще всего мы видим::

• Нет авторизации на уровне объекта — пользователь меняет ID в запросе и получает доступ к чужим заказам или договорам.
• Нет rate limiting — перебор логинов, кодов подтверждения или номеров документов выполняется без ограничений.
• BFF отдаёт лишние поля — клиенту возвращаются технические идентификаторы, внутренние статусы или отладочные данные.
• Мобильный API полагается на клиента — проверка прав выполняется только в приложении, без серверной валидации.

Знание типичных ошибок помогает аудитору быстрее находить уязвимости, а разработчику — строить защиту не вслепую, а с опорой на реальные кейсы из практики.

Чтобы исключить эти проблемы, сразу встройте в процесс разработки контроль доступа на уровне объектов и свойств, настройте ограничение запросов, минимизируйте выдачу данных, перенесите ключевые проверки на сервер. Это даст не только соответствие OWASP API Security Top-10, но и реальное снижение риска утечек и атак.

Практика: как тестировать API

Эффективная стратегия тестирования API должна включать автоматизацию и ручной анализ. Автосканеры полезны для поиска технических ошибок, но логические уязвимости авторизации и избыточная выдача данных выявляются только в ручных сценариях.

Минимальный набор проверок:

1. Авторизация на уровне объектов и свойств (BOLA/BOPLA).
2. Настройка и тестирование rate limiting, включая имитацию распределённых атак.
3. Аудит спецификаций API (OpenAPI/Swagger) на предмет лишних эндпоинтов, полей и параметров.

С такой комбинацией вы закроете уязвимости, которые в автоматическом скане могут остаться незамеченными, и снизите риск критичных утечек.

Mobile Top 10:2024 — риски мобильных приложений

OWASP Mobile Top 10 — это список наиболее опасных уязвимостей и ошибок в мобильных приложениях. В российских условиях его особенно важно учитывать в банках, маркетплейсах и государственных сервисах, где мобильный клиент стал основным каналом взаимодействия с пользователями.

Топ проблем: учётные данные, supply chain, authn/authz

В OWASP Mobile Top 10:2024 на первом плане остаются уязвимости, связанные с управлением учётными данными:

• хранение логинов и паролей в открытом виде в SQLite, SharedPreferences или keychain
• жёстко прописанные ключи API в коде, доступные при декомпиляции
• отправка токенов по незащищённым каналам

Серьёзным фактором риска в мобильной разработке стал supply chain: компании подключают сторонние SDK и библиотеки без аудита кода, а автоматические обновления зависимостей нередко приносят в проект уязвимости или скрытые трекинг-модули.

Как проявляются проблемы аутентификации и авторизации (authn/authz):

• вход без повторной авторизации при критичных операциях (например, перевод денег)
• проверка прав только на клиенте, без валидации на сервере
• одинаковые токены доступа для разных ролей

Быстрые меры: MASTG/МАSVS, защита хранилищ, приватность, анти-tampering

Чтобы снизить риски, используйте методики OWASP MASVS (Mobile Application Security Verification Standard) и OWASP MASTG (Mobile Application Security Testing Guide) как чек-листы и методические базы. Они помогают структурировать тестирование и проверку защиты на всех этапах разработки.

Минимальные шаги для укрепления безопасности мобильных приложений:

1. Хранить учётные данные и ключи только в защищённых контейнерах ОС (Android Keystore, iOS Keychain).
2. Проверять сторонние SDK и обновления перед интеграцией в релиз.
3. Внедрять анти-tampering и обфускацию для усложнения реверс-инжиниринга.
4. Контролировать доступ к функциям на серверной стороне, даже если проверка есть в клиенте.

Внедрение этих мер не заменит полного аудита, но закроет самые частые сценарии атак на мобильные приложения.

GenAI/LLM: новый фронт OWASP

С появлением решений на базе больших языковых моделей (LLM) и их интеграцией в продукты OWASP открыл новый фронт — защиту GenAI-приложений. Рост популярности умных чат-ботов, поисковых систем и «агентов» создал уникальный набор угроз, которые не описаны в классических Top-10.

Для российского бизнеса: финтех, e-commerce, госсектор эти риски особенно актуальны. На передний план выходят две ключевые группы уязвимостей:

1. Insecure Output Handling — модель генерирует данные или команды, которые могут быть опасны при автоматической обработке (SQL-запросы, ссылки на вредоносные ресурсы, инструкции по обходу авторизации).
2. Supply Chain — компрометация через плагины, внешние API, модельные веса или наборы данных.

Для систем на базе RAG (Retrieval-Augmented Generation) и агентных архитектур полезно внедрять базовые технические ограничения. Это фильтрация входных и выходных данных, запуск потенциально опасных операций в изолированных средах, строгий контроль доступа к плагинам и инструментам.

В российском сегменте уже появляются собственные LLM WAF — фильтры и прокси, которые анализируют запросы и ответы, блокируя вредоносные сценарии.

LLM Top 10 (v1.1) и апдейт 2025

OWASP выпустил LLM Top 10 v1.1, а к 2025 году готовит обновление. Среди ключевых угроз,  которые будут в центре внимания, можно выделить:

• Prompt Injection — внедрение вредоносных инструкций в запрос к модели.
• Insecure Output Handling — автоматическое выполнение или передача данных, сгенерированных моделью, без проверки.
• Supply Chain — уязвимости в плагинах, моделях, внешних сервисах.
• Excessive Agency — избыточные полномочия агента без ограничений по контексту и операциям.

В RAG-и агентных архитектурах эти риски особенно высоки: модель может получить доступ к данным или функциям, на которые не рассчитан её сценарий работы, и выполнить нежелательные действия.

Мини-плейбук для команды: «входы / выходы / контексты / плагины»

Для эффективной защиты LLM-интеграций необходимо наладить системную работу. Вот мини-плейбук, который поможет зафиксировать базовые правила безопасности:

1. Входы — проверка и фильтрация запросов, исключение опасных шаблонов.
2. Выходы — анализ ответов на наличие вредоносных команд, ссылок, кода.
3. Контексты — контроль объёма и типа передаваемых данных, особенно конфиденциальных.
4. Плагины — аудит подключаемых инструментов, ограничение прав и зон доступа.П

Плейбук поможет зафиксировать базовые правила, которые будут работать даже при изменении моделей и архитектуры для снижения риска внезапных компрометаций через ИИ-инфраструктуру.

ASVS (Application Security Verification Standard) — один из ключевых стандартов OWASP. Это язык требований к безопасности приложений, понятный разработчикам, тестировщикам, аудиторам. В ASVS требования сгруппированы по уровням зрелости и областям безопасности, их можно подбирать под реальный риск проекта, а не проверять всё подряд.

Новая версия ASVS 5.0 стала заметно более структурированной:

• Трёхуровневая система зрелости — выбираете уровень под риски проекта.
• 14 категорий безопасности — охватывают весь цикл защиты, от аутентификации до криптографии.
• Более чёткие формулировки — требования стали конкретнее и проще для внедрения.

Как «приземлить» ASVS на реальную разработку:

Выбор уровня ASVS: не все требования одинаково нужны:

1. Уровень 1 — базовая защита. Подходит для внутренних инструментов (~50 требований, автоматизированное тестирование).
2. Уровень 2 — стандарт для бизнеса. Корпоративные приложения (~130 требований, ручное тестирование + инструменты).
3. Уровень 3 — высокая защита.

Уровень 3 — защита, рассчитанная на финтех, госсектор и критическую инфраструктуру. В OWASP ASVS 5.0 уровень 3 включает около 180 контролей — это полный набор требований из всех 14 категорий, без исключений по технологиям. Объём рассчитан на проекты с повышенными рисками, где нужна максимальная глубина проверки архитектуры и реализации.

После выбора уровня читаем каждое требование не как сухую строку стандарта, а как инструкцию для реализации. Например, пункт про хранение паролей превращается в конкретное правило: «Использовать Argon2 или bcrypt с солью и параметрами не ниже X». Так формируются живые чек-листы, которые реально применимы на проекте.

Практический подход к аудиту по ASVS

Не проверяйте всё подряд:

1. Фильтруйте по контексту: OAuth не нужен, если используется только basic auth.
2. Приоритезируйте риски: сначала аутентификация и авторизация, потом второстепенные контроли.
3. Группируйте проверки: например, валидация входных данных во всех формах сразу.

Структура отчёта по аудиту ASVS.
Итоговый документ удобно строить по уровням зрелости.

1. Критичные нарушения (L1) — дефекты, из-за которых приложение не проходит базовый уровень. Например: ASVS 2.2.1 — отсутствует блокировка после нескольких неудачных попыток входа.
2. Рекомендации для L2 — улучшения для перехода на следующий уровень. Например: ASVS 4.2.2 — добавить CSRF-токены в формы.

При таком формате видно, что нужно исправить в первую очередь, что можно запланировать в рамках развития безопасности.

Интеграция с процессами: от кода до мониторинга

Чтобы ASVS был не только в документах, а реально работал, его нужно встроить в три области: сборку кода, мониторинг и проектную документацию. Вот минимальная связка, которая работает в проде и понятна аудиторам:

1. Сборка кода. Настрой SAST-проверки на каждый коммит или pull request с профилем под выбранный уровень (L1/L2). Автотестами закрой требования L1. Для релизных веток добавь быстрый DAST-скан (например, ZAP) и правило: если найден критичный дефект, выпуск останавливается до исправления.
2. Мониторинг. Записывай события безопасности по ASVS 7.1.x, настраивай оповещения на подозрительные входы, рост прав, блокировки доступа и массовые ошибки авторизации. Свяжи оповещения с процессом реагирования на инциденты и храни логи в защищённом виде.
3. Документация. В модели угроз указывай, какие пункты ASVS она закрывает, а требования к безопасности формулируй как конкретные проверки. Создай чек-листы для ревью кода и прослеживаемость «требование → задача → тест → подтверждающий артефакт».

Так формируется сквозная картина: требования из ASVS отражаются в коде и тестах, события видны в мониторинге, а доказательная база хранится в артефактах. Команда понимает, что делать дальше, аудиторы видят, что уже сделано.

SAMM — оценка зрелости безопасной разработки

OWASP SAMM (Software Assurance Maturity Model) — это структурированная модель, помогает оценить, как компания строит безопасность на всех этапах жизненного цикла ПО, определить конкретные шаги для повышения зрелости. В отличие от разрозненных чек-листов, SAMM измеряет не только наличие процессов, но и их зрелость — насколько они управляемы, интегрированы в SDLC и дают измеримый результат.

Методика охватывает пять доменов: Governance, Design, Implementation, Verification и Operations. В каждом — набор практик с уровнями зрелости от 0 до 3. Можно оценить не только текущее состояние процессов разработки и защиты, но и то, как они работают, насколько устойчивы к изменениям и как могут воспроизводиться в новых проектах.

Быстрая самооценка (target vs. current), дорожная карта на год

Оценка по SAMM начинается с фиксации текущего состояния (current) и целевого уровня (target) по каждой практике. Обычно это делается через опросники и интервью с командами, анализ артефактов (код, документация, отчёты тестов) и наблюдение за процессами.

Например:

1. Current: верификация безопасности кода проводится эпизодически по инициативе отдельных разработчиков.
2. Target: автоматизированная проверка кода и зависимостей интегрирована в CI/CD, результаты фиксируются и отслеживаются метриками.

Разрыв между текущим и целевым состоянием формирует список задач. Их приоритизация строится по критериям: влияние на риск, стоимость внедрения, зависимость от смежных процессов. Так появляется дорожная карта на год:

• первые 3–4 месяца — закрытие критичных пробелов (например, внедрение SAST и контроль управления уязвимостями)
• следующие 4–6 месяцев — интеграция процессов в DevOps-практики, обучение команды
• оставшееся время — оптимизация и закрепление (метрики, автоматизация)

Такая поэтапная стратегия исключает перегруз команды и создаёт устойчивый фундамент для дальнейшего роста зрелости.

Где SAMM пересекается с SDLC/DevSecOps и бюджетами

SAMM не существует в вакууме — он встроен в процессы разработки и эксплуатации. Если в компании уже есть налаженный SDLC, модель помогает встроить безопасность в каждый этап:

1. Планирование и дизайн: практики Governance и Design задают политику, стандарты, требования безопасности к архитектуре.
2. Реализация: Implementation отвечает за интеграцию безопасного кодинга, контроль зависимостей, защиту сборок.
3. Тестирование и приёмка: Verification обеспечивает ручное и автоматизированное тестирование, моделирование угроз, аудит кода.
4. Эксплуатация: Operations включает реагирование на инциденты, обновление зависимостей, управление уязвимостями в продакшне.

В DevSecOps-контексте SAMM работает как «дорожная карта внедрения безопасности в CI/CD». Он показывает, какие шаги должны появиться в пайплайне, в каком порядке их внедрять и как измерять эффект.

С точки зрения бюджета SAMM помогает обосновать расходы конкретными целями:

1. Например, внедрение SAST-инструмента для достижения Target Level 2 в практике Secure Build. Этот уровень в SAMM означает, что процессы уже формализованы, интегрированы в разработку и автоматизированы, а их качество контролируется.
2. Другие цели могут включать обучение разработчиков для закрытия пробела в уровне Design 1 → 2 или интеграцию Dependency-Track для автоматического контроля SBOM в Operations.

Такая привязка делает инвестиции в безопасность прозрачными для руководства: каждый пункт дорожной карты SAMM можно связать с конкретным риском и метрикой, а значит — с бизнес-эффектом.

WSTG — практическое тестирование

OWASP WSTG (Web Security Testing Guide) — один из наиболее детализированных стандартов тестирования безопасности веб-приложений. Это не просто перечень уязвимостей, а методика с пошаговыми сценариями проверки: от базовой аутентификации до сложных атак на бизнес-логику. Версия 4.2 считается стабильной и активно используется в аудитах. Пятая редакция в разработке, но сроки её выхода OWASP не объявлял.

WSTG редко применяют в чистом виде — обычно его комбинируют с автоматизированными инструментами. Чаще всего в российских проектах для «быстрых» проверок используют OWASP ZAP, а глубокий разбор выполняют вручную по сценариям из WSTG.

Такой подход помогает быстро выявить технические уязвимости, сохранить контроль над логическими ошибками, которые автомат не найдёт. Здесь важно помнить: ZAP ≠ замена ручному тесту бизнес-логики. Автосканеры помогают быстро выявить технические ошибки, но сценарии, завязанные на процессы и роли пользователей, требуют экспертного анализа.

Карта техник (AuthN/AuthZ, бизнес-логика, криптография, клиентская сторона)

WSTG охватывает четыре ключевых направления тестирования:

1. Аутентификация и авторизация (AuthN/AuthZ) — проверка устойчивости логина, сессий, механизма выхода, ограничений доступа на уровне объектов и функций.
2. Бизнес-логика — тесты на обход шагов процессов (например, оформление заказа без оплаты), проверка сценариев «недоступных» для пользователя ролей, попытки смены статуса операции без разрешения.
3. Криптография — аудит использования шифрования при хранении и передаче данных, проверка корректности сертификатов, алгоритмов и их параметров.
4. Клиентская сторона — анализ безопасности кода JavaScript, защиты от XSS, проверки политик Content Security Policy, поведения SPA-приложений при несанкционированных действиях.

Эта карта помогает формировать тест-план, в котором учтены как стандартные технические проверки, так и специфические риски конкретного бизнеса.

Как встроить WSTG в CI/CD: «smoke-DAST ZAP + ручные сценарии по риску»

Оптимальный способ интеграции WSTG в разработку — разделить тестирование на два уровня:

1. Smoke-DAST ZAP в CI/CD — на каждом релизе запускается упрощённый набор автоматических проверок: поиск стандартных XSS, SQL-инъекций, проблем с заголовками безопасности, уязвимых библиотек. Это экспресс-проверка работы критичных функций приложения.
2. Ручные сценарии по риску — планируются отдельно, охватывают сложные проверки: авторизация на уровне объектов, бизнес-логика, обход процессов. Здесь же выполняется анализ криптографии и клиентской части, который автоматизация покрыть не может.

Комбинация даёт баланс: CI/CD фиксирует регрессии на базовом уровне, а ручное тестирование фокусируется на глубинных и контекстных рисках. В итоге команда получает регулярный контроль без перегрузки релизного цикла и формальных отчётов «для галочки».

Помимо стандартов и методик, проекты OWASP включают набор инструментов, которые можно интегрировать прямо в рабочие процессы. Среди них есть как полностью автоматизированные решения для CI/CD, так и материалы, помогающие быстро внедрить проверенные практики в разработку.

В российских компаниях наиболее востребованы три направления: автоматическое тестирование через OWASP ZAP, усиление веб-файрвола с помощью OWASP CRS и использование Cheat Sheet Series для оперативного внедрения безопасных паттернов в код.

OWASP ZAP: как настроить сканер для DevSecOps и в чём его отличие от ручного пентеста

OWASP ZAP — DAST-сканер с открытым исходным кодом, подходит для автоматической проверки веб-приложений на распространённые уязвимости. Его удобно встраивать в CI/CD:

• в пайплайне GitLab CI или GitHub Actions ZAP можно запускать при каждом pull request, проверяя ключевые страницы на XSS, SQL-инъекции, уязвимости в заголовках
• результаты тестов автоматически прикрепляются к задаче, это ускоряет реакцию команды

При этом ZAP не заменяет ручного тестирования. Он не видит сложные сценарии авторизации, бизнес-логику или ошибки, зависящие от специфики проекта. В реальной практике ZAP используют как «сигнализацию» для быстрого выявления технических проблем, а глубинный анализ выполняют вручную по методикам WSTG.

OWASP CRS: как использовать веб-фаервол (WAF) для защиты от популярных атак

OWASP CRS (Core Rule Set) — набор готовых правил для ModSecurity и совместимых WAF, добавляет базовую защиту без сложной настройки. Он закрывает типовые атаки: XSS, SQL-инъекции, Path Traversal, попытки загрузки вредоносных файлов.

Где CRS полезен:

• защита от массовых автоматизированных атак на публичные веб-сервисы
• временная «заплатка» при невозможности сразу исправить уязвимость в коде
• фильтрация шумного трафика и фиксация подозрительных запросов

Где CRS не поможет:

• защита от логических уязвимостей и бизнес-логики
• фильтрация специфичных API-запросов с кастомными схемами

В российских проектах CRS часто используют на периметре как быстрый старт защиты, а затем дополняют кастомными правилами под особенности приложения.

Шпаргалки OWASP: как быстро закрыть ключевые уязвимости в коде

OWASP Cheat Sheet Series — это коллекция кратких, но ёмких рекомендаций по ключевым аспектам безопасности: от безопасного хранения паролей до защиты REST API. Каждая «шпаргалка» — это концентрат проверенных приёмов, который можно внедрить сразу, без долгого изучения документации.

В работе команд Cheat Sheet Series особенно полезны:

• при онбординге новых разработчиков — как стандарты кодинга
• для ревью кода — как база готовых критериев безопасности
• при подготовке к аудиту — как чек-листы для быстрой проверки критичных зон

Использование этих «шпаргалок» в связке с ASVS и WSTG ускорит внедрение безопасных практик, снизит количество повторяющихся ошибок.

OWASP CycloneDX и Dependency-Track: контроль зависимостей и уязвимостей в ПО

Цепочка поставок ПО давно стала одной из главных зон риска. Уязвимости и вредоносные изменения могут попасть в продукт через зависимости, сторонние SDK, образы контейнеров или даже обновления операционной системы. Решать эту задачу точечно — «обновим, когда вспомним» уже недостаточно. Нужен системный подход, здесь на помощь приходят SBOM (Software Bill of Materials) и инструменты из числа проектов OWASP.

SBOM: как управлять зависимостями с помощью CycloneDX

SBOM — это полный список компонентов, из которых состоит приложение: от библиотек и модулей до ОС и контейнерных образов. С его помощью можно быстро понять, затронут ли ваш продукт новой уязвимостью, оценить масштаб проблемы.

CycloneDX — формат описания состава программного обеспечения (SBOM, Software Bill of Materials). В нём фиксируются все компоненты продукта: библиотеки, модули, версии, их зависимости и лицензии. Файл нужен, чтобы быстро понять, из чего «собрана» система, найти уязвимые или запрещённые компоненты, проконтролировать обновления.

CycloneDX стал де-факто стандартом SBOM и закреплён как спецификация ECMA-424. Его преимущества:

• поддержка разных типов артефактов — не только кода, но и конфигураций, инфраструктуры, сервисов
• совместимость с инструментами анализа уязвимостей и управления зависимостями
• активная поддержка и развитие сообществом, включая новые профили для SaaS и контейнеров

ECMA-424 — это международный стандарт, описывает, в каком виде хранить и передавать сведения о составе программного обеспечения: список компонентов, их версии, лицензии, зависимости. Благодаря этому SBOM в формате CycloneDX можно автоматически обрабатывать, проверять на уязвимости и использовать как официальный артефакт при аудите или для соответствия требованиям.

Для российских компаний это удобный формат: он легко интегрируется в локальные пайплайны, не требует привязки к западным облакам, читается большинством SCA-инструментов, доступных в РФ.

SCA: зачем проверять зависимости на этапе сборки и как контролировать их в проде

Dependency-Check — инструмент для анализа зависимостей на этапе сборки. Он проверяет код и пакеты по базам известных уязвимостей (NVD и локальные зеркала), формирует отчёт и может останавливать сборку при критичных находках.

Dependency-Track — система непрерывного мониторинга SBOM в продакшне. Она хранит актуальные списки компонентов, сопоставляет их с базами уязвимостей, уведомляет о новых рисках.

Такое разделение даёт гибкость:

• на этапе сборки мы отсекаем заведомо небезопасные компоненты
• в продакшне отслеживаем изменения и реагируем на новые уязвимости в уже выпущенных версиях

Встраиваем в пайплайн и политику обновлений (приемлемый риск, SLA на патчи)

Эффективность SBOM и SCA зависит от того, как они встроены в процессы. Рабочая схема для CI/CD:

1. Генерация SBOM в формате CycloneDX при каждой сборке.
2. Автоматическая проверка Dependency-Check перед релизом.
3. Регулярный анализ Dependency-Track в продакшне.

Здесь важна политика обновлений:

• определяем, какой риск считаем приемлемым (например, CVSS < 5.0 может ждать планового релиза)
• фиксируем SLA на установку патчей (критичные — в течение 72 часов, средние — в течение месяца)
• используем policy-based updates — обновляем компоненты автоматически, если они попадают под заданные критерии

Даже если проект собирается в закрытом контуре, SBOM нужен: ОС, контейнерные образы и сторонние утилиты всё равно содержат зависимости, которые могут устареть или оказаться уязвимыми. Отсутствие внешних подключений не означает отсутствие угроз внутри цепочки поставок.

Как «приземлить» OWASP на российские требования

OWASP часто воспринимают как «иностранную методологию», но на практике её артефакты отлично ложатся в требования российского законодательства и стандартов. При правильной интеграции OWASP помогает не только повысить уровень безопасности, но и создать доказательную базу для аудита.

Где OWASP закрывает процессы соответствия

КИИ / № 187-ФЗ / Приказ ФСТЭК № 239. Российское регулирование для критической информационной инфраструктуры требует системного управления уязвимостями, контроля изменений и регулярного тестирования безопасности. Здесь OWASP даёт готовые, проверенные методики:

1. ASVS — формализует требования безопасности в терминах, понятных разработчикам и аудиторам.
2. WSTG — даёт структуру и сценарии тестов, включая ручную проверку бизнес-логики.
3. SBOM и SCA (CycloneDX, Dependency-Track) — закрывают контроль компонентов и цепочки поставок.
4. SAMM — помогает оценить зрелость процессов secure SDLC и сформировать дорожную карту улучшений.

Использование этих артефактов упрощает подготовку материалов для аудита, когда нужно показать, что меры выполняются и реально работают.

Финансовый сектор: ГОСТ Р 57580 и СТО БР ИББС
 Эти стандарты требуют защищённой разработки, регулярного тестирования, учёта компонентов и управления изменениями. OWASP — не норматив, но может помочь:

• структурировать secure SDLC (ASVS, SAMM)
• выстроить управление уязвимостями в продуктах и инфраструктуре (WSTG, SCA)
• документировать артефакты, которые можно предъявить аудиторам как доказательства выполнения требований

При проверках в банках и платёжных системах именно наличие документированных артефактов (отчётов по WSTG, чек-листов ASVS, выгрузок SBOM) часто становится аргументом в пользу зрелости процессов.

Таблица соответствий «требование ↔ артефакт OWASP»

Если встроить OWASP в нормативный контур, вы сможете одновременно реально повысить безопасность и проходить аудит без лишних «бумажных» упражнений.

Типичные ошибки при «внедрении OWASP»

OWASP часто используют формально, теряя его основную ценность — системный подход к безопасности. Ошибки, которые встречаются даже в крупных компаниях, приводят к иллюзии защищённости и провалам при аудитах.

Ошибка 1. «Top 10 = чек-лист для галочки».
OWASP Top 10 — это аналитический рейтинг, а не универсальный набор тестов. Если воспринимать его как полный чек-лист, критичные уязвимости вне списка (например, специфичные для API) останутся незамеченными. Для полноценного покрытия нужны ASVS и WSTG, а Top 10 — лишь ориентир по приоритетам.

Ошибка 2. «ZAP заменит ручной анализ и бизнес-логику».
ZAP удобен для автоматизации технических проверок, но не способен оценить бизнес-логику, сложные сценарии авторизации или злоупотребления функционалом. Автоматизация должна дополнять ручные тесты по WSTG, а не подменять их.

Ошибка 3. «ASVS — это только про пентест, а не про требования».
 ASVS — это «язык» формулировки требований к безопасности, применимый ещё на этапе проектирования. Если использовать его только для проверки готового продукта, вы упустите возможность встроить безопасность в процесс разработки и избежать дорогостоящих переделок.

Ошибка 4. «SBOM лишний: у нас закрытая сборка».
Закрытая сборка не защищает от уязвимостей в библиотечных зависимостях, ОС или контейнерных образах. SBOM нужен, чтобы иметь полный перечень компонентов и быстро реагировать на уязвимости в цепочке поставок, даже если код не распространяется за пределы компании.

Разобрав эти ошибки, проще выстроить процесс так, чтобы OWASP приносил реальную пользу: повышал уровень безопасности, давал доказательную базу для аудита, а не создавал иллюзию работы.

Главное

OWASP — это не список уязвимостей, а экосистема инструментов, стандартов и методик, которые помогают строить безопасные приложения системно. В 2025 году она охватывает все уровни: от требований (ASVS) и зрелости процессов (SAMM) до практических методик тестирования (WSTG) и контроля цепочек поставок (CycloneDX, SBOM).

Российским компаниям важно помнить следующие принципы:

1. OWASP Top 10 ≠ API Top 10. При аудите API не используйте веб-топ как замену — вы пропустите ключевые логические уязвимости.
2. ASVS — это требования, а не чек-лист. Его сила в том, что он задаёт стандарты на всех этапах SDLC, а не только в пентесте.
3. ZAP не заменяет ручной тест. Автоматизация ускоряет работу, но бизнес-логику проверяет человек.
4. SBOM нужен всем. Даже при закрытой сборке уязвимости приходят с зависимостями ОС, контейнеров, библиотек.

В локальном контексте OWASP помогает выполнять требования № 187-ФЗ, приказа ФСТЭК № 239, ГОСТ Р 57580 и СТО БР ИББС, но не воспринимайте его как норматив. Это доказательная база и набор best practices, которые аудиторы воспринимают положительно.

Как превратить OWASP из документа в рабочий инструмент:

1. Постройте карту артефактов OWASP под свой стек и риски.
2. Интегрируйте артефакты в процессы от архитектуры до мониторинга.
3. Раз в год делайте пересмотр требований и тестов под новые версии стандартов и угроз.

OWASP ценен только тогда, когда он живёт в коде, пайплайнах и культуре команды. В противном случае он останется красивым документом в корпоративном вики и бесполезным для реальной защиты.