Сценарий 14: расследование инцидента ИБ

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

Начните с ограниченного вопроса

Укажите CVE, уязвимую функцию, открытый endpoint или наблюдаемый путь эксплуатации. Привяжите вопрос к карточке инцидента, ревизии исходников, затронутой среде и времени наблюдения. Не передавайте секреты, учётные данные, клиентские payload или неограниченные журналы.

Для проактивной гипотезы, не связанной с активным инцидентом, используйте отдельный процесс проверки гипотез безопасности. Это не точка входа сценария 14.

Запуск отдельной CLI-команды

Подготовьте окружение по руководству CLI. Выполняйте команду в PowerShell из корня репозитория CodeGraph. Нужны существующий CPG и доступный сервис GoCPG gRPC. Замените обозначения в кавычках. Для CLI укажите реальное имя уязвимой функции: команда передаёт запрос напрямую в анализ графа вызовов и не преобразует описание CVE в имя символа.

python -m src.cli security incident "<function-name>" --db "<cpg-path>" --format json

Параметр --max-depth ограничивает глубину графа вызовов. Сохраняйте вместе команду, ревизию CPG, запрос и вывод. Без --db команда завершается закрыто с сообщением security incident requires explicit --db for CPG access.

JSON команды содержит query, direct_callers, transitive_callers, impact_score и entry_points. CLI не формирует находки по распространению недоверенных данных и не доказывает возможность эксплуатации. Код 0 означает завершение команды, а не устранение инцидента. Код 1 может означать отсутствие области графа или ошибку анализа.

Как CLI строит отчёт

Команда передаёт имя функции анализатору графа вызовов. Анализатор находит её прямых вызывающих методов, затем проходит цепочки вызовов вверх до глубины --max-depth. Так можно перейти от места дефекта к обработчикам, через которые код используется в приложении.

Оценка impact_score показывает долю затронутых методов относительно 10% методов графа. Анализатор считает уникальные методы в цепочках вызывающих и вызываемых функций, делит это число на total_methods * 0.1 и ограничивает результат значением 1. Например, для графа из 1000 методов и 25 затронутых методов оценка равна 0,25.

При числе прямых вызывающих методов свыше 100 анализ влияния считает затронутые методы по прямым связям. В этой ветви transitive_callers в отчёте пуст: прямые вызывающие методы уже представлены в direct_callers. Поиск entry_points выполняется отдельным обходом до --max-depth.

Для entry_points анализатор выбирает вызывающие методы без входящих вызовов (fan_in = 0), методы с характерными именами обработчиков и точки входа, заданные плагином языка или предметной области. Например, для цепочки route_handler → parse_request → decode_payload исследование decode_payload помогает найти обработчик и промежуточный парсер. Сопоставьте цепочку с маршрутизацией приложения, форматом входа и тестами обработки недоверенных данных.

Запуск типизированного сценария AppSec

Используйте ролевой маршрут при наличии управляемой задачи AppSec и runtime-контекста:

from src.digital_employees.runtime.scenarios import (
    RoleBoundScenarioInvocationRequest,
    invoke_role_bound_scenario_request,
)

request = RoleBoundScenarioInvocationRequest(
    query="Проследи вызывающие функции и точки входа до уязвимого парсера.",
    employee_id="codegraph_appsec",
    scenario_id="scenario_14",
    event_type="appsec_start",
    context={
        "project_key": "codegraph",
        "namespace": "default",
        "task_id": "<task-id>",
        "source_refs": ["<incident-ref>", "<revision-ref>"],
        "file_paths": ["<bounded-source-path>"],
    },
)
result = invoke_role_bound_scenario_request(request)
if result.get("error"):
    raise RuntimeError(result["error"])
if not result.get("scenario_id") or not result.get("answer"):
    raise RuntimeError("Scenario returned no scenario identity or answer")
print(result["answer"])

CLI и ролевой маршрут — разные носители свидетельств. Для каждой находки фиксируйте, какой маршрут её создал.

Как читать результат

Результат помогает расставить приоритеты ручной проверки прямых и транзитивных вызовов, точек входа, уязвимых использований, путей атаки и наблюдений taint flow. Критические пути проверьте в привязанных исходниках и затронутой среде.

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

От анализа к реагированию

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

Оперативный план указывает, кто меняет секреты, ограничивает трафик, выпускает исправление и уведомляет участников. Цепочки вызовов из CodeGraph помогают выбрать затронутые обработчики и проверки для этого плана.

Ошибки и восстановление

• Явная база отклонена или недоступна: остановитесь и восстановите CPG нужной ревизии.
• Функция не найдена: проверьте точный символ, покрытие языка, точку входа и глубину обхода.
• Результат частичный или резервный: пометьте его как предварительный и получите исходные или runtime-свидетельства.
• Идёт активная эксплуатация или среда небезопасна: следуйте процессу командования инцидентом заказчика, не ожидая завершения анализа CodeGraph.

Связанные материалы

• Каталог сценариев
• Аудит безопасности
• Модель угроз
• Сценарий 09: ревью кода