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

Для архитекторов безопасности, инженеров AppSec и руководителей ИБ

Содержание¶

• Аннотация
• 1. Проблема
• 1.1 Ограничения традиционного SAST
• 1.2 Почему сопоставления шаблонов недостаточно
• 2. Методология
• 2.1 Многокритериальный подход
• 2.2 Гипотезный подход и сопоставление с шаблонами
• 2.3 Стратегия декартова произведения
• 3. Обзор архитектуры
• 3.1 Конвейер
• 3.2 Доменные провайдеры
• 3.3 Пресеты скоринга
• 4. Возможности V2
• 4.1 Квалификация доказательств
• 4.2 Обнаружение цепочек уязвимостей
• 4.3 Обратная связь от аналитиков
• 4.4 Инкрементальный анализ
• 4.5 Мониторинг трендов
• 5. Сценарии развёртывания
• 5.1 Анализ через CLI
• 5.2 Интеграция в CI/CD
• 5.3 Интеграция через REST API и MCP
• 6. Результаты валидации
• 6.1 Сравнение с традиционным SAST
• 6.2 Верификация потоков данных и проверка достижимости путей
• 7. Заключение и возврат инвестиций
• Связанные документы

Аннотация¶

Традиционные инструменты SAST страдают от доли ложных срабатываний 70–90%, что делает разбор находок основной статьёй затрат в программах безопасности приложений. CodeGraph решает эту проблему с помощью многокритериальной системы валидации гипотез, которая:

1. Генерирует тестируемые гипотезы из баз знаний CWE/CAPEC
2. Оценивает гипотезы по трём взвешенным критериям с учётом контекста кодовой базы
3. Верифицирует находки через анализ потоков данных на графе свойств кода (CPG)
4. Учитывает обратную связь аналитиков для подавления подтверждённых ложных срабатываний

Результат: 100% обнаружение CVE на целевых кодовых базах при снижении доли ложных срабатываний с 70–90% до менее 15% — повышение производительности аналитиков в 5–6 раз.

Справочник по API, модели данных и примеры кода: Справочник системы гипотез.

1. Проблема¶

1.1 Ограничения традиционного SAST¶

Традиционный SAST:
  Обнаружен шаблон: "strcpy"
  Результат: ВОЗМОЖНАЯ уязвимость
  Доля ложных срабатываний: 70-90%

CodeGraph:
  Гипотеза: Недоверенные данные из recv() поступают в strcpy()
  Доказательство: Путь потока данных верифицирован через CPG
  Результат: Уязвимость ПОДТВЕРЖДЕНА
  Доля ложных срабатываний: <15%

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

1.2 Почему сопоставления шаблонов недостаточно¶

2. Методология¶

2.1 Многокритериальный подход¶

Традиционная оценка уязвимостей использует один параметр (обычно базовый балл CVSS). Система гипотез CodeGraph оценивает три независимых критерия:

Распределение 40/30/30 отражает эмпирическое наблюдение: распространённость CWE — наиболее сильный предиктор реальных находок, но контекст кодовой базы и осуществимость атаки обеспечивают необходимое уточнение.

Бонусные множители дополнительно корректируют приоритет: известный шаблон CVE (+20%), критическая серьёзность (+10%), недавняя эксплуатация (+15%). Бонусы накапливаются — гипотеза, совпадающая с недавно эксплуатированным критическим CVE, получает усиление до 1.52x.

Полная формула скоринга, разбивка компонентов и API: Справочник системы гипотез — Многокритериальный скоринг

2.2 Гипотезный подход и сопоставление с шаблонами¶

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

2.3 Стратегия декартова произведения¶

Механизм генерации создаёт гипотезы из декартова произведения:

Гипотезы = База CWE (58 записей)
          × Шаблоны CAPEC (27 атак)
          × Языковые шаблоны (приёмники/источники/санитайзеры по фреймворкам)
          → Фильтрация по релевантности к кодовой базе
          → Оценка и ранжирование

Это обеспечивает всестороннее покрытие: каждая комбинация слабости, шаблона атаки и языковой опасной функции оценивается. Этап скоринга затем исключает нерелевантные комбинации — обычно сокращая тысячи теоретических гипотез до 20–50 высокоприоритетных кандидатов для выполнения.

3. Обзор архитектуры¶

3.1 Конвейер¶

+-------------------------------------------------------------------+
|            КОНВЕЙЕР ВАЛИДАЦИИ ГИПОТЕЗ                               |
+-------------------------------------------------------------------+

  [1] ГЕНЕРАЦИЯ ──> [2] СКОРИНГ ──> [3] СИНТЕЗ ЗАПРОСОВ
       CWE × CAPEC       3 критерия       SQL/PGQ-
       × Шаблоны          + бонусы         шаблоны
                              |
                              v
  [6] ОБРАТНАЯ   <── [5] ВАЛИДАЦИЯ <── [4] ВЫПОЛНЕНИЕ
      СВЯЗЬ           Подтвердить/       Выполнить
      Аналитик        Отклонить          на CPG

