> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withgiga.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Findings & Evidence

> How findings are structured, scored, and verified

# Findings & Evidence

A **finding** is a confirmed vulnerability discovered during an audit. WithGiga's defining principle: GigaOps only emits findings on **confirmed compromise or exposure** — not theoretical issues, not "potential" weaknesses, not unverified scanner output.

## Finding structure

Every finding includes:

| Field            | Description                                                                                                                         |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `id`             | Unique identifier within the audit                                                                                                  |
| `title`          | Plain-English summary                                                                                                               |
| `description`    | Detailed explanation of what's wrong and why it matters                                                                             |
| `severity`       | Critical / High / Medium / Low / Informational                                                                                      |
| `class`          | `exploit` (confirmed RCE/auth bypass/etc.), `exposure` (sensitive data visible), `misconfiguration`, or `coverage` (documented gap) |
| `source`         | `agent` (found by GigaOps) or `baseline` (found by deterministic scanner before the agent ran)                                      |
| `category`       | Class of issue (e.g., `auth_bypass`, `sqli`, `exposed_credential`)                                                                  |
| `cwe`            | CWE identifier (e.g. `CWE-89`)                                                                                                      |
| `cve`            | CVE identifier if applicable, enriched with CVSS and CISA KEV status                                                                |
| `evidence`       | Structured evidence object — see below                                                                                              |
| `recommendation` | Specific remediation steps                                                                                                          |
| `discoveredAt`   | Timestamp                                                                                                                           |

## Severity levels

| Severity          | Score impact | Examples                                                                                              |
| ----------------- | ------------ | ----------------------------------------------------------------------------------------------------- |
| **Critical**      | −30 pts      | Confirmed RCE, authentication bypass, exposed admin panel without auth, leaked production credentials |
| **High**          | −15 pts      | SQLi with data extraction, stored XSS, privilege escalation, exposed sensitive PII                    |
| **Medium**        | −8 pts       | Reflected XSS, IDOR with limited impact, CSRF on state-changing endpoints, weak TLS                   |
| **Low**           | −3 pts       | Information disclosure, missing security headers, verbose errors, version disclosure                  |
| **Informational** | 0            | Observed configuration choices, hardening opportunities, no impact                                    |

See [Security Score](/audits/security-score) for how these compose into the letter grade.

## How findings are validated

WithGiga enforces a three-layer validation pipeline before any finding is accepted into an audit:

**Layer 1 — Submission gate (real-time)**
GigaOps submits findings through a `report_finding()` tool call, never by emitting text. At submission time, the orchestration layer validates:

* The cited command ID (`evidence.cmd_id`) must exist in the execution ledger for this engagement
* That command must have exited successfully and produced output — not just run
* Any stack-specific claim (e.g. "Jinja2 SSTI", "Firebase misconfiguration") requires that stack to have been fingerprinted from actual recon output earlier in the engagement

Findings that fail this check return `[finding_rejected]` to the agent and are silently dropped.

**Layer 2 — Deduplication**
Before entering the pending queue, each finding is checked against all existing findings by stable ID and by CWE × affected URL. This prevents the agent from re-reporting a vulnerability already caught by the baseline scanner, even if the title phrasing differs.

**Layer 3 — Post-hoc verification**
Before findings are written to the database, a verifier cross-checks each critical/high finding's claimed response against the actual stdout of the cited command. Read-only curl commands are replayed in the sandbox and the live response is compared to what the agent claimed.

A finding that fails any layer is dropped, not downgraded.

***

## Evidence

Evidence is what separates confirmed findings from scanner output. Every finding includes the raw artifact that proves the vulnerability exists.

### What evidence looks like

For an authentication bypass, evidence might be:

```
$ curl -i https://admin.acme.example.com/api/users \
    -H 'X-Forwarded-For: 127.0.0.1'

HTTP/2 200
content-type: application/json

[
  {"id": 1, "email": "ceo@acme.example.com", "role": "admin"},
  {"id": 2, "email": "cfo@acme.example.com", "role": "admin"},
  ...
]
```

For a SQL injection finding:

```
sqlmap -u 'https://acme.example.com/search?q=foo' --batch --dump

Database: app_production
Table: users
[247 entries]
+----+----------------------+-----------+
| id | email                | password  |
+----+----------------------+-----------+
| 1  | alice@acme.com       | $2b$10... |
...
```

This is what auditors, customers, and engineering leads will see in the PDF report. There's no ambiguity.

## Browsing findings

### From the dashboard

* **Per audit** — open an audit to see all its findings, filterable by severity
* **Across the workspace** — the **Findings** view aggregates every finding across all audits in the workspace
* **Across workspaces** — the global findings page (top-level **Findings**) aggregates everything

### From the API

```bash theme={null}
# All findings for an audit
curl https://api.withgiga.ai/api/workspaces/{workspaceId}/audits/{auditId} \
  -H "Authorization: Bearer $GIGA_API_KEY"

# Just the structured report
curl https://api.withgiga.ai/api/workspaces/{workspaceId}/audits/{auditId}/report \
  -H "Authorization: Bearer $GIGA_API_KEY"
```

## Verifying remediation

To verify a finding is remediated:

1. Apply the fix
2. Re-run an audit against the same target (typically [Shallow](/audits/shallow) is enough)
3. Confirm the finding is no longer present
4. Compare the asciinema recordings before/after for full transparency

## Next steps

<Columns cols={2}>
  <Card title="Reports & Recordings" icon="file-pdf" href="/audits/reports">
    PDF export and full session replay.
  </Card>

  <Card title="Security Score" icon="chart-line" href="/audits/security-score">
    How findings compose into a letter grade.
  </Card>
</Columns>