GitHub makes reproducible evidence part of private vulnerability intake

Four fields before submission

GitHub announced structured private vulnerability reports on October 1. The default form requires a summary, details, a proof of concept of at least 150 characters, and impact. Maintainers can customize forms through a repository file and require a weakness classification. Reporters can disclose AI assistance. Custom forms also affect REST API submissions, while the default form is not enforced for existing API integrations.

That last distinction matters when assessing the reach of the change. A better browser form does not necessarily improve every route through which reports arrive. Maintainers should understand which submission paths their project uses before assuming all reports now meet the same standard. The announcement describes a more structured intake mechanism, rather than a guarantee that the submitted material is complete or technically sound.

Source: GitHub: Structured forms for private vulnerability reports

Analysis: Detail is useful when it is testable

A long report can still be wrong. The more useful contribution is a small example that connects a specific input, affected version and observable result. A reviewer should be able to distinguish an actual trust-boundary violation from a behavior the software intentionally permits. Requiring an impact explanation makes that reasoning visible, though it cannot perform the reasoning for either participant.

The AI disclosure field adds context without settling credibility. Human-written reports can be mistaken, and AI-assisted reports can contain valid discoveries. Treating the label as the verdict would miss the evidence. A sensible triage process asks whether the claimed outcome can be reproduced under the stated conditions, whether the reporter had the relevant permission, and which users or systems would be affected if the issue were real.

Practical implications: Design for the reviewer’s next step

A project-specific form can ask for the details that repeatedly go missing: installation mode, relevant configuration, exact version and a safe reproduction. The best fields reduce another round of clarification. Requiring unrelated information simply moves administrative work onto the reporter and may discourage a concise, useful submission. Form design should follow the project’s actual failure modes.

Maintainers can evaluate the update by comparing clarification rounds and time to a confirmed decision. They should also check custom forms through both browser and API paths, especially if a reporting service already integrates with the repository. GitHub’s new structure creates an opportunity to improve the evidence available at intake. Whether it produces faster repairs will depend on the quality of that evidence and the people responsible for acting on it.