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
SENDERapproved researcher
REPORTforwarded email
ATTACHMENTproof and logs
ZEROQUARRYBounded report intakeTurn an email into scoped, reviewable security workactive
TARGETproject resolved
VERDICTclaim validated
RESPONSEcoordinated reply
sender, project, target, and authorization boundaries are checked first
Capabilities
A report can be missed. Its context can disappear too.
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
A concrete path through the work.
ZeroQuarry automates investigation and coordination. Your team keeps control of authorization, risk ownership, and production changes.
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.
Operational result
What the team gets back.
Useful coverage should lead to faster decisions, cleaner remediation, and evidence that holds up when someone asks for it later.
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.
Details
Questions that come up in evaluation.
These are the product boundaries, controls, and operating details teams usually want to understand first.
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
Continue through the operating loop.
Start with one real security boundary.
Use the free trial on your own product, then decide whether the resulting security work is useful enough to keep.