Understanding Findings
How to read a Secbez finding — code, evidence chain, graph context, severity, confidence, agent verdicts, and remediation.
A finding is Secbez's output for a single, deduplicated, deterministically-anchored vulnerability. It is the unit you triage, suppress, fix, or accept.
Finding details
Every finding contains the following fields. Most of them are visible in the dashboard finding pane and are also available through the API.
Code anchor
The exact file, line range, and code snippet where the vulnerability was detected. Surrounding context (typically ±5–10 lines) is included so reviewers can see the construct in situ.
Rule and category
The stable rule ID (e.g., SEC.SQLI.RAW_QUERY_TEMPLATE_LITERAL) and category (e.g., SQL injection, IDOR/BOLA, broken access control). Rule IDs are public identifiers — baseline matching, suppression rules, and analytics all key off them.
Evidence chain
A structured explanation of why this code was flagged:
- What was found — the specific deterministic pattern or condition (e.g., a template literal in a Prisma
$queryRawcall). - Why it matters — the security impact if exploited.
- How it could be exploited — a concrete attack scenario grounded in the evidence.
Graph context
When a code graph is available, findings are enriched with cross-file evidence:
- Callers — the call chain into the vulnerable function, ranked by edge strength.
- Route reachability — whether the function is reachable from an HTTP/GraphQL/queue/scheduled entry point, and which one.
- Auth / tenant chain — whether an authentication or tenant-scoping middleware dominates the entry path, with the verifying file:line.
- Taint flow — when the detector emits source-to-sink evidence, the propagation chain is attached.
This context is the difference between "raw query found" and "raw query reachable from an unauthenticated POST handler with no tenant predicate."
Reasoning trace
When AI reasoning was applied to the finding, the trace is attached:
- The category of reasoning (auth/privilege, tenant scoping, dataflow, business invariants, workflow integrity).
- The verdict (
vulnerable,inconclusive,safe). - The reasons, citing the evidence used to reach the verdict.
This makes verdicts auditable — every confirmation is backed by named evidence, not opaque AI judgment.
Severity and confidence
Two independent ratings — see Severity & Confidence for the full scoring model.
Remediation
A grounded explanation of the fix and, when one can be produced safely, a verifier-checked patch. The textual agent_prompt is always emitted — you can hand it directly to a coding agent.
Finding status
| Status | Meaning |
|---|---|
| Open | Active finding requiring attention. |
| Suppressed | Manually silenced (false positive, accepted risk, or won't-fix). |
| Fixed | The vulnerable code was changed in a subsequent scan and the finding no longer reproduces. |
Needs-review findings
Some findings are flagged needs review because the deterministic evidence was incomplete and the invariant agent reached an inconclusive verdict. These findings are preserved rather than dropped — the philosophy is that missing evidence is not proof of safety.
A reviewer with codebase context should evaluate them. The dashboard surfaces the exact missing condition the agent could not verify (e.g., "tenant predicate not found in path", "sanitizer presence not verified").
Baseline vs. new
Each scan compares findings against the repository baseline:
- New — introduced since the baseline. These flow through policy and can gate a PR Check Run.
- Baseline — already present in the repository before the change. These are tracked but don't gate.
This keeps review focused on net new risk.