GitHub confidential advisory comments: check the audience before posting
Can the reporter read the internal note you just added to a vulnerability investigation? In security coordination, identifying the audience comes before polishing the sentence. GitHub's October 2 announcement adds confidential comments within repository security advisories, keeping internal discussion alongside the advisory history.
According to the announcement, confidential comments are visible to people with repository write access. Reporters and invited collaborators without that permission cannot read them or receive notifications. The diagram proposes a pre-submission review sequence; it is not a product screenshot.
Confidential follows current permissions
This is not a private note visible only to its author. Current repository writers are the audience, and losing write access removes access. The confidential label and the current membership of the write-access group are therefore separate questions worth reviewing.
The announced scope is public repositories with private vulnerability reporting enabled, on Free, Pro, Team, and Enterprise Cloud. This article does not propose widening permissions or excluding reporters. It proposes writing internal investigation notes and external technical explanations according to their different purposes.
The type cannot be switched after posting
A posted comment cannot be switched between regular and confidential. Add a short review of audience, content, and selected type immediately before submission. Drafting an investigation hypothesis and reviewing the shareable facts separately can reduce mistakes before anything is sent.
For example, review internal responder assignments and unconfirmed hypotheses in one draft, while a reporter-facing message contains verified reproduction results. This is a suggested team practice, not a GitHub-required form. Do not use real vulnerabilities or secrets as test comments.
Missing from an API is not missing from the record
GitHub states that confidential comments are available through GraphQL but are not returned by REST. An archive built only from REST comments should not be described as the complete investigation history. Record both the collection path and the reader's permission context.
Views of confidential comments are recorded in the audit log. An access record is nevertheless different from a copy of the comment body. In export and search tools, document the API used and the audience checked; label inaccessible coverage as unverified. The integration problem is distinguishing absence from lack of visibility.
Validate the workflow with harmless text
Design a test in an advisory owned by the team using non-sensitive sentences to inspect type selection and audience visibility. Have the responsible person review the advisory, account, and permissions before execution. Compare the visible type with the collector's output, then write the result into the operating guide.
More internal space can also leave collaborators without useful information. Maintain a separate obligation to explain progress, reproduction results, and shareable actions to reporters. This article verifies the announced feature, permission boundary, and API distinction; it makes no unsupported claims about security improvement or response speed.