Scenario 16 searches the project CPG for external, network, query, authentication, file, process, and related entry-point candidates. The output gives the security engineer a list of functions for reviewing input validation, access checks, and downstream operations.
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
Prepare the Python environment and configuration using the CLI guide and programmatic guide. Confirm the required graph services are reachable and configure the LLM for workflow paths that use it. Save the example as a Python file in the CodeGraph repository root and run it from that directory in the prepared environment. Replace the project, namespace, task, evidence references and source paths with the accepted AppSec scope.
Bind the request to an AppSec task, source revision, component, and language/domain configuration. The CPG must represent the reviewed revision. Supplement discovered functions with routes from runtime configuration, dynamic registration, generated code, and external gateways.
The domain plugin supplies categories, name patterns, and specific functions for discovery. Choose categories that match the interfaces in your project.
Run the typed AppSec scenario
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Map network 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)
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"])
After the run, save the answer with the project revision. Use the discovered functions as a checklist for reviewing routes, input validation, and access checks.
How the scenario collects categories
The general path selects one question type from keywords. It searches that category first, then adds general categories from the active plugin. When the number of discovered names is below the configured threshold, it runs additional searches using plugin patterns. It ranks the results by relevance to the query.
Ask about network and authentication entry points in separate calls. The Python example selects network discovery. For the second call, use “Map authentication entry points in the bounded API component.” and save its result separately. Compare the input handlers with the functions that verify user identity.
On the general path, cpg_results contains name and category pairs, while metadata.entry_points groups discovered names by category. retrieved_functions holds the ranked list within the configured limit. The metadata.total_entry_points field reports the length of that list. Use the names in metadata.entry_points to inspect an individual category.
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.
For a relevant function, follow the path from external input to the operation, confirm route reachability, and inspect access checks. This turns the candidate list into an attack-surface review plan.
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.
Compare the scenario results with the source code and runtime configuration. Use that evidence to update the threat model and record a decision for each material risk.
Failure and recovery
With an empty context, the call fails with
role_bound_scenario_contract_missing:project_key,namespace,task_id.
Set project_key, namespace, and task_id to the project and task used for
the analysis, then repeat the call.
- 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: identify the data used by the scenario and supplement it with source files and graph evidence before making a decision.