Handle inbound security reports

Security reports arrive through researcher inboxes, support queues, customers, and bug-bounty programs. The operational risk is not only missing a real issue; it is losing context while someone manually translates an email into a test plan.

ZeroQuarry email triage turns a forwarded report into constrained assessment work inside the product project that owns the target.

When to use this workflow

Use it when:

• a central security or support inbox receives reports for multiple products
• trusted researchers or partners send technical reports by email
• the first task is to identify the affected repository or URL and reproduce the claim
• you need the original report context and the resulting scan to stay grouped with product history

Do not treat email triage as an open public submission endpoint. Processing is limited by sender allowlists, project routing, approved repositories, remote scan settings, and your account tier.

Design the intake boundary

Before provisioning an address, decide:

1. which ZeroQuarry project owns the reports
2. which exact sender addresses or domains are trusted
3. which GitHub repositories the triage model may select
4. whether the project may initiate remote URL scans

Repository and remote-scan constraints are important. They turn an untrusted email body into a request that can only operate inside a boundary you defined.

Set up the project inbox

1. Open the product project.
2. Use the project action to Provision incoming e-mail address.
3. Open Account > Integrations > E-mail Triage.
4. Add the exact sender addresses or domains that may be processed.
5. For the project, list allowed GitHub repository URLs one per line.
6. Enable remote URL scans only if reports for that project legitimately need live-target validation.
7. Forward trusted reports to the assigned proj-<id>@incoming.zeroquarry.com address.

For exact field behavior and safeguards, read Email triage.

Review the resulting work

For each forwarded report:

1. Confirm the report was matched to the intended project and target.
2. Read the generated scan notes; they are the bridge between the email and the assessment plan.
3. Validate findings against the reporter's claim and the product context.
4. Record the finding state and the reason for any dispute or accepted risk.
5. Route remediation through the appropriate engineering system.
6. If the report is external, create a controlled share or disclosure record only after validation.

Operate the inbox safely

• Keep allowlists narrow. Prefer exact addresses for individual researchers.
• Review allowed repositories when ownership changes or a project is archived.
• Leave remote scans off unless the project has a stable authorization model.
• Begin with exact senders and one repository while tuning the intake rules.
• Treat email text as untrusted input even from an allowlisted sender.
• Review unmatched or unresolved notifications instead of silently broadening the project boundary.

Measure the outcome

Useful measures are time to first technical assessment, percentage of reports that resolve to a known asset, time to a validated or disputed decision, and time from validation to remediation ownership. Email volume by itself is not a measure of security effectiveness.