Автоматизированное расследование инцидентов безопасности с использованием анализа графа вызовов, трассировки потоков данных и визуализации путей атаки.
Обзор¶
Обработчик инцидентов анализирует уязвимости безопасности, прослеживая пути атаки от точек входа до уязвимых функций. Обработчик доменно-агностичен — все специфичные для языка данные (имена функций, шаблоны, точки входа) загружаются динамически из активного доменного плагина через DomainRegistry.
Конвейер анализа:
- Анализ запроса — извлечение уязвимой функции, сопоставление ключевых слов с категориями анализа
- Обнаружение уязвимостей — поиск критических функций через запросы к CPG
- Анализ потоков данных — трассировка от источников к приёмникам через
DataFlowTracer - Трассировка путей атаки — поиск точек входа и кратчайших цепочек вызовов через
CallGraphAnalyzer - LLM-анализ — генерация отчёта об инциденте с рекомендациями по устранению
Ключевые компоненты:
| Компонент | Роль |
|---|---|
CallGraphAnalyzer |
Обнаружение точек входа (fan_in=0), трассировка путей атаки, PageRank |
DataFlowTracer |
Анализ потоков данных (источник → приёмник) |
DomainRegistry |
Доменные маппинги функций, источники/приёмники, точки входа |
LLMInterface |
Генерация отчёта об инциденте на естественном языке |
render_attack_path_mermaid() |
Визуализация путей атаки в виде Mermaid-диаграмм |
Быстрый старт¶
# Выберите сценарий реагирования на инцидент
/select 14
CLI¶
python -m src.cli audit --db data/projects/myproject.duckdb --language ru
MCP (ИИ-ассистент)¶
codegraph_query(query="Проследить влияние CVE-2023-XXXX в parse_input", scenario_id="scenario_14")
Расследование инцидента¶
Анализ воздействия CVE¶
> Анализ воздействия уязвимости CVE-2023-XXXX в функции validate_input
╭─────────────── Анализ воздействия CVE ─────────────────────────╮
│ │
│ CVE: CVE-2023-XXXX │
│ Уязвимость: Переполнение буфера в функции validate_input() │
│ Степень серьёзности: КРИТИЧЕСКАЯ (CVSS 9.8) │
│ │
│ Уязвимая функция: │
│ validate_input() │
│ Расположение: src/server/parser/input.c:234 │
│ │
│ Поверхность атаки: │
│ Точки входа: 3 │
│ - handle_request() [Доступно по сети] │
│ - api_process_message() [API-эндпоинт] │
│ - do_internal_call() [Внутреннее API] │
│ │
│ Путь эксплуатации: │
│ Клиент → read_message() → handle_request() │
│ → validate_input() [УЯЗВИМА] │
│ │
│ Радиус поражения: │
│ Прямые вызовы: 5 │
│ Косвенное воздействие: 156 функций │
│ │
╰───────────────────────────────────────────────────────────────╯
Отслеживание путей эксплуатации¶
> Найти все пути от сетевого ввода до уязвимой функции
╭─────────────── Пути эксплуатации ──────────────────────────╮
│ │
│ Пути от сети к уязвимому коду: │
│ │
│ Путь 1 (Прямой, 3 перехода): │
│ handle_request() → parse_command() │
│ → validate_input() ⚠️ │
│ │
│ Путь 2 (API-маршрут, 4 перехода): │
│ api_process_message() → route_handler() │
│ → parse_command() │
│ → validate_input() ⚠️ │
│ │
│ Путь 3 (Расширенный протокол, 5 переходов): │
│ on_connection() → dispatch_command() │
│ → route_handler() │
│ → parse_command() │
│ → validate_input() ⚠️ │
│ │
│ Всего уязвимых путей: 3 │
│ │
╰────────────────────────────────────────────────────────────╯
Трассировка путей атаки¶
CodeGraph автоматически обнаруживает точки входа и прослеживает кратчайшие цепочки вызовов от каждой точки входа до уязвимости. Пути атаки ранжируются по усилению риска и визуализируются как Mermaid-диаграммы.
Обнаружение точек входа¶
Точки входа определяются с помощью комбинации эвристик:
- Методы с fan_in = 0 (нет вызывающих — вероятно, корни API или main-функции)
- Методы, соответствующие шаблонам: main, handle_*, on_*, api_*, route_*, test_*, do_*, cmd_*, serve_*, dispatch_*
- Функции точек входа из доменного плагина (через DomainRegistry.get_entry_point_functions())
Усиление риска¶
Каждый путь атаки получает оценку риска:
- Короткие пути = высокий риск (прямой доступ к уязвимости)
- Точки входа с высоким fan_in = несколько повышенный риск (более экспонированы)
- Формула: (1 / max(chain_length, 1)) * (1 + fan_in * 0.1)
Отчёт о радиусе поражения включает attack_paths, entry_points_count и most_exposed_entry_point.
Диаграмма пути атаки¶
> Проследить пути атаки к уязвимости strcpy
╭─────────────── Пути атаки ───────────────────────────────╮
│ │
│ Цепочки вызовов от точки входа до уязвимости │
│ │
│ | Точка входа | Уязвимость | Длина | Риск |│
│ |-------------------|------------|-------|-------------|│
│ | handle_request | strcpy | 3 | 1.000 |│
│ | api_process | strcpy | 4 | 0.500 |│
│ | do_internal_call | strcpy | 5 | 0.200 |│
│ │
│ Путь 1: │
│ │
│ ```mermaid │
│ graph TD │
│ N0["handle_request (api.c:45)"]:::entry │
│ N1["parse_command"] │
│ N2["strcpy (parser.c:120)"]:::vuln │
│ N0 --> N1 --> N2 │
│ classDef entry fill:#69f,stroke:#333 │
│ classDef vuln fill:#f33,stroke:#333 │
│ ``` │
│ │
│ Наиболее уязвимая точка входа: handle_request │
│ │
╰───────────────────────────────────────────────────────────╯
Анализ устранения уязвимостей¶
Поиск похожих уязвимостей¶
Обработчик использует LLM-анализ в сочетании с контекстом графа вызовов для выявления потенциально похожих паттернов уязвимостей. LLM получает данные о потоках данных, цепочках вызовов и метаданные уязвимости для анализа похожих мест в коде. Это не AST-детекция клонов — результаты носят рекомендательный характер и требуют ручной проверки.
> Поиск схожих шаблонов, которые могут содержать ту же уязвимость
╭─────────────── Анализ шаблонов ────────────────────────────╮
│ │
│ LLM-анализ похожих паттернов │
│ │
│ Шаблон: Копирование строки без ограничения из сетевого ввода │
│ │
│ Потенциально похожие места (требуется проверка): │
│ │
│ 🔴 ВЫСОКИЙ РИСК (тот же шаблон): │
│ src/server/parser/grammar.c:567 │
│ src/server/core/main.c:890 │
│ src/server/commands/copy.c:234 │
│ │
│ 🟡 СРЕДНИЙ РИСК (похожий шаблон): │
│ src/server/replication/sender.c:456 │
│ src/server/auth/handler.c:789 │
│ │
│ ⚠ Результаты сгенерированы LLM и требуют ручной проверки │
│ │
╰────────────────────────────────────────────────────────────╯
Оценка влияния исправления¶
> Оценка влияния предлагаемого исправления
╭─────────────── Влияние исправления ────────────────────────╮
│ │
│ Предлагаемое исправление: Добавить проверку границ │
│ в validate_input() │
│ │
│ Место внесения исправления: │
│ Файл: src/server/parser/input.c │
│ Строки: 234-240 │
│ │
│ Функциональное влияние: │
│ - Длина ввода теперь ограничена MAX_INPUT_SIZE │
│ - Для слишком длинных входных данных возвращается ошибка │
│ │
│ Радиус поражения (из графа вызовов): │
│ - Прямые вызовы: 5 │
│ - Транзитивные вызовы: 156 │
│ - Затронутые точки входа: 3 │
│ │
│ Уровень риска: НИЗКИЙ │
│ - Только защитная проверка │
│ - Нет изменений в поведении для корректных данных │
│ │
╰────────────────────────────────────────────────────────────╯
Анализ цифровых следов¶
Отследить затронутые данные¶
Секция анализа цифровых следов генерируется LLM на основе контекста уязвимости, данных о потоках и информации из графа вызовов. LLM анализирует потенциальное раскрытие данных, уровни привилегий и признаки компрометации. Результаты носят рекомендательный характер — это экспертный анализ, а не вычисляемые факты из кодовой базы.
> Какие данные могли быть получены с использованием этой уязвимости?
╭─────────────── Анализ доступа к данным ────────────────────────╮
│ │
│ LLM-анализ цифровых следов │
│ │
│ Возможное раскрытие данных (на основе контекста потоков): │
│ │
│ Доступные области памяти: │
│ ├── Буфер входных данных (прямой доступ) │
│ ├── Состояние соединения (смежная память) │
│ ├── Токены аутентификации (тот же контекст) │
│ └── Другие данные сессии (кадры стека) │
│ │
│ Уровень привилегий: │
│ - Запускается как: серверный процесс │
│ - Может получить доступ: ко всем файлам данных │
│ - Не может получить доступ: на уровне ОС без эскалации │
│ │
│ Признаки компрометации: │
│ - Запросы с необычным двоичным содержимым │
│ - Неожиданные ошибки выделения памяти │
│ - Логи сбоев с validate_input в трассировке стека │
│ │
│ ⚠ Этот анализ сгенерирован LLM и носит рекомендательный │
│ характер │
│ │
╰───────────────────────────────────────────────────────────────╯
Хронология инцидента¶
Сформировать отчёт об инциденте¶
> Сформировать отчёт по реагированию на инцидент
╭─────────────── Отчёт об инциденте ─────────────────────────────╮
│ │
│ ОТЧЁТ ОБ ИНЦИДЕНТЕ БЕЗОПАСНОСТИ │
│ Сформирован: 2024-12-20 14:30 UTC │
│ │
│ Краткое описание уязвимости: │
│ Тип: Переполнение буфера (CWE-120) │
│ Степень серьёзности: КРИТИЧЕСКАЯ │
│ Затронуто: validate_input() в input.c │
│ │
│ Результаты анализа: │
│ Критические уязвимости: 3 │
│ Пути потоков данных: 12 │
│ Прослежено путей атаки: 3 │
│ Наиболее уязвимая точка входа: handle_request │
│ │
│ Меры устранения: │
│ 1. Добавить проверку границ в validate_input() │
│ 2. Проверить аналогичные участки кода (5 мест) │
│ 3. Обновить документацию по безопасности │
│ │
╰───────────────────────────────────────────────────────────────╯
Примеры вопросов¶
- «Проследить влияние [CVE] в [функции]»
- «Найти пути эксплуатации для [функции]»
- «Проследить пути атаки к [уязвимой функции]»
- «Найти точки входа, которые ведут к [функции]»
- «Найти похожие шаблоны уязвимостей»
- «Какие данные можно получить через [уязвимость]?»
- «Оценить влияние исправления на [функцию]»
- «Создать отчёт по инциденту»
Связанные сценарии¶
- Аудит безопасности — Проактивный анализ безопасности
- Точки входа — Картирование поверхности атаки
- Проверка кода — Проверка исправлений безопасности