Handle vulnerabilities
Publish a vulnerability policy
Give researchers a safe reporting channel, scope, response expectations, and coordinated disclosure process.
Someone who finds a weakness should not have to guess how to reach you. Publish a clear security contact.
The failure mode is predictable. A researcher finds an authorization flaw and reports it in a public issue because the project has no security contact. The report exposes users before maintainers can investigate. The researcher did nothing malicious — you just gave them no better path.
On GitHub the convention is a SECURITY.md file in the repository root. Keep it short and concrete:
# Security Policy
## Supported versions
Only the latest 2.x release receives security fixes.
## Reporting a vulnerability
Report privately via GitHub's "Report a vulnerability" button,
or email [email protected]. Do not open a public issue.
We acknowledge reports within 3 business days and aim to
release fixes within 90 days, coordinating disclosure with you.
## Scope
Do not access other users' data, run denial-of-service tests,
or use social engineering. Good-faith research within these
boundaries will not result in legal action.Every element earns its place. Supported versions stop reports against code you will never patch. The private channel — enable GitHub’s private vulnerability reporting so the button exists — keeps details out of public view while you investigate. Response expectations tell the researcher when silence means “escalate” rather than “ignored”.
Tell reporters what helps you reproduce the issue: affected endpoint or function, a proof-of-concept request, the observed and expected behavior.
Safe harbor cuts both ways
A policy must also protect the project from destructive testing. Clear scope and safe-harbor language help good-faith research without granting permission to access other users’ data. State plainly what is out of bounds.
Then behave like the policy says. Acknowledge reports, protect reporter data, and coordinate fixes and disclosure. A policy you do not answer is worse than none: the researcher waits the promised three days, hears nothing, and publishes.
Draft SECURITY.md with supported versions, a monitored private contact, useful report details, response expectations, and testing boundaries. Send a harmless test report and save proof that the responsible person receives and acknowledges it. Then test the public issue path and confirm it directs reporters to the private channel without exposing report contents.
Lesson completed