Каждый этап настраивается независимо и может выполняться изолированно. Например, пресеты скоринга позволяют задавать разные профили весов для встроенных систем, веб-приложений и корпоративного ПО.

Имена классов, сигнатуры конструкторов и детали методов: Справочник системы гипотез — Архитектура конвейера

3.2 Доменные провайдеры¶

Система поставляется с 6 специализированными доменными провайдерами, каждый из которых предоставляет приёмники, источники и санитайзеры, специфичные для фреймворка:

Дополнительно YAMLRuleProvider позволяет командам определять собственные правила в YAML-файлах конфигурации для внутренних фреймворков и проприетарных API.

Все провайдеры реализуют базовый интерфейс PatternProvider: get_sinks(), get_sources(), get_sanitizers().

3.3 Пресеты скоринга¶

Разные профили приложений требуют разных весов скоринга. Три встроенных пресета:

Пресет embedded акцентирует частоту CWE, поскольку встраиваемые системы имеют хорошо известные шаблоны уязвимостей (переполнения буфера, целочисленные переполнения), где исторические данные CWE высокопредиктивны. Пресет web акцентирует сходство с атакой, поскольку уязвимости веб-приложений более разнообразны и сопоставление с шаблонами атак лучше различает реальные угрозы.

Пресеты настраиваются через config.yaml → hypothesis.scoring.presets или передаются непосредственно в конструктор скорера.

4. Возможности V2¶

4.1 Квалификация доказательств¶

EvidenceQualifier обеспечивает многофакторную оценку достоверности каждого доказательства:

Гипотеза с has_taint_path=True, sanitizer_absent=True и user_facing_source=True получает оценку достоверности близкую к 1.0, что делает её высокоприоритетной находкой. Это заменяет бинарную оценку «найдено/не найдено» традиционных инструментов.

4.2 Обнаружение цепочек уязвимостей¶

ChainDetector выявляет цепочки повышения привилегий — последовательности, в которых эксплуатация уязвимости A делает возможной уязвимость B:

Пример цепочки:
  CWE-200 (раскрытие информации) → раскрывает схему памяти
    → CWE-125 (чтение за границами) → утечка значения канареечной переменной
      → CWE-120 (переполнение буфера) → достижение выполнения кода

Обнаружение: ChainDetector.detect(hypotheses) → List[VulnerabilityChain]

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

4.3 Обратная связь от аналитиков¶

FeedbackStore реализует постоянную обратную связь от аналитиков, повышающую точность скоринга со временем:

Аналитик помечает находку как ЛС
  → FeedbackStore.record_outcome(hypothesis_id, "false_positive")
  → Следующее сканирование: get_adjustment() применяет отрицательный вес
  → После N подтверждений: get_suppressed() автоматически подавляет

Аналитик подтверждает находку
  → FeedbackStore.record_outcome(hypothesis_id, "true_positive")
  → Следующее сканирование: похожие гипотезы получают повышение приоритета

Обратная связь хранится в локальной базе SQLite (~/.codegraph/hypothesis_feedback.sqlite) и сохраняется между запусками анализа. Это решает критическую проблему SAST: ложные срабатывания, которые появляются заново после каждого сканирования.

4.4 Инкрементальный анализ¶

IncrementalAnalyzer выполняет дельта-анализ на основе git diff — генерирует и оценивает гипотезы только для кода, изменённого между двумя коммитами:

IncrementalAnalyzer(db_path, source_path)
  .run_incremental(from_ref="v1.0", to_ref="HEAD")
  → Определяет изменённые файлы и функции
  → Генерирует гипотезы в области изменённого кода
  → Запускает полный конвейер скоринга + валидации
  → Возвращает: только новые/изменённые находки

Это делает гипотезный анализ практичным для CI/CD: полное сканирование 50 тыс. строк занимает ~30 секунд, но инкрементальное сканирование типичного PR (100–500 изменённых строк) завершается за 1–3 секунды.

4.5 Мониторинг трендов¶

HypothesisTrendStore отслеживает тренды уязвимостей по релизам:

record_run(project, commit, timestamp, results)
  → Сохраняет подтверждённые/отклонённые по категориям

get_trend(project, days=90)
  → Возвращает временные ряды: переполнение буфера, инъекции и т.д.

get_delta(project, from_commit, to_commit)
  → Возвращает: новые находки, исправленные находки, регрессии

Данные трендов позволяют формировать дашборды безопасности, показывающие, становится ли кодовая база более или менее защищённой со временем, какие категории CWE имеют восходящий тренд и оказывают ли конкретные меры исправления ожидаемый эффект.

5. Сценарии развёртывания¶

5.1 Анализ через CLI¶

