Safeguard
Security Guides•

First reply to a security report: a template for maintainers

What to say in the first message to someone who reported a vulnerability in your project: acknowledge, set expectations, ask for what you need.

Safeguard Security Team
3 min read

Reply within a day or two, thank the reporter, say you are looking into it, ask for anything missing, and state how you will keep them updated. You do not need to confirm the bug in the first message. You only need to show a real person has it and tell them what happens next.

Why speed matters more than substance

The OpenSSF maintainer guide for vulnerability reports advises acknowledging receipt quickly, within one to two days. A fast acknowledgment keeps a reporter from assuming the report went nowhere, which is the usual reason people go public early. It costs you five minutes.

The template

Adapt this to your own voice:

Hi NAME,

Thanks for reporting this, and for sending it privately.
I have received it and I am looking at it now.

To help me reproduce it, could you tell me:
- the version or commit you tested
- the steps or a proof of concept
- what you think an attacker gains

I will update you by DATE even if I have no answer yet.
Please keep the details private until we agree a date together.

Do you want credit in the advisory, and if so, under what name?

NAME

Keep it short. A long first reply reads like a form letter.

What each line is doing

  • Private by default. You ask for confidentiality without sounding legalistic.
  • A specific update date. This is the line that earns trust. Choose a date you can keep.
  • Questions that unblock you. The guide suggests asking for affected lines, the risk, and a proof of concept when a report is unclear.
  • Credit. The guide says credit is expected unless the reporter declines, so ask early instead of guessing.

What to leave out of the first reply

  • A verdict. You have not reproduced it yet.
  • A promised fix date. You do not know how hard the fix is.
  • Any argument about severity. Save that for after you understand the issue.
  • A request that the reporter sign an agreement. That tends to end the conversation.

Keep the thread alive

After the first reply, send a short note whenever something changes: reproduced, fix in progress, release date chosen. If you cannot reproduce the issue after repeated attempts, the guide suggests a polite closing note, not silence.

For the intake side, turn on private vulnerability reporting so reports land somewhere private and tracked. For what comes after the reply, see publishing a GitHub security advisory.

Quick check

How fast should I answer?

The OpenSSF guide says to acknowledge within one to two days. A short holding reply is better than a late full one.

Should I confirm the vulnerability in the first message?

No. Confirm receipt and next steps. Confirm the bug once you have reproduced it.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.