Use context to navigate, not to pronounce a verdict
SocratiCode can help an authorised reviewer find an externally reachable operation, locate checks around it, and follow related symbols and files. That is useful navigation across a large source-available project.
It does not prove that a vulnerability exists. It also does not prove that one is absent. Search results, assistant summaries, and missing graph edges are all incomplete forms of evidence until the relevant source, configuration, tests, and runtime behaviour have been checked.
Scope comes first: review only source and systems you are authorised to assess, and follow the project’s established testing and disclosure process.
Confirm the data boundary before indexing
Check SocratiCode’s embedding and Qdrant configuration and the coding assistant’s data-handling settings. The default Ollama and Qdrant path is local for indexing, but an external embedding provider, remote Qdrant service, or the assistant itself can transmit source or tool results to another service.
Use source-code boundaries to map those paths before sensitive source is indexed.
Start from a reachable operation
Choose an operation within the authorised scope, such as an account export endpoint. Use codebase_search to locate:
- the route or handler;
- authentication and authorisation checks;
- downstream access to sensitive data;
- relevant configuration and feature flags;
- tests that encode the expected access policy.
Open every material result and confirm what the source actually does. A semantically similar result is a lead, not a finding.
Trace relationships in both directions
Use codebase_flow or codebase_symbol to inspect callers and callees. Use codebase_graph_query to inspect file dependencies. Look for alternative entry points that reach the same sensitive operation and paths that could bypass the expected guard.
external entry → handler → policy check → sensitive operation
└──────── alternative entry? ────────┘
The graph is a map of relationships SocratiCode could establish from indexed source. Dynamic dispatch, configuration, generated code, reflection, runtime policy, and dependencies outside the indexed project can change the real path.
Turn a lead into evidence
A suspected issue should be recorded only after checking the relevant source and its assumptions. Depending on the project, that normally includes:
- the exact entry point and required attacker capability;
- the guard that should enforce the policy;
- the path to the sensitive operation;
- configuration or deployment conditions needed for the path;
- existing tests and the reason they do or do not cover it;
- a safe, authorised validation through the project’s normal process.
Do not weaken tests, bypass controls, or treat a generated explanation as reproduction evidence.
Interpret negative results carefully
“No search result” can mean several different things: the query missed the relevant term, the index is stale, the file type was not indexed, the relationship is dynamic, or the code is outside the project. Check codebase_status, inspect coverage, try a precise identifier where available, and read the surrounding source before concluding that something is absent.
The same applies to a missing graph edge. Absence from a static graph is not proof that no runtime path exists.
Keep the review auditable
Record the project revision, index status, queries used, source locations opened, and the independent validation performed. This lets another authorised reviewer distinguish a search lead from a confirmed result.
If the suspected issue is in SocratiCode itself, use the repository’s private security reporting policy. For a system spread across several repositories, review the limits in cross-repository context before widening the search.