Pimp My IDE / security comms
Back to garage
October 4, 2026 | GitHub / advisories / disclosure

Give the side channel a record.

GitHub security advisories now let maintainers hide one comment from reporters and invited collaborators. That keeps sensitive investigation notes in the case history instead of scattering them through chat.

Use the new lane for suspected abuse, internal coordination, and investigation details. Keep the reporter-facing question, fix status, disclosure date, and credit decision in the shared lane.

The useful change is record custody.

On October 2, GitHub added confidential comments to repository security advisories. A maintainer can select "Confidential. Only maintainers will see this comment" before posting. People with write access can see the comment. Reporters and invited collaborators without write access cannot see it and do not receive a notification.[1]

The practical win is not secrecy by itself. It is continuity. GitHub says teams previously moved abuse concerns, investigation details, and coordination notes into another system. The advisory then lost part of its own history. A confidential comment keeps that note beside the report, patch work, and eventual publication.

A private note is useful when it preserves the case record. It is dangerous when it hides the case decision.

Visibility follows current write access.

The audience is permission-based, not a hand-picked list. GitHub says current repository write access controls visibility. If a person loses write access, that person can no longer read confidential comments. Views appear in the audit log.[1]

That makes each comment a live access-control decision. Before posting, name why the reporter should not see it. Check who currently has write access. Do not assume that yesterday's maintainer roster still defines today's audience.

The control is also one-way. GitHub says a posted comment cannot switch between regular and confidential. If you choose the wrong lane, a later toggle cannot repair the audience decision. Read the text and recipient class before posting.

The API paths do not match.

GitHub says confidential comments are available through GraphQL but are not returned by the REST API.[1] Any bot that mirrors advisory activity needs an explicit test for this difference. A successful REST export is not proof that the full maintainer record was copied.

Record which interface produced an archive. If a retention or incident-review process needs confidential comments, test the GraphQL query with an account that has the required access. Then verify the export against a known confidential marker. Do not log real vulnerability details in a test fixture.

Keep coordinated disclosure shared.

GitHub's advisory documentation describes a longer job. Maintainers discuss impact, collaborate on a fix in a temporary private fork, and publish the advisory after a patch is released. It recommends adding a fix version before publication when possible.[2]

The OpenSSF finder guide describes coordinated vulnerability disclosure as private reporting, fix creation and testing, then disclosure to downstream users with the mitigation ready. It also tells reporters to state disclosure timing and constraints early.[3]

A confidential maintainer comment does not complete any of those steps. Use it for material that would harm the investigation or expose someone. Put requests to the reporter, reproducible findings they need to answer, expected dates, fix status, and credit decisions in the shared record unless there is a specific reason not to.

Interactive makeover / recipient pressure door

Choose the lane. Keep the handoff.

This replaces an unlabeled side conversation with a visibility selector, recipient map, four decision checks, and a copyable handoff. It models a review decision. It does not post to GitHub or inspect repository permissions.

Pressure door

Planning model

Choose who needs the note. Then select the checks that the real advisory process must complete.

Comment visibility
Decision checks

Recipient map

Shared lane selected
ReporterCan read and reply
Invited collaboratorCan read and reply
Repository writerCan read and reply
0 of 4 decision checks selected

The shared lane is selected. The reporter stays in the conversation.

Selected checks are requirements, not evidence. This page cannot see write access, advisory comments, audit logs, fix versions, or disclosure dates.
Team rule / copyable start

Write the reason before the hidden note.

A short policy keeps the confidential lane narrow. Put it beside the advisory runbook and test the export path before a real incident needs it.

  1. Use a shared comment for reporter questions, requested evidence, fix progress, expected dates, and credit.
  2. Use a confidential comment for suspected abuse, internal investigation details, or coordination that would expose people or weaken the response.
  3. Before posting, review the current repository writers. The recipient class follows that permission.
  4. Give every confidential action a named owner and a date for a shared update.
  5. Test GraphQL-based retention with synthetic content. Do not treat a REST export as complete.

Stop condition: if the team cannot state why the reporter must be excluded, use the shared lane.

Sources read

Source log and evidence boundary
  1. GitHub Changelog, "Confidential comments on repository security advisories", published October 2 and read October 4, 2026. It documents the visibility rule, lack of reporter notifications, permission changes, audit logging, one-way comment type, API difference, availability, and intended uses.
  2. GitHub Docs, "Repository security advisories", read October 4, 2026. It documents the draft, private-fork, publication, CVE, fix-version, and Dependabot parts of the advisory process.
  3. OpenSSF Vulnerability Disclosures Working Group, finder guide, read October 4, 2026. It supplies the coordinated disclosure model, security-policy guidance, reporter expectations, timing advice, and report-content checklist. The repository identifies the document as CC BY 4.0.

Evidence boundary. GitHub documents the shipped control and its access behavior. GitHub and OpenSSF document the larger disclosure process. Pimp My IDE designed the recipient map and handoff. This page did not create a live advisory, inspect a repository permission set, or test the GraphQL response.