- GitHub's default private vulnerability report form now requires summary, details, impact and a proof of concept of at least 150 characters. GitHub aims it at low-quality and AI-generated reports.
- The default is not enforced for the REST API. Only teams that publish a custom form hold API submissions to the same standard.
- Check that reporting is enabled, decide on an organization-wide form, and review which integrations submit through the API.
Writing a report now costs almost nothing. Reading one still costs a person's time. GitHub's latest change targets that gap. It does not try to spot bad reports. It asks reporters to show their work.
What GitHub changed
On October 1, GitHub announced a new form for private vulnerability reports. These are security reports sent privately to a project's maintainers. Before, reporters had one free-text box.
GitHub says that box made it easy to send low-quality or AI-generated reports. It also made the useful ones hard to find.
Now reporters must fill in four fields by default. They are summary, details, proof of concept, and impact. The proof of concept must be at least 150 characters. GitHub says it should be reproducible.
The answers are merged into the advisory description. Maintainers review and edit reports as they do today.
How the form works
Owners can swap in their own form. They add a file named .github/VULNERABILITY_REPORT.yml to the repository's default branch. To cover every repository they own, they add it to the organization's .github repository. If the custom form is invalid, GitHub uses the default.
The forms use issue form syntax. This is the template format GitHub uses for bug reports. Fields support a min_length setting. An owner can use it to demand more detail than the default does.
Owners can also require reporters to assign a CWE. A CWE is a standard label for the type of weakness. Organization and enterprise owners can enforce this by policy.
Repositories with a security policy now show reporters a banner. It links to the SECURITY.md file. A new checkbox lets reporters say they used AI assistance.
The API is a separate door
The default form is not enforced for the REST API. GitHub says this keeps existing integrations working.
A custom form changes that. API reports must then match it. A mismatch returns an error. The error points to a new endpoint. That endpoint returns the form the repository enforces.
The result is simple. A repository on the default form still takes API reports without those four fields. Only a custom form closes that path.
What the source does not tell us
GitHub gives no figures on how many low-quality or AI-generated reports it sees. It does not say whether the form reduces them. This is a feature announcement, not a measured result.
A 150-character minimum is also a low bar. It is about 25 words, a sentence or two. A length check measures effort, not truth.
The lesson here is narrower. The form moves the first cost of proof to the sender. Before, that cost was missing.
Why this matters beyond GitHub
Think of a customs declaration. It does not stop every bad shipment. It makes the sender state what is inside. Inspectors then start with a claim they can test.
A reproducible proof of concept does the same for a vulnerability claim. The reader can try it.
The feature covers public repositories with private vulnerability reporting enabled. It is available on GitHub Free, Pro, Team and Enterprise Cloud. If your company publishes open-source code, your engineers read these reports.
Questions to put to your team
First, is private vulnerability reporting on for our public repositories? Who reads what arrives?
Second, do we want a custom form? We could set it once at the organization level, with stricter minimum lengths.
Third, do any of our tools or partners submit through the API? Would a custom form break them?
Fourth, should reporters have to assign a CWE? Fifth, does each repository have a SECURITY.md that says what we expect?
A report is only useful if someone can act on it. The cheapest filter is a form that asks for evidence. It saves a person the time spent finding out there was none.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
