Turn on GitHub private vulnerability reporting: steps and form

Repository owners and admins can enable private vulnerability reporting from Settings, under Advanced Security. Once on, a Report a vulnerability button appears on the repository's Advisories page, and reporters can send a private report instead of opening a public issue. It takes under a minute to set up.

Why a private channel helps

Without one, a researcher who finds a flaw has two bad choices: post it in a public issue, or hunt for a contact address. Maintainers who are already stretched end up triaging emails in the open. A private channel keeps details out of public view until a fix is ready and gives the report a predictable place to land.

The steps

1. Open the repository's main page on GitHub.
2. Click the Settings tab. If it is not visible, open the More dropdown and select Settings.
3. In the sidebar, in the Security and quality section, click Advanced Security.
4. Next to Private vulnerability reporting, click Enable.

To turn it off, click Disable in the same place.

What reporters see

When the feature is on, the Report a vulnerability button appears on the Advisories page. Reporters can also submit through the REST API, and API submissions must include the required sections of any custom form that applies to the repository.

By default the form asks for a summary, details, a proof of concept and an impact statement. That is a reasonable set, and it saves you a round of questions.

A custom form

You can add a VULNERABILITY_REPORT.yml or .yaml file in the repository's .github directory to define your own form. A form in the owner's .github repository acts as the default for all repositories, and a repository level form takes precedence over it. If GitHub cannot parse or validate your custom form, reporters see the default form instead.

Use a custom form to ask for the affected version, the environment, and whether the issue is already public. Keep it short, because long forms discourage good reports.

What to do after you enable it

1. Add a short security policy that tells people what to expect. See security policy file for a GitHub repo.
2. Decide who receives notifications, and make sure at least two people can respond, so a single absence does not stall a report.
3. Agree on a response time you can keep. State it only if you will meet it.
4. Test the flow by submitting a harmless report yourself.

For consumers of open source

If a project you depend on has no private channel, a polite request to enable one helps everyone. It is a small ask, and it makes the project safer to depend on. To see what makes a report useful, read what a good vulnerability report contains.

Safeguard's SBOM and dependency scanning show which of your dependencies need attention, and you can try a free scan.

Quick check

Sources

• GitHub Docs: configuring private vulnerability reporting for a repository

Last reviewed: 19 October 2026.