A TigerStrike finding is more than a “scanner says line 84 is bad” — see the fields below.

​
Anatomy

FieldExample
SeverityCRITICAL / HIGH / MEDIUM / LOW / INFO
StatusNEW (default) / MUTED / RESOLVED / ACCEPTED
Title”Stored XSS via display-name field”
Categoryxss-stored, idor, ssrf-internal, privilege-escalation, …
Resourcehttps://staging.example.com/profile
Reproducible payloadThe exact request body the agent sent
Exploit narrativeNumbered steps the agent took to confirm exploitation
EvidenceScreenshots, response bodies, exfiltrated data (PII redacted)
CWE / OWASPCWE-79, OWASP A03:2021
Framework tagsPCI:6.5.7, SOC2:CC7.1, CIS-K8s:5.2.5
RemediationConcrete code/config fix; links to canonical references

​
Reproducible payloads

Every confirmed exploit comes with the exact request that triggered it: 
POST /api/profile HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json

{
  "display_name": "<script>alert(document.cookie)</script>"
}
Plus the response that demonstrated success: 
HTTP/1.1 200 OK
Content-Type: application/json

{"id":12345,"display_name":"<script>alert(document.cookie)</script>"}
You can replay the request from the finding’s Reproduce tab — the dashboard shows the curl command + the agent’s interpretation: 
curl -X POST https://staging.example.com/api/profile \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." \
  -H "Content-Type: application/json" \
  -d '{"display_name":"<script>alert(document.cookie)</script>"}'

​
Exploit narrative

The agent records what it tried before it confirmed: 
1. Logged in as [email protected].
2. Retrieved profile: GET /api/profile → display_name="Test User".
3. Tested input reflection — sent display_name="<TIGER>" → reflected in response.
4. Tested XSS — sent display_name="<script>alert(1)</script>" → script element rendered in
   GET /profile (HTML view), confirming stored XSS.
5. Verified persistence — logged out, re-logged in, payload still rendered.
Useful for:
  • Triage — does the finding match what your team would have caught?
  • Re-test — can you reproduce after the fix lands?
  • Incident response — if the bug ever shipped, the narrative is your audit trail.

​
Evidence

Per finding:
  • Screenshots — at the moment of confirmed exploit (e.g. the alert box rendering).
  • Response bodies — relevant excerpts; full bodies retained until retention sweep.
  • Network traces — captured during exploitation; available for download as HAR.
  • Exfiltrated data — when an agent successfully retrieves data it shouldn’t, the data is recorded with PII auto-redacted (emails partially masked, SSNs replaced, etc.).
Evidence retention follows your org’s data-retention setting (default 90 days). After that, only the metadata persists.

​
Severity

Set by a combination of CVSS v3.1 + practical exploitability as judged by the agent:
SeverityThreshold
CRITICALCVSS ≥ 9.0 OR confirmed RCE / data-exfil at scale
HIGHCVSS 7.0 – 8.9 OR confirmed privilege escalation / IDOR
MEDIUMCVSS 4.0 – 6.9 OR likely-exploitable but agent couldn’t confirm fully
LOWCVSS < 4.0 — defense-in-depth concerns, info-disclosure of low-value data
INFOBest-practice deviation, no direct exploit demonstrated
The agent’s “practical exploitability” judgment shows up in the finding as a confidence rating (high, medium, speculative) — speculative findings are usually INFO-tier and worth treating as leads rather than confirmed bugs.

​
Statuses

StatusWhen to use
NEWDefault; needs triage
MUTEDFalse positive — keep on record but don’t show in inboxes / gate calculations. Requires a justification.
ACCEPTEDTrue positive that you’ve decided not to fix (compensating controls, business reason). Has an expiry — re-reviewed annually.
RESOLVEDFixed; ships into TigerGate’s “verify fix” check on the next scan
The next time the same scan config runs, TigerStrike picks up where it left off:
  • A RESOLVED finding gets re-tested. If still exploitable, it’s reopened to NEW with a “regression” tag.
  • A MUTED finding stays muted unless the underlying signature changes meaningfully.
  • An ACCEPTED finding stays accepted until the expiry date.

​
Filtering / inbox

The findings inbox at Pentest → Findings supports:
  • Severity pills + Status pills (multi-select).
  • Target filter (drop a target name; matches name + tags).
  • Category filter (xss, idor, etc.).
  • Search across title + URL + payload.
  • Group by — flat / target / severity / category.
Save common filters as views — useful for “all open release-blocker-tagged findings” or “everything in env:prod from this quarter”.

​
Exporting findings

CSV / JSON / SARIF / PDF — all from the dashboard at Pentest → Findings → Export. Pick a format from the dropdown, the filter chips above the findings list scope the export, and the file downloads in the browser. Exports are UI-only; there is no curl / API endpoint. SARIF uploads natively into GitHub’s Security tab if you want pentest findings alongside SAST results. For scheduled or recurring exports, use the Reports tab — every export here is also available there with email / Slack / webhook delivery.