Интерпретация оповещений из средств сканера

  • 11 мин

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

Общие сведения о серьезности уязвимостей

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

Система оценки CVSS

Общая система оценки уязвимостей (CVSS) предоставляет стандартные числовые оценки, указывающие на серьезность уязвимостей.

Категории метрик CVSS:

  • Базовые метрики: Встроенные характеристики уязвимостей, не зависящие от определенных сред.
  • Временные метрики: Характеристики уязвимостей, изменяющиеся с течением времени (доступность эксплойтов, доступность исправлений, достоверность).
  • Метрики окружающей среды: Характеристики уязвимостей, характерные для конкретных сред и развертываний.

Вычисление базовой оценки CVSS версии 3: Базовые оценки объединяют несколько метрик:

Метрики эксплуатируемости:

  • Вектор атаки (AV): Сеть (N), смежная (А), локальная (L) или физическая (P).
  • Сложность атаки (AC): Низкая (L) или высокая (H) трудность при использовании уязвимости.
  • Необходимые привилегии (PR): Никакие (N), Низкие (L) или Высокие (H) привилегии, необходимые для эксплуатации.
  • Взаимодействие с пользователем (пользовательский интерфейс): Нет (N) или обязательный (R) для успешной эксплуатации.

Метрики влияния:

  • Влияние конфиденциальности (C): Нет (N), низкое (L) или высокое (H) раскрытие информации.
  • Влияние целостности (I): Нет (N), низкая (L) или высокая (H) возможность изменения данных.
  • Влияние на доступность (A): Отсутствует (N), низкий (L) или высокий (H) перебой в работе службы.

Пример вектора CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

Классификации серьезности

Оценки CVSS сопоставляют с рейтингами серьезности:

Severity Оценка CVSS Описание Приоритет
Критический 9.0 - 10.0 Легко эксплуатируемые уязвимости, вызывающие широко распространенную компрометацию системы. Требуется немедленное исправление.
High 7.0 - 8.9 Серьезные уязвимости, обеспечивающие значительное раскрытие информации или нарушение работы службы. Исправление требуется в течение нескольких дней.
Medium 4.0 - 6.9 Умеренные уязвимости с ограниченной эксплуатируемостью или воздействием. Исправление необходимо в течение нескольких недель.
Low 0.1 - 3.9 Незначительные уязвимости с минимальным воздействием на безопасность. Исправление по мере удобства.
Нет 0,0 Информационные результаты без фактического влияния на безопасность. Необязательное устранение.

Примеры интерпретации серьезности:

Критическая уязвимость (CVSS 10.0):

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

Высокая уязвимость (CVSS 8.1):

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

Средняя уязвимость (CVSS 5.9):

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

Оценка эксплойтируемости

Оценки CVSS не сообщают полную историю: оценка эксплойтируемости определяет фактический риск:

Зрелость эксплойтов

Этапы доступности эксплойтов:

Недоказанный:

  • Статус: Теоретические уязвимости без известных эксплойтов.
  • Уровень риска: Более низкий риск — эксплуатация требует значительных усилий злоумышленника.
  • Действие: Мониторинг разработки эксплойтов; планирование исправления, но не срочно.

Доказательство концепции:

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

Функциональный:

  • Статус: Общедоступный рабочий код эксплойтов.
  • Уровень риска: Высокий риск — эксплуатация, доступная для умеренно квалифицированных злоумышленников.
  • Действие: Ускорить устранение; реализуйте временные меры, если применение патча задерживается.

Активная эксплуатация:

  • Статус: Уязвимость активно эксплуатируется в дикой природе.
  • Уровень риска: Критический риск — использование происходит в данный момент.
  • Действие: Экстренные меры по устранению; используйте немедленные меры по устранению рисков; отслеживайте наличие компрометации.

Пример оценки эксплойтности:

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

Анализ поверхности атаки

Определите, является ли уязвимость доступной:

Факторы доступности:

  • Использование кода: Фактически ли уязвимый путь кода выполняется приложением?
  • Воздействие сети: Предоставляется ли уязвимый компонент сетевому доступу?
  • Требования к проверке подлинности: Требуется ли для эксплуатации доступ с проверкой подлинности?
  • Зависимости конфигурации: Требует ли уязвимость использования определенных конфигураций?

Пример доступности:

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

Контекст среды

Рассмотрим конкретную среду:

