Agentic SAST Without Guesswork: File-Level Evidence, Validation, and Trace

Static application security testing (SAST) is often sold as a list of rules. Agent-assisted source analysis adds a reasoning step: connect a potentially attacker-controlled input to a sensitive operation, then explain why the path is reachable and what control is missing. That reasoning is useful only when it stays anchored to the repository and can be checked by another engineer.

An agent’s confidence is not evidence. A reviewable source finding should identify the exact repository revision, file, line range, relevant code, source of the input, sensitive sink, assumptions about reachability, and the validation result. If any link in that chain is missing, the result is a lead to investigate—not a confirmed vulnerability.

Pin the code before analysis

Record the repository and commit that were authorized for review. A moving branch makes later reproduction ambiguous: the code may change after the scan, and line references can point to different logic. A pinned clone gives reviewers a stable basis for checking each claim.

For sensitive repositories, use a narrowly scoped credential or a credential-free repository URL when the project is public. Restrict access to the cloned source and avoid including secrets, generated artifacts, dependencies, or unrelated documentation in finding exports. The source material itself can contain credentials and customer data.

Follow a source-to-sink path

A strong SAST explanation traces how data enters and where it is used. For a web request, a source might be a route parameter, header, JSON field, upload, or GraphQL variable. A sensitive sink might be a SQL query, shell command, filesystem path, template renderer, outbound HTTP request, or authorization decision.

The analyst then checks the transformations between those points: parsing, validation, encoding, canonicalization, permission checks, and library behavior. A string appearing near exec does not prove command injection if it is a fixed constant. A value reaching a database call does not prove SQL injection if it remains parameterized. Conversely, sanitization in one branch may not protect a second path.

Require exact, checkable evidence

Each candidate should cite an existing file and line, include only the small snippet needed to orient the reviewer, and explain the data flow in plain language. Reviewers should be able to open the pinned revision and independently find both the source and sink. A generated summary without code references cannot support a remediation decision.

Validation should try to disprove the candidate: Is the route reachable? Is the data attacker-controlled? Does a guard run on every path? Is the sink actually dangerous in this framework? Does a test, type constraint, or upstream policy change the exploitability? Record counter-evidence and uncertainty instead of smoothing them away.

Understand what repository analysis cannot prove

SAST can inspect code paths; it cannot by itself prove that a deployed endpoint is reachable from the Internet, that production secrets are exposed, or that an authorization bug produces a particular customer impact. Those claims need runtime, deployment, identity, or business context. Use DAST or an authorized manual assessment to validate behavior in a running environment when that is within scope.

Likewise, an agent that reads code should not be granted unnecessary ability to execute it or contact the network. A constrained workflow can pin the clone and allow list, search, and read operations while preventing shell execution, package installation, network access, or source modification. These restrictions reduce exposure and make the analysis process easier to audit.

A practical source finding format

• Revision: repository and commit identifier.
• Location: file and exact line range.
• Source: the attacker-controlled value and its entry point.
• Path: transformations, guards, and the route to the sink.
• Impact condition: the role, deployment state, or configuration needed.
• Validation: what was checked and what remains uncertain.
• Fix and retest: the control to add and the evidence that will prove it works.

Eresus Guard documents an agentic SAST workflow in which research workers inspect a pinned clone, candidates cite a file, line, and snippet, and surviving results pass validation and trace before storage. Review the SAST language matrix for its supported source families and the Guard Workbench for the surrounding assessment flow.