MikhbarMIKHBAR
Artificial Intelligence

GitHub Introduces Structured Forms for Private Vulnerability Reports

GitHub has updated its private vulnerability reporting feature to incorporate structured forms, aiming to help maintainers effectively filter out low-quality and AI-generated submissions.

GitHub Introduces Structured Forms for Private Vulnerability Reports

Transitioning Away from Free-Text Boxes

GitHub has officially announced that private vulnerability reports can now use a structured form that asks reporters for the details you need to assess a vulnerability, including a reproducible proof of concept. Previously, a single free-text box made it easy to submit low-quality or AI-generated reports and hard for maintainers to find the signal in them. By default, reporters are now required to fill in four distinct fields: summary, details, proof of concept requiring at least 150 characters, and impact. These answers are automatically combined into the advisory description so that maintainers can review and edit the report just as they did previously. Further details are available from GitHub Changelog in the original source material.

To help developers better understand the ecosystem and handling procedures surrounding private vulnerability reporting, users can consult the official documentation to learn more about privately reporting a security vulnerability. Further details are available from Back to changelog in the original source material.

Customizing Forms and Enforcement Settings

Maintainers looking to tailor these requirements to their specific projects can customize the form by adding a .github/VULNERABILITY_REPORT.yml file to their repository’s default branch. For those managing multiple repositories, a form can be applied across all owned repositories by adding it to the organization or account’s .github repository. These custom forms utilize issue form syntax, and individual fields support a min_length property to enforce a minimum level of detail from submitters. If a configured form turns out to be invalid, GitHub defaults to utilizing the standard system form.

Additionally, repository administrators can require reporters to assign a Common Weakness Enumeration (CWE) before submission by navigating through settings. Organization and enterprise owners are also equipped to enforce this setting uniformly via a designated policy.

AI Disclosure and Security Policies

With the rise of automated tools, the new reporting interface includes specific provisions for artificial intelligence. Reporters can check a dedicated checkbox stating 'I used AI assistance to find or write up this report' to transparently disclose AI utilization. Furthermore, if a target repository maintains an active security policy, reporters will encounter a banner containing a direct link to the SECURITY.md file prior to completing their submission.

API Integration and Availability

For workflows relying on automation, any custom forms added to a repository must also be matched by reports submitted through the REST API. GitHub ensures backward compatibility by not strictly enforcing the default form for the API, allowing existing integrations to continue functioning normally. If an API submission fails to match a custom form layout, the returned error will point directly to a new endpoint that provides the specific form enforced by the repository.

This feature update is currently available for public repositories that have private vulnerability reporting enabled across GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud plans.

Sources

Continue chronologically

Related entity coverage