Evidence & Context

Secbez doesn't just flag code — it explains why the code is flagged and shows the evidence behind the verdict. This section describes the kinds of evidence a finding can carry.

Code-level evidence

Snippet

The exact vulnerable code with surrounding context. The triggering lines are highlighted, and the snippet is wide enough to show the relevant construct (e.g., the entire query builder chain for a SQLi finding, the full route handler for an authz finding).

Detector trace

The deterministic detector that produced the finding, the rule ID, and the structured pattern that matched (e.g., "Prisma $queryRaw called with a template literal containing a non-literal expression at offset 12").

Graph evidence

The code graph attaches cross-file evidence to every finding:

• Callers — functions from other files that reach the vulnerable function. Each caller is shown with its file and line so you can trace the path.
• Route reachability — whether an attacker can reach the function from the network. The dashboard shows the entry route (e.g., POST /api/users/:id/role), the framework, and the path through the graph.
• Auth chain — whether an authentication or authorization barrier dominates every path from an entry point to the sink. The barrier is shown with the file/line of the actual enforcement, not just the helper name.
• Tenant scoping — whether the operation is bound to a server-derived tenant or owner identity. Field-name evidence alone (a teamId column) is not treated as proof.
• Taint flow — the propagation chain from attacker-controlled source through any transformations to the sink. Cross-function propagation is only treated as strong evidence when arguments, parameters, returns, or fields are tracked.

The graph is sophisticated enough to distinguish "this code is structurally near a sink" from "this code actually flows into a sink under reachable conditions" — only the latter counts as exploit-path evidence.

Reasoning trace

When AI reasoning was applied to a candidate, the trace is part of the evidence:

• Reasoning category — auth/privilege, tenant scoping, dataflow, business invariants, or workflow integrity.
• Verdict — vulnerable, inconclusive, or safe.
• Cited evidence — the snippet ranges and graph context the reasoning referenced.
• Missing conditions — when the verdict is inconclusive, the specific evidence that could not be confirmed.

A vulnerable verdict requires concrete evidence for every required condition for that vulnerability class. Missing evidence becomes inconclusive, never vulnerable.

Validation history

Findings persist their validation history across scan runs. You can see:

• When a finding first appeared.
• Each scan run that re-confirmed it.
• The PR or commit that fixed it (if applicable).

How context affects severity

Cross-file context flows into both severity and confidence:

• Reachability from an unauthenticated entry point lifts severity.
• A verified authentication or tenant barrier in the dominating path downgrades or suppresses the finding.
• A confirmed taint path through multiple files raises confidence.
• A purely structural pattern with no callers in the graph is downgraded to needs-review.

When evidence is missing

If a required piece of evidence is missing — for example, the candidate's caller chain wasn't reachable in the active graph snapshot — Secbez does not silently assume the worst (or the best). The finding is preserved, the missing condition is recorded, and the finding is routed to needs-review.