How to Require Reproduction Details in GitHub Vulnerability Reports
A private vulnerability report claims a serious flaw, but its proof of concept never shows it working. What does GitHub's form already demand, and how do you raise the bar?
- The default private report form requires a summary, details, proof of concept, and impact.
- Place a custom form at .github/VULNERABILITY_REPORT.yml on the default branch to set your own requirements.
- Custom requirements also apply to REST submissions; satisfying them does not validate a vulnerability.
Make reproduction details part of the submission
GitHub maintainers can require more than a free-form claim that their project is vulnerable. The October 1 reporting update introduced four required default fields, including a proof of concept of at least 150 characters. Responses become the advisory description.
The need is concrete: a maintainer posting on Reddit described reviewing an AI-generated report that, in their account, missed controller-level authentication. Other participants questioned PoCs that described theoretical impact without demonstrating it.
A length requirement asks for evidence; it cannot establish that the evidence is correct. Reproduction remains part of the maintainer’s assessment.
Put project-specific questions in a YAML form
Add .github/VULNERABILITY_REPORT.yml on the repository’s default branch. GitHub’s configuration guide provides a complete example using issue-form syntax. Use validations.required for mandatory answers and validations.min_length for minimum lengths on input or textarea fields.
A useful project-specific prompt could request the version, relevant configuration, reproduction steps, and observed result. Those are suggested questions to adapt, not a universal GitHub checklist.
An account’s .github repository can supply a shared form; a repository-specific form takes precedence. Invalid YAML or an invalid form falls back to the default. After adding it, inspect the reporting page to see whether the intended questions actually appear.
A SECURITY.md file does not enable private reporting
Enable the feature under Settings → Advanced Security → Private vulnerability reporting. The new forms apply to enabled public repositories on Free, Pro, Team, and Enterprise Cloud.
The reporter guide separates this feature from SECURITY.md. The policy gives maintainers’ reporting guidance and appears above the submission form when present. Creating that file alone does not open the private reporting channel.
Reporters may also disclose AI assistance. That is a voluntary declaration, not an automated detection result or a decision about whether the bug exists.
Custom forms also change what API submissions must contain
A REST submission’s Markdown description must include the sections and responses required by the applicable custom form. The built-in default form is exempt from API enforcement.
Adding a custom form can therefore affect an existing integration even if its API call has not changed. Follow the validation error’s reference to the applicable form and update the submitted content.
The practical outcome is a clearer request for information at intake. Check both submission paths, then assess whether the supplied reproduction actually supports the claim.