Scenario 16 searches the project CPG for external, network, query, authentication, file, process, and related entry-point candidates. The output is an attack-surface hypothesis for AppSec review; the security verdict comes from the accountable AppSec review.
When to use it
Use the scenario to answer a bounded question:
- which functions accept network or client input;
- where authentication or privilege boundaries enter the code;
- which file, process, or extension interfaces expand the attack surface;
- which candidates need data-flow or incident analysis next.
Use Scenario 14 for an active incident and Threat model for the broader system model.
Prerequisites and scope
Bind the request to an AppSec task, source revision, component, and language/domain configuration. The CPG must represent the reviewed revision. Static entry-point discovery cannot see every route created by runtime configuration, reflection, generated code, infrastructure, or external gateways.
Do not freeze category counts or internal matching patterns in a security decision. They are implementation details and vary by project and domain plugin.
Run the typed AppSec scenario
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Map network and authentication entry points in the bounded API component.",
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)
Entry-point analysis uses the documented role-bound scenario route. The low-level query endpoint remains an internal diagnostic surface.
Read the result
Review retrieved_functions, cpg_results, evidence, and the category metadata. Confirm each decision-relevant candidate in the source revision, then trace data and authorization separately.
The result is not proof of exploitability. It lists candidate entry points; confirm reachability, protection, dynamic creation, and CPG coverage during AppSec analysis.
From inventory to AppSec evidence
For each relevant entry point, record trust boundary, input type, authentication and authorization checks, validation, downstream sinks, environment exposure, and owner. Use focused data-flow analysis and runtime configuration evidence where necessary.
The threat model owner approves the threat model, accepts the risk, and closes the AppSec lane using the scenario output and supporting evidence.
Failure and recovery
- Empty inventory: verify CPG freshness, language/domain configuration, component scope, and query wording.
- Too many generic candidates: name one boundary or input category and rerun.
- Runtime route missing from results: add deployment/router evidence and inspect generated or dynamic registration.
- Fallback output: label it preliminary and restore source-bound evidence before a security decision.
Source contract
This guide is bound to:
src/workflow/scenarios/security/entry_points.py— CPG collection, ranking, evidence, and fallback;src/workflow/scenarios/security/handlers/core/entry_points.py— specialized handler;src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py— typed routing;src/digital_employees/runtime/scenarios/employee_scenario_invocation.py— AppSec ownership and event policy.