GitHub now forces reporters of private vulnerability reports to complete four required fields—summary, details, a proof‑of‑concept of at least 150 characters, and impact—before the issue can be created. This gives AI, cloud, platform, DevOps, and security engineers a more reliable data set to triage, reduces the volume of low‑quality or AI‑generated submissions, and lets the information flow directly into the advisory description.
New mandatory form fields
The default form combines the four required inputs into the advisory description, so reviewers see a single, structured narrative. The proof‑of‑concept field enforces a minimum length, ensuring that reporters provide enough technical detail to reproduce the issue.
Customizing and enforcing the form
Repositories can replace the default form by adding a .github/VULNERABILITY_REPORT.yml file to the default branch. Organizations or accounts can place the same file in a central .github repository to apply it across all owned repositories. The form syntax follows GitHub issue form definitions, and each field can specify min_length constraints.
Additional controls include:
- Optional requirement for reporters to select a CWE identifier (configured under Settings → Advanced Security → Private vulnerability reporting).
- Ability for organization or enterprise owners to enforce the CWE requirement via policy.
- Display of a banner linking to a repository’s
SECURITY.mdwhen a security policy exists. - Checkbox for reporters to disclose AI assistance used in finding or writing the report.
API behavior and compatibility
When a custom form is present, submissions through the REST API must match the defined fields; otherwise the request fails and the error payload points to a new endpoint that returns the enforced form definition. The default form is not enforced for API calls, so existing integrations that rely on the previous free‑text model continue to work.
This behavior applies to public repositories that have private vulnerability reporting enabled on GitHub Free, Pro, Team, and Enterprise Cloud plans.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Teams should audit their current private vulnerability reporting workflow to verify that required fields align with internal triage processes. If you rely on automated ingestion of reports, update any API clients to handle the new validation rules or to fetch the form definition when a mismatch occurs. Consider adding a .github/VULNERABILITY_REPORT.yml that mirrors your internal ticket schema, and enable the CWE requirement if your risk model benefits from standardized weakness classification. Finally, monitor the AI‑assistance disclosure flag to assess the impact of generative tools on report quality and to adjust review guidelines accordingly.