GitHub adds structured forms for private vulnerability reports

GitHub has changed private vulnerability reporting from a mostly free text submission flow into a structured form for public repositories that have the feature enabled. The company says the new default asks reporters for four required pieces of information: a summary, details, impact, and a reproducible proof of concept of at least 150 characters. The answers are combined into the draft security advisory, so maintainers can still review and edit the report before acting on it.

The update is aimed at a familiar problem for open source maintainers and security teams. A blank report box can attract vague bug claims, incomplete security findings, and AI assisted reports that are hard to triage. Structured fields do not prove that a report is valid, but they can force more useful evidence to the front of the workflow.

What changed for maintainers

Repositories can use the default GitHub form or define their own by adding a .github/VULNERABILITY_REPORT.yml file to the default branch. Organizations and account owners can apply a form across repositories through their .github repository. GitHub says the forms use issue form syntax and support min_length, which gives maintainers a way to require more detail in selected fields.

• Maintainers can require reporters to assign a CWE before submission.
• Organization and enterprise owners can enforce the CWE setting through policy.
• Repositories with a security policy now show reporters a banner linking to SECURITY.md.
• Reporters can disclose whether they used AI assistance to find or write the report.

The REST API behavior is more cautious. GitHub says custom forms are enforced for reports submitted through the API, while the default form is not enforced there so existing integrations keep working. If an API submission does not match a custom form, the error points to an endpoint that returns the repository's enforced form.

Why it matters

The practical value is triage quality. Security teams still need to verify the bug, reproduce the issue, assess exploitability, and coordinate disclosure. The difference is that a maintainer can now ask for the same minimum evidence every time, rather than turning each weak report into a back and forth.

For projects that already receive high quality reports, the change should feel like housekeeping. For projects facing noisy submissions, especially after AI tools made it easier to generate plausible vulnerability writeups, the decision rule is simple: use the default form first, then customize only the fields that consistently waste reviewer time. Overly strict forms can push legitimate reporters away, so the best version is specific enough to improve signal without becoming a paperwork wall.

GitHub says the feature is available for public repositories with private vulnerability reporting enabled across GitHub Free, Pro, Team, and Enterprise Cloud.

Sources

• github.blog

Cover photo by Negative Space on Pexels, used under the Pexels License.