Сегментация сети:

  • Доступ к Интернету: Уязвимости в компонентах, подключенных к Интернету, имеют наивысший приоритет.
  • Внутренняя сеть: Внутренние уязвимости имеют более низкий приоритет, если сеть сегментирована.
  • Изолированные системы: Системы с воздушным зазором или другими формами изоляции имеют минимальный риск от уязвимостей сети.

Конфиденциальность данных:

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

Компенсирующие элементы управления:

  • Брандмауэр веб-приложения: Правила WAF могут препятствовать попыткам эксплуатации.
  • Обнаружение вторжений: IdS/IPS может обнаруживать и блокировать попытки эксплуатации.
  • Сегментация сети: Сетевая изоляция ограничивает влияние эксплуатации уязвимостей.
  • Наименьшие привилегии: Ограниченные разрешения снижают влияние эксплуатации.

Управление ложными срабатываниями

Не все обнаруженные уязвимости на самом деле влияют на приложения:

Распространенные ложные положительные причины

Ошибочно идентифицированные компоненты:

  • Конфликты именования: Разные компоненты с похожими именами неправильно совпадают.
  • Ошибки обнаружения версий: Неправильная идентификация версии, приводящая к совпадениям ложной уязвимости.
  • Путаница пространственной идентификации пакета: Пакеты в разных экосистемах неправильно идентифицированы как один и тот же пакет.

Пример ложноположительный:

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

Неиспользуемые пути кода:

  • Мертвый код: Уязвимый код импортирован, но никогда не выполнялся.
  • Необязательные функции: Уязвимости в необязательных функциях, которые приложение не включает.
  • Зависимости разработки: Уязвимости в пакетах, используемых только во время разработки, а не в рабочей среде.

Ошибки диапазона версий:

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

Ложноположительная проверка

Процесс исследования:

  1. Проверьте удостоверение компонента: Убедитесь, что сканер правильно определил компонент.
  2. Проверьте точность версии: Убедитесь, что обнаруженная версия соответствует фактической развернутой версии.
  3. Просмотрите сведения об уязвимостях: Узнайте, что влияет на уязвимость.
  4. Анализ использования кода: Определите, используются ли уязвимые пути кода.
  5. Обратитесь к консультантам по поставщикам: Проверьте, предоставляет ли поставщик дополнительный контекст.
  6. Тестовая эксплуатация: Попытайтесь воспроизвести уязвимость в тестовой среде.

Требования к документации: При подавлении ложных срабатываний документируйте:

  • Обоснование: Почему обнаружение является ложным срабатыванием.
  • Сведения о расследовании: Действия, предпринятые для проверки ложноположительных результатов.
  • Утверждающий: Член команды безопасности одобряет подавление.
  • Дата проверки: Дата повторной оценки подавления.

Пример файла исключений (OWASP Dependency-Check):

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

Платформы приоритета

Для эффективного управления уязвимостями требуется системная приоритетность:

Определение приоритета на основе рисков

Факторы приоритета:

Оценка серьезности (25% вес):

  • Базовая оценка CVSS предоставляет основу для оценки рисков.
  • Более высокие оценки указывают на более серьезные потенциальные последствия.

Эксплуатируемость (35% вес):

  • Состояние активной эксплуатации является наиболее важным фактором.
  • Доступность общедоступных эксплойтов значительно повышает риск.
  • Доказательства концепции эксплойтов указывают на возможное использование.

Критичность активов (20% вес):

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

Экологические факторы (20% вес):

  • Существующие компенсирующие элементы управления снижают эффективный риск.
  • Сегментация сети ограничивает радиус взрыва.
  • Возможности мониторинга позволяют обнаруживать угрозы.

Матрица приоритета:

Эксплойтируемость Критический уровень серьезности Высокий уровень серьезности Средняя серьезность Низкая серьезность
Активная эксплуатация P0 (экстренное реагирование) P0 (экстренное реагирование) P1 (критическое) P2 (высокий)
Функциональный эксплойт P0 (экстренное реагирование) P1 (критическое) P2 (высокий) P3 (средний)
Доказательство концепции P1 (критическое) P2 (высокий) P3 (средний) P4 (низкий уровень)
Недоказанной P2 (высокий) P3 (средний) P4 (низкий) P5 (необязательно)

Исправление соглашений об уровне обслуживания

Определите соглашения уровня обслуживания для исправления:

