You maintain a public library and receive a security report. The message claims that a user can access a resource that does not belong to them, but it does not specify the version or reproduction conditions. You must respond, understand the scope, and organize a discussion among maintainers, without exposing the details of the report.
This fictional scenario serves as a guiding thread. The GitHub developments of October 1 and 2, 2026 provide reception and coordination tools. They do not exempt from qualifying the reality of the problem. The protocol presented here is a Partitech proposal, without any real vulnerability or exploitation test.
Three levers for the same reception circuit
GitHub announced on October 1 structured forms for private reports. Maintainers can customize the requested information with a file .github/VULNERABILITY_REPORT.yml. The default form specifically requests a summary, details, demonstration, and impact. A completed form improves the organization of information; it does not validate the reporter's statement.
The same day, submission limits are announced. They relate to the new reports. Administrators can set an overall daily limit for repositories and designate trusted reporters. Comments on existing advisories are not affected.
On October 2, confidential comments become available. Their access follows the current write permissions of the repository. The reporter and invited collaborators without these rights do not see them. The announced scope concerns public repositories that have enabled private vulnerability reporting.
These three levers address different difficulties: obtaining the right information, managing the arrival of new files, and choosing the recipients of a discussion. None automatically measure the severity of a flaw. A brief file can be important; a very long file can remain impossible to reproduce.
Request a usable reproduction
In our example, the first answer should allow understanding the situation without asking for customer data. Which version is concerned? What behavior is expected? What behavior was observed? What rights did the account used have? These questions limit a local reproduction.
The form provided below is an editorial template, not a ready-to-deploy YAML file. It is used to choose the information before validating the syntax against the GitHub documentation.
| Requested information | Usefulness for the maintainer |
|---|---|
| Version and environment | Find the concerned behavior |
| Prerequisites | Identify the necessary rights and configuration |
| Harmless local steps | Understand the journey without touching a third party |
| Expected and observed | Distinguish the gap from normal behavior |
| Presumed scope | Examine what would actually be accessible |
| Limitations of the trial | Avoid generalizing a single result |
Encourage the use of synthetic accounts and data. Do not request access tokens, production database copies, or personal information. If evidence includes sensitive data, have its existence and role specified without reproducing it in the form.
The demonstration, often called a proof of concept, serves to make a behavior observable. Its length does not determine its validity. In an AI-assisted report, check the links, versions, and steps exactly as in any other report. The origin of the text is not enough to conclude good or bad faith.
GitHub specifies an important difference for integrations : a custom form is required for REST submissions, whereas the default form is not. REST here refers to an interface that allows a program to send a report. If you customize the form, monitor the operation of your integrations; the result in the browser does not cover this second path.
Limit the flow without losing useful reports
A submission limit affects the number of new cases, not their value. Before changing a setting, look at what is slowing down your team: lack of versions, duplicates, no responsible person, or actual volume. A flow measure does not fix a triage circuit without an owner.
Triage is the initial assessment of the file. It involves understanding what is described, checking the conditions, and guiding the next steps. It does not necessarily mean immediately declaring a confirmed flaw or closing the report without response.
Plan an alternative path in your security policy for a legitimate person blocked by a limit. This path should allow confidential contact known to the maintainers. It should not lead to posting sensitive details in a public issue. Check who receives the messages and who replaces this person in case of absence.
The list of trusted reporters also deserves monitoring. Define who can add someone to it, how to review this trust, and when to remove an entry. The status should facilitate contact with known contacts, without becoming a forgotten exemption.
For a duplicate, link the new file to the existing follow-up without disclosing confidential elements from another report. Explain to the reporter what you can communicate and the next step. An understandable response prevents them from interpreting an administrative closure as abandoning their report.
Choose visibility before posting a comment
In our scenario, the team wants to discuss a reproduction hypothesis and a possible fix. Part of this discussion may be useful to the reporter; another part pertains to internal coordination. Choose the visibility based on the content and the actual recipients.
| Content to share | Review question |
|---|---|
| Request for clarification from the reporter | Is it readable in the channel that he is consulting? |
| Internal qualification hypothesis | Should all current holders of write permission receive it? |
| Fix coordination | Which manager should receive the information? |
| Unnecessary sensitive information | Can it be withdrawn before any publication? |
GitHub indicates that confidential visibility cannot be changed after publication, that reads are recorded in the audit log, and that the support differs between GraphQL and REST: these comments are available in GraphQL, but not returned by REST at launch. If your tracking tool only uses REST, a lack of comments therefore does not prove the absence of discussion.
Confidentiality depends on current rights, not on a fixed list at the time of writing. The departure of a maintainer must be handled in access management. Conversely, a person newly granted write rights can enter the reading scope. Check the rights before choosing the channel for particularly sensitive content.
Build a circuit that leads to a decision
For each file, keep a simple sheet: date of receipt, presumed component, version, reproduction status, owner, and next action. The status 'missing information' must indicate which ones. The status 'confirmed' must refer to what has been observed. A hypothesis remains a hypothesis until this stage.
In our fictional bug, you could first request the version and access conditions, then reproduce it only with two synthetic accounts in a local environment. If the behavior is normal and documented, explain why. If a defect appears, assign the fix and organize verification before public communication. None of these operations is carried out in this article.
Measure the time until the first useful response and the number of cases still without a responsible person. These indicators describe your operation; they do not demonstrate that all significant flaws have been received. Avoid publishing details that could identify a reporter or an undisclosed vulnerability.
Before expanding the process, have a mock submission reviewed by another team member. Can they find the environment, explain the visibility, and identify the next decision? If so, your receipt produces a usable file. If not, correct the questions and responsibilities before adding new constraints for the reporters.
Sources and verification date
GitHub sources reopened on October 6, 2026: structured forms, submission limits and confidential comments. The sheet, the tables, and the scenario are original Partitech recommendations. No advisory, GitHub setting change or real report was created.