01
Project routing
Give each product project its own incoming address so reports land with the correct asset history.
Inbound vulnerability reports
Turn a researcher email into bounded assessment work.
Project-specific inboxes, sender allowlists, approved repositories, remote-scan controls, and manual or automatic kickoff convert incoming reports into structured investigation without expanding scope silently.
Project-specific inboxesAllowed senders and targetsManual or automatic kickoff
incoming://report-triageprocessing
researcher@example.devto security@
Reproduced XSS in your contact form
stored payload executes on submit — PoC and request log attached
ZQC-412
claimstored XSS · contact form
targetapp/contact · mapped to main
evidencePoC attached · 2 requests
acknowledgedtriagedfix routed
sender, project, target, and authorization boundaries are checked first
Capabilities
Where an inbound report goes
A report often arrives in one system, becomes a ticket in another, and turns into ad hoc testing somewhere else. ZeroQuarry keeps the original claim and the resulting assessment inside the owning product history.
02
Sender allowlists
Process exact researchers, partner addresses, or trusted domains instead of creating an open public trigger.
03
Repository boundaries
List the GitHub repositories the triage model may select for each project.
04
Remote-scan control
Keep live-target testing disabled unless that project has an explicit and stable authorization boundary.
05
Review before kickoff
Start with automatic dispatch off so operators can inspect proposed target, scan type, and notes.
06
Connected remediation
Validate resulting findings, record the decision, route ownership, and create a controlled share or disclosure when appropriate.
How it runs
Receive, resolve, assess, respond
What happens between a researcher's email and a defensible answer.
Receive
Forward the report to the assigned project inbox from an allowed sender.
Resolve
The triage model identifies target, scan type, and useful notes inside the configured boundary.
Assess
An operator approves the work or the project starts it automatically after the rules are trusted.
Respond
Validate findings, route remediation, and track the external communication when needed.
Outcomes
Faster triage, without losing the thread
One connected record, from the original claim to the assessment it triggered.
Faster time to technical assessment
Reduce the manual translation between an external claim and a scoped reproduction plan.
Safer automation boundary
Constrain what an untrusted email can cause the platform to investigate.
One connected record
Keep intake, findings, decisions, remediation, and disclosure with the product that owns the risk.
Evaluation FAQ
Questions about inbound report intake
Who can email in, what the automation may do, and how to tune the noise.
Can anyone email the inbox?
Only messages routed to an active project address and matching an exact sender or allowed domain are processed.
Can the email tell ZeroQuarry to scan another repository?
The model can only resolve repositories listed for that project. Reports that cannot map safely are surfaced for review instead of expanding the boundary.
How should we tune report intake?
Begin with exact sender addresses and one approved repository. Matching reports start after those checks, so keep the boundary narrow and expand it only after target matching behaves as expected.
Related workflows
Coordinated disclosure
Route the next report through it
Forward the next inbound claim and compare the answer with your current process.