Skip to main content

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

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:
FieldDescription
idUnique identifier within the audit
titlePlain-English summary
descriptionDetailed explanation of what’s wrong and why it matters
severityCritical / High / Medium / Low / Informational
classexploit (confirmed RCE/auth bypass/etc.), exposure (sensitive data visible), misconfiguration, or coverage (documented gap)
sourceagent (found by GigaOps) or baseline (found by deterministic scanner before the agent ran)
categoryClass of issue (e.g., auth_bypass, sqli, exposed_credential)
cweCWE identifier (e.g. CWE-89)
cveCVE identifier if applicable, enriched with CVSS and CISA KEV status
evidenceStructured evidence object — see below
recommendationSpecific remediation steps
discoveredAtTimestamp

​
Severity levels

SeverityScore impactExamples
Critical−30 ptsConfirmed RCE, authentication bypass, exposed admin panel without auth, leaked production credentials
High−15 ptsSQLi with data extraction, stored XSS, privilege escalation, exposed sensitive PII
Medium−8 ptsReflected XSS, IDOR with limited impact, CSRF on state-changing endpoints, weak TLS
Low−3 ptsInformation disclosure, missing security headers, verbose errors, version disclosure
Informational0Observed configuration choices, hardening opportunities, no impact
See 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": "[email protected]", "role": "admin"},
  {"id": 2, "email": "[email protected]", "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  | [email protected]       | $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

# 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 is enough)
  3. Confirm the finding is no longer present
  4. Compare the asciinema recordings before/after for full transparency

​
Next steps

Reports & Recordings

PDF export and full session replay.

Security Score

How findings compose into a letter grade.