GitHub’s structured forms mean eligible product teams can ask for more consistent information when someone privately reports a vulnerability. This may make reports easier to assess, but it does not resolve the underlying work of deciding severity, communicating clearly and managing remediation.

What has changed

For public repositories with private vulnerability reporting enabled, GitHub now provides a default form requiring a summary, details, proof of concept and impact. The proof-of-concept response has a minimum length of 150 characters. Submitted responses are combined into the advisory description, which maintainers can still review and edit.

GitHub says the feature is available on GitHub Free, Pro, Team and Enterprise Cloud for the eligible public repositories described above. It is not, on the supplied evidence, a statement about every repository or every vulnerability-management workflow.

The business implication: better inputs are not the same as better outcomes

A structured report can create a more predictable starting point for triage. That is useful where reports arrive with uneven context or where several people need to understand an issue quickly. However, the form does not establish who owns the decision, whether the report is credible, what customers need to be told, or how a fix should be prioritised against product commitments.

Questions for product and operations leaders

  • Who is accountable for reviewing incoming reports and making prioritisation decisions?
  • Can the team absorb potentially more detailed submissions without delaying important product work?
  • What level of evidence is proportionate for the products and users involved?
  • Will a custom form create friction for reporters or conflict with existing API-based reporting workflows?
  • How will product, engineering and customer-facing teams stay aligned when a report affects a live service?

Customisation needs a compatibility decision

GitHub allows custom forms, and states that a custom form can be enforced for REST API submissions. By contrast, the default form is not enforced for the API, allowing existing integrations to continue. For organisations that rely on API-based intake, this makes compatibility a governance question rather than a purely administrative one: a more prescriptive intake standard may affect connected reporting processes.

What to avoid

  • Assuming a longer report automatically indicates a higher-quality or higher-priority issue.
  • Treating a required field as a substitute for expert assessment.
  • Introducing a stricter form without considering the experience of legitimate reporters.
  • Separating vulnerability intake from product ownership, release decisions and stakeholder communication.

When external product support is useful

External support may be appropriate when vulnerability reporting needs to be considered alongside a wider product roadmap, user experience, platform change or operating model. The desired outcome is not simply a more detailed submission form; it is a proportionate, owned decision process that supports a reliable digital product.

OUROPT can help product teams define the ownership, user journeys and delivery priorities around secure digital products, where vulnerability-reporting changes need to fit the wider product operating model.

Explore our services →

Sources and references

  1. Structured forms for private vulnerability reportsGitHub Changelog · 1 October 2026