From Reconnaissance to Proof

Strix's value appears in the transition between “this code or request looks suspicious” and “this security consequence was actually demonstrated.” This chapter follows that transition as a lifecycle: source-aware triage selects a question, the sandbox supplies the right interface for exercising it, browser and proxy activity preserve observable behavior, and recovery logic keeps a failed turn from becoming an invisible gap. The goal is to understand what changes at each stage, what evidence persists, and when a candidate must remain unresolved rather than being promoted to a finding.

The previous boundary still governs the process. An agent does not get to test a source match simply because a scanner named it, and a captured request is not permission to replay it against an unrelated host. The lifecycle is useful precisely because each transition narrows the claim.

A static signal becomes a testable question

In a white-box run, Strix can begin with more than a public response. Its source-aware workflow maps a repository, identifies routes and sinks, and uses tools such as Semgrep, AST-structural search, secret detection, and filesystem or dependency checks to rank paths. The output is a set of hypotheses: a possible missing authorization check, a suspicious input flow, an unsafe dependency, or a configuration that deserves closer examination. The important transition is from pattern to question. Instead of “the scanner found a problem,” the specialist asks what input reaches which operation, under which identity, and with what consequence.

That change in wording has operational consequences. A pattern matcher sees a dangerous call; a security test needs an attacker-controlled source and a reachable sink. A dependency scanner can identify a version covered by an advisory; a meaningful prioritization still depends on whether the application imports the package, uses the affected symbol, or reaches it from an external entry point. Source-aware triage makes those questions easier to form and helps an agent choose where to spend runtime effort. It does not establish exploitability by itself.

The different static signals also carry different kinds of uncertainty. An AST match can show that a function is called in a particular structural pattern, while a secret detector can show that a credential-shaped value is present in a repository. A dependency check can establish that a pinned version falls within an advisory range, but it does not automatically show that the vulnerable API is imported or reachable. A route map can identify an entry point without showing which middleware, role check, or tenant filter runs before the sink. Treating these outputs as interchangeable would flatten useful distinctions. The specialist's task is to preserve the kind of question each signal supports and then choose a runtime test that can answer it.

That usually means tracing a candidate in two directions. Forward tracing asks what the suspicious operation does with its input: does it query a database, render a response, make a network request, or invoke a command? Backward tracing asks where the input comes from and which decisions intervene: a public request, an authenticated form, a queue message, a configuration value, or a trusted internal call. The two traces meet only when the source is attacker-controlled, the route is reachable under a realistic identity, and the missing or ineffective control occurs before the consequence. A static tool can suggest every part of this chain, but it rarely proves all of them in one result.

A useful example is a source match around an object lookup.