GitHub has added confidential comments to repository security advisories, giving maintainers a way to keep selected advisory discussions visible only to people with write access to the repository. The feature is intended for conversations that may require tighter access control, such as remediation coordination or clarification of sensitive findings.
Confidential comments are available for eligible public repositories with private vulnerability reporting enabled. GitHub says the feature is available on GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. However, access is controlled by repository write permissions—not simply by a person’s status as an advisory collaborator or vulnerability reporter.
What changed in repository security advisories
When posting a comment in a repository security advisory, an eligible user can select the Confidential option below the comment box. The resulting comment is visibly marked in the advisory timeline, but its content is restricted to people with write access to the repository.
That rule applies to both viewing and creating confidential comments. Advisory collaborators who do not have write access cannot create or view them. GitHub’s documentation specifically notes that this includes people who privately report vulnerabilities when those reporters do not also have repository write access.
People without write access also do not see confidential comments or receive notifications about them, according to GitHub’s announcement. Losing write access likewise removes a person’s ability to read confidential comments. In practice, maintainers should treat repository write access as the audience boundary for this feature.
Confidentiality is selected when the comment is posted and cannot be changed afterward. A comment cannot be converted from confidential to regular, or from regular to confidential. Authors should therefore confirm the intended audience before publishing sensitive information.
Why the access model matters
Repository security advisories already provide a place for maintainers of public repositories to discuss and fix vulnerabilities before publishing an advisory. Confidential comments add a narrower visibility option within that workflow, allowing maintainers to retain discussion in the advisory timeline without making every comment available to all advisory participants.
The distinction between advisory participation and repository access is important. A researcher may submit a privately reported vulnerability and participate in the advisory process, but that does not by itself grant access to confidential comments. If the researcher does not have write access, the comments remain unavailable to them.
The supplied permissions documentation also states that users with applicable write or administrative permissions can edit and delete comments in a security advisory. It does not separately define confidential-comment-specific editing or deletion rules. Administrators should avoid assuming that every administrative permission scenario provides access to confidential comments unless the user also has the required write access.
GitHub says views of confidential comments are recorded in the audit log. The available documentation does not specify the exact audit event name, recorded metadata, retention period, or visibility of that audit information.
Availability and repository requirements
The feature was announced on October 2, 2026. GitHub identifies public repositories with private vulnerability reporting enabled as the eligible environment, and lists GitHub Free, Pro, Team, and Enterprise Cloud as supported plans.
Private vulnerability reporting is configured at the repository level. According to the repository configuration documentation, an owner or administrator of a public repository can enable it by opening Settings, selecting Advanced Security under Security and quality, and choosing the enable or disable option for Private vulnerability reporting.
Once enabled, researchers can submit reports through the repository’s Advisories page. The announcement’s plan and availability statement should be treated separately from the configuration documentation: the configuration reference confirms how public repositories enable private vulnerability reporting, but does not independently reproduce the full plan eligibility list for confidential comments.
API and workflow considerations
Confidential comments are available through GitHub’s GraphQL API, while the REST API does not return them. This matters for teams that synchronize advisory discussions with internal tooling or build reporting around repository security data. A REST-based integration should not be expected to retrieve confidential comments.
GitHub has not supplied, in the referenced material, the specific GraphQL types, fields, mutations, permission checks, or limitations for these comments. Teams should therefore avoid building against assumed operation names or undocumented response fields.
The supplied sources also do not establish webhook, export, or integration behavior for confidential comments. They confirm that people without write access are not notified about the comments, but they do not document how other notification channels or external systems handle them.
What developers and administrators should do
- Confirm repository eligibility. Make sure the repository is public and that private vulnerability reporting is enabled.
- Review the intended audience. Before posting, verify that everyone who needs to read the comment has repository write access.
- Select confidentiality before publishing. The visibility setting cannot be changed after the comment is posted.
- Use the feature for appropriate advisory discussions. Confidential comments can help limit selected remediation details to repository users with write access, but they are not described as a guarantee against every form of disclosure.
- Choose the API carefully. Use GraphQL when confidential comments must be accessed programmatically. Do not assume that the REST API will return them.
- Check access changes. Removing a user’s write access also removes their ability to read confidential comments.
Teams should also account for the fact that the feature’s confidentiality is fixed at creation time. If a comment is posted with the wrong visibility, the supplied documentation does not describe a complete correction workflow. That makes a pre-publication review especially important for sensitive advisory content.
Important limitations
The available documentation leaves several implementation details unspecified. It does not provide confidential-comment-specific GraphQL examples, exact audit-log metadata, webhook behavior, export behavior, or a complete description of notification handling. It also does not resolve whether a repository administrator without write access can view confidential comments.
GitHub’s announcement establishes the listed plan availability and the October 2, 2026 release date, but the supplied sources do not confirm whether deployment is universal, gradual, region-specific, or subject to additional account-level restrictions. Administrators should verify that the option appears in the target repository before designing a workflow around it.
For maintainers who already use private vulnerability reporting, the practical change is a more restricted comment visibility choice inside the advisory process. The key operational rule is straightforward: confidential comments are for repository users with write access, and that audience should be confirmed before sensitive information is posted.
