Open the repository's Settings, go to Advanced Security under Security and quality, and click Enable next to Private vulnerability reporting. Researchers then see a Report a vulnerability button on the Advisories page. Check that the right people get notified, or reports will sit unseen.
Steps
- Open the repository's main page, then Settings. If you cannot see it, use the More dropdown.
- In the sidebar under Security and quality, click Advanced Security.
- Next to Private vulnerability reporting, click Enable.
GitHub's documentation describes these steps, and menu labels can change, so check the current page if yours looks different.
Who gets notified
Per the GitHub documentation, repository administrators and security managers are notified of new private reports if they watch the repository for all activity or subscribe to Security alerts, and have notifications enabled for the repository. To receive email, select email in your personal notification settings.
This is the step teams miss. Enabling the feature without checking notifications means reports arrive in a place nobody looks. Test it: submit a dummy report from a second account, and confirm who is alerted and how fast.
What reporters see
When enabled, researchers see a Report a vulnerability button on the repository's Advisories page. The default form asks for a summary, details, a proof of concept and an impact statement. Reporters can also submit through the REST API using a Markdown description.
Customise the form
You can add a VULNERABILITY_REPORT.yml or .yaml file to the repository's .github directory to change the form. You can also set a default form in the owner's .github repository, and the repository level form takes precedence. If GitHub cannot parse or validate the custom form, reporters see the default form.
Good fields to add: affected version, whether the issue was tested on the latest release, how the reporter wants to be credited, and a confirmation that they have not disclosed it elsewhere.
Pair it with a policy
The feature is a channel, not a policy. Add a SECURITY.md that says what you cover, how fast you aim to respond, and what reporters can expect. The documentation page I fetched does not cover that file, so check GitHub's separate guidance on it. For help on wording, see security.md or security.txt, which to publish.
After a report arrives
A private report can be turned into a draft security advisory, where you collaborate on a fix and later publish. The steps after that are in the post on fixing a vulnerability privately with a temporary private fork.
Quick check
Do we need to be a big project to use it?
No. It is a repository setting. Small projects benefit because it gives reporters a private route and a form without needing an email address on show.
Is this enough for a vulnerability disclosure process?
It covers intake. You still need triage, a fix process, advisory publishing and a policy. The other posts in this series cover those.
Safeguard's SBOM and dependency scanning, plus policies and gates, can help ensure that fixes you publish for your own project do not ship with other known vulnerable dependencies. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