Аварийное реагирование (P0):

  • Временной интервал: Немедленно (в течение 24 часов).
  • Критерии: Критически важные уязвимости в активной эксплуатации в системах, подключенных к Интернету.
  • Процесс: Процесс аварийного изменения с уведомлением руководства.
  • Пример: Log4Shell (CVE-2021-44228) в общедоступном приложении.

Критическое (P1):

  • Временной интервал: 7 дней.
  • Критерии: Высокий/критический уровень серьезности с функциональными эксплойтами или доступом к Интернету.
  • Процесс: Ускоренная обработка изменений с помощью координации группы безопасности.
  • Пример: Внедрение SQL в интерфейсе администрирования с проверкой подлинности.

Высокий (P2):

  • Временной интервал: 30 дней.
  • Критерии: средняя или высокая степень серьёзности с эксплуатациями для доказательства концепции или внутренним воздействием.
  • Процесс: Стандартный процесс изменения с запланированным периодом обслуживания.
  • Пример: Межсайтовые скрипты (XSS) на внутренней панели мониторинга.

Средний (P3):

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

Низкий (P4):

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

Установление порога ошибок безопасности

Панели ошибок безопасности определяют минимальные стандарты безопасности, которые должны соответствовать:

Определение критериев готовности

Пример панели ошибок безопасности:

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

Принудительное применение политики

Шлюз качества Azure Pipelines:

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

Рабочий процесс обработки уязвимостей

Систематическая сортировка обеспечивает эффективное управление уязвимостями.

Процесс сортировки

Шаг 1. Автоматическая фильтрация:

  • Средства проверки: Автоматически фильтруйте уязвимости по серьезности.
  • Анализ доступности: Удалите неустранимые уязвимости из очереди триажа.
  • Известные ложные срабатывания: Автоматическое подавление ранее выявленных ложных срабатываний.

Шаг 2. Начальная оценка:

  • Проверка серьезности: Проверьте точность оценки CVSS для вашей среды.
  • Проверка эксплойтируемости: Определение доступности эксплойтов и активной эксплуатации.
  • Идентификация активов: Определите, какие приложения и системы затронуты.

Шаг 3. Оценка рисков:

  • Влияние на бизнес: Оцените потенциальные последствия успешной эксплуатации в бизнесе.
  • Анализ воздействия: Определите уязвимость сети и область атаки.
  • Компенсирующие элементы управления: Определите существующие способы снижения риска.

Шаг 4. Приоритет:

  • Назначьте приоритет: Используйте матрицу приоритетов для назначения приоритета исправления.
  • Установка срока исполнения: Назначьте крайний срок исправительных действий на основе SLA.
  • Назначьте владельца: Определите ответственную команду для устранения проблемы.

Шаг 5. Отслеживание исправления:

  • Создание билетов: Создание рабочих элементов в системе отслеживания (Jira, Azure Boards).
  • Мониторинг прогресса: Отслеживайте прогресс исправления против крайних сроков.
  • Проверка: Проверьте успешное исправление с помощью повторного сканирования.

Частота каденции собраний триажа

Еженедельная проверка безопасности:

  • Участники: Команда безопасности, руководители разработки, представители операционной команды.
  • Повестка дня: Просмотрите новые высококритичные результаты, отслеживайте ход исправления, корректируйте приоритеты.
  • Длительность: 30–60 минут.

Ежемесячный обзор уязвимостей:

  • Участников: Руководство по безопасности, управление инженерами, группа соответствия требованиям.
  • Повестка дня: Просмотрите тенденции, настройте политики, оцените общую безопасность.
  • Длительность: 60-90 минут.

Метрики и отчеты

Отслеживание эффективности управления уязвимостями:

Основные метрики

Метрики уязвимостей:

  • Среднее время обнаружения (MTTD): Время от раскрытия уязвимостей до обнаружения в системах.
  • Среднее время исправления (MTTR): Время от обнаружения до успешной исправления.
  • Плотность уязвимостей: Количество уязвимостей для каждого приложения или строки кода.
  • Частота исправления: Процент уязвимостей, исправленных в рамках SLA.

Метрики тренда:

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

Пример панели мониторинга

Панель мониторинга управления уязвимостями:

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

Замечание

Дополнительные сведения о соглашениях об уровне обслуживания (SLA) и сроках исправления см. в разделе соглашения об уровне обслуживания Azure.

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