GitHub now lets you add confidential advisory comments to repository security advisories, limiting visibility to users who have write access on the repository. This change removes the need to move sensitive coordination to external channels and keeps the discussion inside the advisory’s audit trail.
What Changed
When you post a comment on a security advisory, you can now select a confidential option. Only maintainers (users with write permission) can see these comments, and they appear in the advisory timeline with a clear marker. Reporters and collaborators without write access are neither shown the comment nor notified about its existence. The visibility follows the repository’s current permission set, and any loss of write access immediately revokes the ability to read existing confidential comments. All reads are logged in the audit log. After posting, a comment cannot be switched between confidential and regular. Confidential comments are exposed through the GraphQL API but are omitted from the REST API. The feature is limited to public repositories that have private vulnerability reporting enabled on GitHub Free, Pro, Team, and Enterprise Cloud plans.
Why It Matters for Engineers
AI, cloud, and DevOps teams often need to discuss exploitation details, mitigation steps, or suspected abuse without exposing that information to external reporters or lower‑privilege collaborators. Keeping those notes inside the advisory preserves context, reduces reliance on ad‑hoc chat rooms, and ensures the discussion is captured for future reference. Security engineers gain a built‑in audit trail that aligns with compliance requirements, while SREs can continue to track investigation status directly in the platform they already monitor.
Operational and Security Implications
- Permission hygiene becomes critical. Since visibility is tied to write access, any change in team membership instantly affects who can read confidential comments. Teams should audit write permissions regularly.
- Tooling must adapt. Automation that consumes advisory comments via the REST API will no longer see confidential entries; developers needing that data must switch to GraphQL queries.
- Auditability improves. Each view is recorded, giving a traceable record of who accessed sensitive discussion. Integrations that rely on audit logs may need to ingest these events.
- Irreversibility of classification. Because a comment’s confidentiality cannot be altered after posting, users must decide the appropriate level before submitting, which may affect workflow design (e.g., draft‑then‑post patterns).
- Scope limitation. The feature only applies to public repositories with private vulnerability reporting enabled, so private repos or those without the setting will not benefit.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review your repository permission model to ensure only the intended maintainers retain write access. Update any scripts or CI pipelines that pull advisory comments to use the GraphQL endpoint if they need to process confidential data. Incorporate audit‑log monitoring to detect unexpected reads of confidential comments. Finally, embed a decision step in your advisory‑handling workflow to choose confidentiality before posting, avoiding the need to repost or delete content.