<style> .ga-hero{padding:clamp(24px,5vw,47px);border-radius:24px;color:#fff;background:linear-gradient(125deg,#1a1832,#563263 54%,#ab4b66)}.ga-hero h2{color:#fff;margin:.35em 0}.ga-kicker{font-size:.8rem;font-weight:800;letter-spacing:.13em;color:#f9c9dc}.ga-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.ga-card{padding:18px;border-radius:16px;border:1px solid #edc8d8;background:#fff4f7}.ga-card strong{display:block;color:#8b3354;font-size:1.16rem}.ga-table{overflow-x:auto;margin:20px 0}.ga-table table{min-width:650px;width:100%;border-collapse:collapse}.ga-table th,.ga-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.ga-table th{background:#fbe5ee;color:#7d2d4c}.ga-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:9px;margin:20px 0}.ga-step{padding:15px;border:1px solid #ebcdda;border-radius:14px;background:#fff8fa}.ga-step b{display:block;color:#8b3354}.ga-note{padding:16px 19px;border-left:5px solid #dc8a2e;border-radius:10px;background:#fff7e9;margin:20px 0}@media(max-width:760px){.ga-grid,.ga-flow{grid-template-columns:1fr}} </style>

SECURITY / VULNERABILITY TRIAGE

報告者との対話と、内部調査を分ける

Security Advisoryのコメントに新しい可視性の境界ができました。非公開のつもりで書いた情報を誤送信しないこと、APIエクスポートから抜け落ちる情報を理解することが鍵です。

3行で要約

• GitHubは2026年10月2日、リポジトリのSecurity Advisoryに機密コメントを追加しました。リポジトリへ書き込み権限を持つ人だけが閲覧でき、報告者など権限のない協力者には表示・通知されません。[^confidential]
• 同日、通常コメントを一覧・取得・追加・編集できるREST APIを公開プレビューで提供しました。ただし機密コメントはREST APIの応答に含まれず、コメント件数にも算入されません。[^api][confidential]
• 脆弱性対応では、報告者向けの回答と内部調査メモを明確に分け、監査・移行ツールがどの範囲を取得するかを検証する必要があります。

背景：脆弱性報告の議論は一枚岩ではない

リポジトリのSecurity Advisoryは、脆弱性の報告者、メンテナー、招待した協力者が調整する場所です。これまではコメントが協力者全員に見えていたため、悪用の疑い、内部調査、公開日程などの話題を別の連絡手段へ移すことがありました。GitHubは今回、こうした情報を同じタイムライン内で書き込み権限者に限定して議論できるようにしました。これはGitHubが示す機能と用途であり、誤操作を自動的に防ぐという保証ではありません。[^confidential]

同日のREST API公開プレビューは、従来Web UI中心だった通常コメントの議論を監査、移行、自動化に使えるようにする更新です。二つは関連しますが、機密コメントをRESTでも取得できるようになったわけではありません。[^api]

何が新しいのか：2種類のコメントと2種類の取得経路

GitHubは機密コメントの閲覧を監査ログに記録すると説明しています。一方、通常コメントのREST APIに返るcomments件数は機密コメントを数えません。件数が0でも内部の機密コメントが存在しないとは結論できません。[^{confidential][}api]

技術的なポイント：エクスポートの欠落を仕様として扱う

新しいREST APIは、Advisoryの通常コメントについて、一覧（更新日時による絞り込み可）、単一コメント取得、追加、編集を提供します。削除は現時点で未対応です。アクセスにはAdvisoryを閲覧できる権限と、対応するRepository security advisoriesのread/write権限またはトークンスコープが必要です。[^api]

重要なのは、API取得結果を「議論の完全な記録」と扱わないことです。機密コメントはRESTでは返らず、閲覧権限を持つ利用者でも通常コメント用エクスポートには現れません。内部メモを含む監査・移行を設計するなら、GitHubが案内するGraphQLでの可用性、権限、監査ログを別途確認する必要があります。具体的なGraphQLクエリは権限とスキーマが環境で変わり得るため、ここでは断定しません。[^{confidential][}api]

開発者・企業への影響：権限が変わると見える範囲も変わる

機密コメントの閲覧は固定されたメンバーリストではなく、現在のリポジトリ書き込み権限に従います。GitHubは、書き込み権限を失うと過去の機密コメントも読めなくなると説明しています。逆に、後から書き込み権限を得た人に何が見えるかは、導入時に実際の権限モデルで確認すべきです。[^confidential]

コメントは投稿後に通常・機密の種類を切り替えられません。したがって、内部情報を通常コメントで投稿してから「後で機密に直す」という運用はできません。投稿前の確認を手順化する価値があります。[^confidential]

実践例：1件の報告を安全にトリアージする

1. 報告者に必要な質問と対応予定は通常コメントで共有します。共有してよい情報か毎回確認します。
2. 認証情報の露出、悪用の疑い、社内対応者の調整などは機密コメントの候補です。ただし秘密そのものは専用の保管・インシデント管理経路で扱います。
3. 自動化で通常コメントを読み込むなら、Repository security advisories権限を最小限にし、REST APIの取得範囲が機密コメントを含まないと明記します。[^api]
4. 監査や移行の前に「通常コメントのみ」「機密コメントを含む内部記録」のどちらが必要かを決めます。必要な範囲を取得できたか、権限とログで検証します。これは編集上の運用提案です。

リスクと限界

• 誤投稿は戻せない。 コメントの機密区分は投稿後に切り替えられません。[^confidential]
• REST APIは完全な履歴ではない。 機密コメントは返らず、件数にも含まれません。[^api][confidential]
• 権限は変わる。 リポジトリ書き込み権限の付与・削除で、機密コメントを閲覧できる人も変わります。[^confidential]
• 提供範囲に条件。 機密コメントは、Private Vulnerability Reportingを有効にした公開リポジトリで、GitHub Free/Pro/Team/Enterprise Cloudに提供されます。コメントREST APIは公開リポジトリ向けの公開プレビューです。[^{confidential][}api]
• 脆弱性の存在を示す発表ではない。 今回はGitHubの報告・調整機能の更新であり、特定製品のCVEや侵害事件ではありません。

今後注目すべき点

コメントAPIの正式提供、GraphQLでの機密コメントの権限と監査方法、監査・移行ツールの対応です。まずテスト用の公開リポジトリで報告者、書き込み権限者、APIトークンそれぞれの見え方を確かめてから、実際の脆弱性対応に組み込むのが安全です。

最終確認日：2026年10月3日（日本時間）。 発表日は2026年10月2日。機能仕様はGitHubの一次情報、トリアージ手順は編集上の提案です。

参照元

[^confidential]: GitHub公式発表：Security Advisoryの機密コメント（2026年10月2日） [^api]: GitHub公式発表：Security AdvisoryコメントREST APIの公開プレビュー（2026年10月2日）