Разовый анализ инженерами безопасности:

# Полная валидация гипотез
python -m src.cli hypothesis run --language C --max 50 --min-priority 0.3

# Список поддерживаемых CWE (опционально по категории)
python -m src.cli hypothesis list-cwes --category buffer_overflow

# Показать доступные доменные провайдеры
python -m src.cli hypothesis providers

# Вывод в JSON для автоматизации
python -m src.cli hypothesis run --language C --format json > results.json

5.2 Интеграция в CI/CD¶

Инкрементальный анализ при каждом запросе на слияние:

# .github/workflows/security-hypothesis.yml
- name: Анализ гипотез
  run: |
    python -m src.cli hypothesis run \
      --language C \
      --max 100 \
      --min-priority 0.3 \
      --format json > hypothesis_results.json

- name: Проверка критических находок
  run: |
    python -c "
    import json, sys
    data = json.load(open('hypothesis_results.json'))
    critical = [h for h in data.get('hypotheses', [])
                if h.get('priority_score', 0) > 0.8]
    if critical:
        print(f'ЗАБЛОКИРОВАНО: {len(critical)} критических находок')
        sys.exit(1)
    "

В инкрементальном режиме IncrementalAnalyzer ограничивает анализ только изменённым кодом, сокращая время выполнения в CI до секунд.

5.3 Интеграция через REST API и MCP¶

REST API:

POST /api/v1/security/hypotheses/run
  Тело: { "language": "C", "max_hypotheses": 50 }
  Ответ: { "hypotheses": [...], "metrics": {...} }

GET /api/v1/security/hypotheses/cwes?category=buffer_overflow
  Ответ: [{ "id": "CWE-120", "name": "Buffer Copy...", ... }]

GET /api/v1/security/hypotheses/providers
  Ответ: ["PostgreSQLPatternProvider", "DjangoPatternProvider", ...]

MCP (Model Context Protocol):

Инструмент: codegraph_hypothesis
  Параметры: language, max_hypotheses, min_priority_score
  Ответ: структурированные результаты для AI-ассистентов

6. Результаты валидации¶

6.1 Сравнение с традиционным SAST¶

Тестирование на кодовой базе PostgreSQL 17 (~1,3 млн строк C):

Ключевые наблюдения: - Шаблонный SAST производит в 15 раз больше ложных срабатываний, чем CodeGraph - Добавление верификации потоков данных (TaintVerifiedScanner) дополнительно снижает долю ЛС с 40% до 12% - Все три целевые CVE (CVE-2025-8713, CVE-2025-8714, CVE-2025-8715) обнаружены во всех конфигурациях — гипотезный скоринг не жертвует полнотой

Полные метрики и детали CVE: Справочник системы гипотез — Производительность

6.2 Верификация потоков данных и проверка достижимости путей¶

Два дополнительных уровня верификации снижают ложные срабатывания сверх скоринга:

Визуализация путей потоков данных. Подтверждённые гипотезы включают полные пути потоков данных: - Mermaid-диаграммы — интерактивные схемы от источника к приёмнику - SARIF 2.1.0 codeFlows — пошаговое распространение потоков данных для интеграции со средами разработки

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

Пример:
  Гипотеза: recv() → strcpy() может вызвать переполнение
  Анализ z3: путь требует buffer_size > 1024 И user_controlled = true
  Результат: ДОСТИЖИМ (нет противоречий) → гипотеза ПОДТВЕРЖДЕНА

  Гипотеза: getenv("DEBUG") → system()
  Анализ z3: путь требует DEBUG == "1" в производственной среде
  Результат: НЕДОСТИЖИМ (противоречит конфигурации) → гипотеза ОТКЛОНЕНА

Классификация OWASP Top 10. Все подтверждённые находки автоматически классифицируются по категориям OWASP Top 10 через owasp_mapping.py, обеспечивая отчётность по соответствию требованиям.

7. Заключение и возврат инвестиций¶

Бизнес-ценность¶

Система валидации гипотез CodeGraph обеспечивает измеримый результат:

Ключевые отличия¶

1. Контекстуальный анализ — учёт специфики конкретной кодовой базы
2. Верификация потоков данных — подтверждение потока через CPG, а не близость шаблонов
3. Приоритизация рисков — 3-критериальный скоринг с доменными пресетами
4. Обратная связь — решения аналитиков навсегда улучшают будущие сканирования
5. Инкрементальный режим — интеграция в CI/CD за секунды
6. Обнаружение цепочек — многоэтапные пути атак, невидимые для инструментов с одиночными находками
7. 6 доменных провайдеров — анализ с учётом фреймворка без настройки

Связанные документы¶

• Справочник системы гипотез — справочник по API, модели данных, примеры кода
• Обзор корпоративной безопасности — резюме для руководства
• Конкурентная матрица — сравнение с аналогами

Версия: 2.0 | Март 2026