Triage an inbound report in five moves: acknowledge it by name, read it for impact, try to reproduce it, give it a rough severity, and route it to an owner with a date. You are not fixing anything on day one. You are deciding what this is and who holds it.
Why the first day matters
A researcher who hears nothing assumes the report was ignored. OWASP's disclosure guidance describes the ideal exchange as an acknowledgment, a timeline for triage, a request for clarification if needed, and then confirmation with a fix timeline. The first message sets the tone for every message after it.
CISA's directive for federal agencies, BOD 20-01, is written for agencies rather than vendors, but its target timelines are a useful reference point. It suggests acknowledging the reporter within 3 business days, finishing the initial assessment within 7 days and resolving within 90 days. Those are recommendations, not mandates. A vendor with a small team can aim for faster acknowledgment because it costs almost nothing.
The five steps
| Step | What you do | Output |
|---|---|---|
| 1. Acknowledge | Reply from a named person, not an auto-reply | A message saying you received it and when they will hear next |
| 2. Read | Identify the affected product, version and claimed impact | One sentence summary |
| 3. Reproduce | Follow the researcher's steps in a test environment | Confirmed, not confirmed, or need more detail |
| 4. Rate | Assign a rough severity and note what you assumed | A label such as low, moderate, high, or incident |
| 5. Route | Open a tracked case with an owner and a next date | A ticket and a promised update |
Step by step notes
Acknowledge. Keep it short. Say you received the report, who is looking at it, and when you will write again. CISA's guidance on the .gov security mailbox notes the value of a reply from a named human, not an auto-reply and not signed "the team".
Read. Check three things: which product and version, what the attacker gains, and whether a production system is involved right now. If the report suggests someone already accessed data, stop the routine and treat it as an incident under your own response plan.
Reproduce. Use a test environment, not production. If the steps are unclear, ask a specific question instead of a general one. Our post on reproducing a report safely goes deeper.
Rate. BOD 20-01 describes one simple approach: rank the effect on confidentiality, integrity and availability as low, moderate or high, with extra labels for not applicable and incident. It calls these scores subjective and meant only to set priority quickly. You can refine the score later.
Route. Open a case, give it one owner and put the next update date in the ticket. A report that lives only in a shared inbox will be forgotten.
What to avoid on day one
- Do not argue about severity in the first reply.
- Do not promise a fix date you cannot keep.
- Do not forward the raw report to a large group. Share it with the people who need it.
- Do not ask for payment terms unless you run a bounty.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the finding list and watch how a case gets an owner and a priority. The same habit applies to a researcher report once it is a ticket.
If the report points at a dependency you ship, Safeguard's reachability analysis can show whether your code actually calls the vulnerable function, which helps with step 4. You can also run a free scan.
Quick check
Do I have to fix the bug within 24 hours?
No. The 24 hours is for acknowledging, understanding and routing the report. Fix timelines depend on severity and complexity, and you should tell the researcher what to expect.
What if I cannot reproduce it?
Say so politely, list what you tried, and ask for the missing detail such as version, configuration or request samples. Do not close the report until you have asked.
Sources
- OWASP Vulnerability Disclosure Cheat Sheet
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
Last reviewed: 19 October 2026.
