Skip to content
Severity Labs

Services

What triage actually looks like.

We're the layer between your hunters and your engineers. Everything below is what we do, what we don't, and what you can add when you need it.

Workflow

From inbound to closeout, here's the end-to-end.

  1. 01

    Inbound

    Reports route to a Severity Labs address or a forwarder from your existing security@ inbox. We acknowledge within SLA, log every submission, and assign a tracking ID before anyone on your side sees it.

  2. 02

    Triage

    We deduplicate against history, confirm scope, and either reject with a clear reason or move forward with reproduction. Hunters get a real reply, not a templated brush-off.

  3. 03

    Validation

    We reproduce end-to-end, capture screenshots and request/response evidence, and write up impact based on what's actually exploitable. If we can't reproduce, we say so before escalating.

  4. 04

    Scoring

    CVSS 3.1 vector and base score, with a written justification. We also annotate business-context severity, because a 9.8 in a sandbox isn't the same as a 6.5 on a payment endpoint.

  5. 05

    Handoff

    A dev-ready issue lands in your tracker: title, asset, repro, impact, suggested fix direction, severity, and a link to evidence. Engineers can pick it up cold.

  6. 06

    Closeout

    We coordinate the retest with the hunter once the fix is deployed, confirm the fix holds, and close the report with a written disposition. Bounty payment recommendations included if you run a paid program.

Included

What's in every engagement.

  • Acknowledgement and SLA tracking
  • Deduplication against historical reports
  • Scope and policy enforcement
  • End-to-end reproduction with evidence
  • CVSS 3.1 scoring and justification
  • Business-context severity annotation
  • Dev-ready report writing
  • Tracker integration (Jira, Linear, GitHub, etc.)
  • Hunter communication in your program's voice
  • Retest verification once fix ships
  • Weekly or monthly summary reporting

Not included

What we don't do.

Clear lines make the work better. If you need any of these, we'll point you at people who do them well.

  • Penetration testing

    We don't run scoped engagements or red team your apps. We triage what hunters bring you.

  • Shipping the fix

    We hand engineers a clear report and a suggested direction. Code changes stay with your team.

  • Source code review

    We work from black-box repro unless you grant access. We don't audit codebases as a service.

  • Public PR or breach response

    We're not your incident response or comms team. If a report indicates active exploitation, we escalate fast and stay in our lane.

What we triage

The bug classes we see, week in and week out.

Every report gets the same workflow regardless of class. The list below is here so you can see what we've reproduced often enough to triage on autopilot — not a scope limit.

Web application

  • Stored, reflected, and DOM-based XSS
  • SQL injection (in-band, blind, time-based)
  • Server-side request forgery (SSRF) and metadata pivots
  • Insecure direct object reference (IDOR) and BOLA
  • Cross-site request forgery (CSRF) where it actually has impact
  • Open redirect (with realistic exploitation chains)
  • Server-side template injection (SSTI)
  • XML external entity (XXE) and XML injection
  • Prototype pollution and gadget chains

Authentication and authorization

  • Account takeover via password reset, OAuth, or session fixation
  • JWT misconfiguration, alg=none, key confusion
  • MFA bypasses and recovery-flow weaknesses
  • Privilege escalation between roles, tenants, or scopes
  • Race conditions in auth-adjacent flows

API and infrastructure

  • Broken object-property authorization in REST and GraphQL
  • Mass assignment and excessive-data-exposure findings
  • Rate-limit bypasses with downstream impact
  • Misconfigured CORS, cookies, or CSP
  • Cloud metadata exposure, leaked credentials, public buckets
  • Subdomain takeover (CNAME, NS, S3, Heroku, Azure)

Out of (typical) scope

  • Self-XSS without exploitation path
  • Missing security headers without demonstrated impact
  • Public information disclosure that isn't sensitive
  • Brute-force / rate-limiting reports without account impact
  • Best-practice scans (`securityheaders.com`, SSL Labs) submitted as findings

Add-ons

Optional work, when the program needs more.

Program design

Scope, policy, reward structure, and disclosure timeline — written so hunters understand what's in bounds before they start.

Hunter relations

Direct, ongoing relationships with researchers who consistently bring quality. Invite-only or private-program management included.

Retest verification

Independent confirmation that a deployed fix actually closes the issue, with the original hunter looped in when appropriate.

Quarterly reviews

Submission trends, hunter quality, asset hotspots, SLA performance. Delivered as a written brief and a 60-minute walkthrough.

Get started

Stop letting reports pile up.

Hunters lose interest. Engineers lose mornings. The next report is already in the inbox.

Book an intro call →