Сценарий 16 ищет в CPG проекта внешние, сетевые, запросные, аутентификационные, файловые, процессные и связанные кандидаты в точки входа. Результат — attack-surface hypothesis для ревью AppSec, а не вердикт об уязвимости.
Когда применять
Сценарий отвечает на ограниченные вопросы:
- какие функции принимают сетевой или клиентский ввод;
- где в код входят границы аутентификации или привилегий;
- какие файловые, процессные или extension-интерфейсы расширяют поверхность атаки;
- какие кандидаты требуют дальнейшего data-flow или incident-анализа.
Для активного инцидента используйте сценарий 14, для общей модели системы — модель угроз.
Предварительные условия и область
Привяжите запрос к задаче AppSec, ревизии исходников, компоненту и language/domain-конфигурации. CPG должен соответствовать ревизии. Статический поиск не видит все маршруты, созданные runtime-конфигурацией, reflection, generated code, инфраструктурой или внешними шлюзами.
Не фиксируйте количество категорий или внутренние patterns в решении по безопасности: это детали реализации, зависящие от проекта и доменного плагина.
Запуск типизированного сценария AppSec
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Найди сетевые и аутентификационные точки входа в ограниченном API-компоненте.",
employee_id="codegraph_appsec",
scenario_id="scenario_16",
event_type="appsec_start",
context={
"project_key": "codegraph",
"namespace": "default",
"task_id": "<task-id>",
"source_refs": ["<revision-ref>", "<threat-model-ref>"],
"file_paths": ["<bounded-source-path>"],
},
)
result = invoke_role_bound_scenario_request(request)
Отдельной поддерживаемой публичной CLI-команды или REST-маршрута для точек входа нет. Не подменяйте сценарий низкоуровневым query endpoint.
Как читать результат
Проверьте retrieved_functions, cpg_results, evidence и метаданные категорий. Подтвердите значимых кандидатов в исходной ревизии, затем отдельно проследите данные и авторизацию.
Результат не доказывает возможность эксплуатации. Она проверяется отдельным security-анализом; указанная функция может быть недостижимой или защищённой, а пропущенная — создаваться динамически или отсутствовать в покрытии CPG.
От инвентаризации к свидетельству AppSec
Для каждой важной точки зафиксируйте границу доверия, тип входа, проверки аутентификации и авторизации, валидацию, downstream sinks, доступность в среде и владельца. При необходимости используйте целевой data-flow анализ и runtime-конфигурацию.
Вывод сценария не одобряет модель угроз, не принимает риск и не закрывает дорожку AppSec.
Ошибки и восстановление
- Инвентарь пуст: проверьте свежесть CPG, language/domain-конфигурацию, область и формулировку запроса.
- Слишком много общих кандидатов: укажите одну границу или категорию ввода и повторите анализ.
- Runtime-маршрут отсутствует: приложите deployment/router evidence и проверьте generated или dynamic registration.
- Получен fallback: пометьте его как предварительный и восстановите исходное свидетельство до решения.
Контракт с исходным кодом
Статья привязана к следующим источникам:
src/workflow/scenarios/security/entry_points.py— CPG-сбор, ранжирование, evidence и fallback;src/workflow/scenarios/security/handlers/core/entry_points.py— специализированный handler;src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py— типизированная маршрутизация;src/digital_employees/runtime/scenarios/employee_scenario_invocation.py— владелец AppSec и политика события.