Triage Inbound Vulnerability Reports
Turn an external report into a private, reproducible case with scope, impact, owner, and a clear next response.
An external report may be incomplete, correct, or based on a different product version. Treat it as a claim to investigate, not as proof of a defect or as spam. A security.txt contact gives reporters a route to reach you, while an internal triage process must decide what the report means. Do not run tests against customer systems to fill a gap in the report.
Intake record
| Field | First-pass question |
|---|---|
| Scope | Is the product or asset ours? |
| Version | Which release and configuration are affected? |
| Reproduction | Can an authorized test environment show it? |
| Impact | What access or data could change? |
| Evidence | What can be stored without excess personal data? |
| Contact | When will the reporter hear back? |
Acknowledge receipt through the reporter's chosen contact route. Move attachments to controlled storage and avoid forwarding secrets or personal data in email threads. Check the asset and version before assigning severity. If the report names a vulnerability class, use a relevant verification standard such as OWASP ASVS to frame the expected control, but validate the actual behavior in the product.
Make a triage decision
Reproduce the issue in a test environment that you own or are authorized to use. Record the exact steps, expected result, actual result, affected role, and logs with sensitive values removed. If reproduction fails, ask a focused question and keep the case open until the evidence is sufficient. Distinguish a duplicate from a false positive; a duplicate may still add useful impact evidence.
Focused reply and decision record
For an incomplete fictional report, reply: "Thank you. We have your report. Which product version and account role produced the stated result? Please do not send credentials or customer records. We will update you after we review the supplied evidence." Record receipt time, asset and version claim, safe evidence reference, owner, next update date, and status unconfirmed. If the report duplicates an open case, link it and keep any new impact evidence; do not call it false merely because the issue is known. Test only an owned or separately authorized environment before changing status to confirmed.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.