CVSS 9.8 на уязвимости в изолированном сервере тестирования и CVSS 6.5 на внешнем веб-портале с обработкой платежей — это не парадокс оценки, а два разных мира. Внешняя оценка критичности работает в вакууме, а реальная приоритизация начинается там, где технический балл сталкивается с бизнес-контекстом, наличием публичного эксплойта и требованиями регулятора. https://seberd.ru/ataka-dnya
Как устроена базовая механика CVE и CVSS
Процесс начинается со сканера уязвимостей. Регулярный обход операционных систем, сетевого оборудования, прикладного ПО. При обнаружении несоответствия система присваивает проблеме уникальный идентификатор CVE. Этот номер служит универсальным каталожным обозначением, позволяющим разным специалистам и инструментам ссылаться на одну и ту же проблему.
Сам по себе идентификатор CVE не говорит о степени опасности. Для количественной оценки используется система CVSS. Калькулятор анализирует несколько параметров. Вектор атаки определяет, требуется ли злоумышленнику физический доступ или атака возможна удаленно через сеть. Сложность эксплуатации оценивает, нужны ли специальные условия или предварительные знания для успешного применения уязвимости. Влияние измеряет ущерб для конфиденциальности, целостности и доступности данных.
Результатом вычислений становится число от нуля до десяти. Сканеры часто используют эти цифры для сортировки отчетов. Команды безопасности видят список из сотен проблем, отсортированных по убыванию балла. Подобный подход создает иллюзию порядка. На практике слепое следование цифрам приводит к распылению ресурсов. Администраторы тратят дни на устранение критических уязвимостей в изолированных внутренних системах, игнорируя умеренные риски на серверах, напрямую доступных из интернета.
Переломный момент — появление доказательства концепции
Оценка CVSS описывает потенциал угрозы. Реальность диктует другие правила. Ключевым фактором, радикально меняющим приоритет реакции, становится наличие доказательства концепции или PoC.
До публикации PoC уязвимость остается теоретической. Злоумышленник должен самостоятельно изучать код, искать обходные пути и разрабатывать метод применения. Подобная задача требует высокой квалификации и времени. Многие организации в таких случаях планируют исправление в рамках регулярного цикла обновлений.
Публикация доказательства концепции снимает барьер входа. Исследователи или злоумышленники предоставляют работающий код, демонстрирующий успешную эксплуатацию. Наличие рабочего эксплойта превращает сложную исследовательскую задачу в выполнение готового скрипта. Критичность проблемы мгновенно возрастает, независимо от первоначального балла CVSS. Уязвимость с оценкой 6.5 и публичным эксплойтом часто требует более срочного вмешательства, чем проблема с оценкой 9.0, для которой способ применения все еще неизвестен.
| Статус уязвимости | Характеристика | Требуемая реакция команды |
|---|---|---|
| Теоретическая уязвимость | Описана в базе CVE, эксплойт отсутствует | Плановое обновление в рамках стандартного графика |
| Опубликован PoC | Предоставлен код, демонстрирующий принцип атаки | Ускоренная проверка применимости и подготовка патча |
| Доступен рабочий эксплойт | Существуют автоматизированные инструменты атаки | Экстренное закрытие или применение временных мер защиты |
Системы мониторинга угроз и ленты безопасности играют здесь решающую роль. Аналитики должны отслеживать не только появление новых записей CVE, но и активность в сообществах исследователей. Появление упоминаний конкретной уязвимости в инструментах сканирования или на форумах служит триггером для пересмотра приоритетов.
Наложение внешней оценки на внутренние бизнес-риски
Универсальная оценка CVSS имеет фундаментальный недостаток. Она не знает топологию вашей сети. Калькулятор не учитывает, защищен ли уязвимый сервер межсетевым экраном, требует ли он аутентификации или обрабатывает платежные данные клиентов.
Внутренняя приоритезация обязана корректировать внешнюю оценку на основе бизнес-контекста. Рассмотрим два сценария. Первый сценарий описывает внутренний сервер тестирования с уязвимостью удаленного выполнения кода, имеющей оценку CVSS 9.8. Доступ к этому серверу возможен только из защищенной подсети разработчиков, а сами данные не представляют коммерческой ценности. Второй сценарий описывает внешний веб-сервер, обрабатывающий авторизацию пользователей. На нем обнаружена уязвимость обхода аутентификации с оценкой CVSS 6.5.
Внешние сканеры пометят первый сервер как приоритетный. Внутренняя логика управления рисками требует немедленного внимания ко второму серверу. Успешная атака на внешний ресурс приведет к компрометации учетных записей клиентов и репутационным потерям. Атака на внутренний тестовый сервер не выйдет за пределы изолированного сегмента.
Матрица приоритезации строится на пересечении двух осей. Первая ось отражает техническую возможность эксплуатации, включая наличие эксплойта. Вторая ось отражает ценность актива и его доступность для потенциального злоумышленника. Пересечение высокого значения по обеим осям формирует критический приоритет, требующий немедленных действий.
Требования регулятора к управлению уязвимостями в госсекторе
В коммерческом секторе управление уязвимостями часто остается на усмотрение команды безопасности. В госсекторе и критической инфраструктуре регулятор задает жесткие рамки. Приказ ФСТЭК № 117 устанавливает требования к обеспечению защиты информации в информационных системах государственных и муниципальных органов. В части управления уязвимостями документ требует регулярного анализа защищенности, контроля конфигураций, использования сертифицированных средств защиты и документирования всех этапов работы с уязвимостями.
Методический документ ФСТЭК от 12 мая 2026 года по выявлению уязвимостей недекларированных возможностей в программном обеспечении формализует процесс еще глубже. Документ вводит три уровня контроля — низкий, средний и высокий. Каждый уровень определяет набор обязательных видов анализа и требования к объемам проверки.
Методический документ от 12 мая 2026 г.
588 КБПросмотр и масштаб — в отдельной вкладке браузера; здесь только превью страницы.
На низком уровне контроля достаточно анализа архитектуры статическими методами и динамического анализа. На среднем уровне добавляется статический анализ исходного кода и фаззинг-тестирование. На высоком уровне требуется полный комплект: анализ архитектуры обоими методами, статический анализ, динамический анализ, фаззинг и ручная экспертиза кода.
| Уровень контроля | Обязательные виды анализа | Минимальные требования к объемам |
|---|---|---|
| Низкий (1) | Анализ архитектуры (статический), динамический анализ | 50 тестовых сценариев, 3 сценария функциональных испытаний |
| Средний (2) | + Статический анализ исходного кода, фаззинг-тестирование | 10000 строк кода для статического анализа, 5 фаззинг-целей, покрытие не менее 25% |
| Высокий (3) | + Ручная экспертиза кода, расширенный фаззинг | Контрольная выборка не менее 20 предупреждений анализатора, покрытие не менее 50-90% по базовым блокам |
Методичка требует представления результатов в машиночитаемом формате CycloneDX версий 1.6 или 1.7. Каждый программный компонент описывается с атрибутами, которые помогают приоритизировать уязвимости. Атрибут attack_surface указывает, входит ли компонент в непосредственную поверхность атаки (значения yes, indirect, no). Атрибут security_function показывает, реализует ли компонент функции безопасности средства защиты. Атрибут source_langs фиксирует язык исходного кода. Атрибут provided_by указывает, каким сертифицированным средством защиты предоставлен компонент.
Подобная структуризация превращает абстрактный список CVE в карту рисков. Уязвимость в компоненте с attack_surface: yes и security_function: no требует немедленного внимания. Уязвимость в компоненте с attack_surface: no, который реализует функции безопасности (security_function: yes), тоже критична, но по другой причине — компрометация средства защиты.
Формирование соглашений об уровне обслуживания
Определение приоритетов бессмысленно без четких сроков реакции. Соглашения об уровне обслуживания устанавливают жесткие временные рамки для устранения проблем в зависимости от присвоенного внутреннего уровня критичности.
Критические уязвимости на системах, доступных из внешней сети, закрываются в течение 24 или 48 часов. Этот срок включает время на тестирование обновления в изолированной среде и его развертывание на продуктивных серверах. Высокий приоритет предполагает устранение в течение семи дней. Средние риски планируются на ежемесячный цикл обновлений. Низкие риски могут оставаться открытыми до следующего крупного релиза программного обеспечения или устраняться при плановой замене оборудования.
В госсекторе методичка ФСТЭК добавляет дополнительные требования к срокам. Результаты всех видов анализа фиксируются в протоколах исследований. Протоколы подписываются исследователем или группой исследователей, проводивших работу. Исследователи несут ответственность за выводы, сделанные ими по результатам проверенных исследований. Все выявленные уязвимости и меры по их устранению верифицируются в протоколах исследований в соответствии с формой, приведенной в методическом документе.
Процесс закрытия уязвимости не заканчивается установкой патча. Команда обязана вести журнал версий программного обеспечения. После применения обновления необходимо провести повторное сканирование. Это подтверждает фактическое устранение проблемы и фиксирует статус как исправленный.
Игнорирование контекста при управлении уязвимостями приводит к параличу процессов. Команды безопасности тонут в море алертов, пытаясь закрыть все проблемы с высоким баллом CVSS. Бизнес-подразделения сопротивляются постоянным простоям ради установки обновлений на некритичные системы. Эффективный процесс строится на постоянном диалоге между аналитиками угроз и владельцами инфраструктуры. Только совместная оценка технической возможности атаки и реального ущерба для бизнеса позволяет выделить ресурсы на устранение тех проблем, которые действительно угрожают организации.