Send security reports to a small group, not one inbox owned by one person. Use an intake address that forwards to two or three trusted maintainers, keep a separate channel for coordinating fixes, and test it yearly. A report that lands in a dead mailbox is the most avoidable way to lose a reporter's trust.
The problem with one person
If you are the only recipient and you are on holiday, ill, or burnt out, reports wait. Reporters who hear nothing tend to go public. A single point of failure also means one compromised mailbox exposes every report. Spread both risks.
What the OpenSSF guide suggests
The OpenSSF maintainer guide recommends a small vulnerability management team of trusted people, noting that larger projects may use three to seven members. It also says to keep the team's coordination alias separate from the intake alias, and it names a pattern to avoid: do not make the coordination alias the same as the public security address. It also says email is an acceptable intake channel, even if you use an issue tracker, and suggests hop-to-hop encryption such as MTA-STS or STARTTLS.
A practical setup for a small project
- Intake. A public address such as security at your project's domain, or GitHub private vulnerability reporting, or both. See enabling private reporting.
- Team. Two or three people who can see reports. For a one-maintainer project, one trusted peer is a large improvement.
- Coordination. A private chat room or list for the team only, separate from intake, so a spammer or reporter cannot see the team's discussion.
- Backup. A named person who covers when the primary is away.
Rules for the team
- Everyone uses two-factor authentication on the accounts tied to the alias.
- Everyone agrees to confidentiality until the release date.
- Reports are acknowledged within one to two days by whoever sees them first. See the reply template.
- A shared note records who owns each report.
Publish it
State the contact and the process in SECURITY.md, and link it from the README. The guide also recommends a regular status update so reporters can tell whether the team is active. A line like "last reviewed" on the policy page goes a long way. For the file itself, see writing a SECURITY.md.
Test it
Once a year, or after any change of team, send a harmless test message to the intake address from outside your organisation and confirm each member receives it. Check spam folders too. Also check that the contact in SECURITY.md and any security.txt file still points at a live person.
When people leave
When a team member goes, remove them from aliases, chat and calendars the same day. The offboarding checklist lists the places.
Quick check
Can the alias be my personal email?
You can start there, but it leaves you as a single point of failure. Add a project address that forwards to more than one person.
Should reporters see who is on the team?
Not necessarily. Publish the process and the contact, not the member list.
Sources
Last reviewed: 19 October 2026.
