GitHub セキュリティ勧告の機密コメント：送信前に読者を確認
内部メモは報告者にも見えるのか。セキュリティ対応では文章より先に読者を確認します。GitHubは10月2日、勧告内の機密コメントを発表しました。
公式発表ではリポジトリのwrite権限を持つ人だけが読めます。権限のない報告者や招待協力者には表示も通知もされません。図は提案手順で、製品画面ではありません。
機密は現在の権限に従う
作者だけの個人メモではありません。現在のwrite権限者が読者で、権限を失うと読めなくなります。機密表示と現在の権限者は別々に確認します。
対象は非公開の脆弱性報告を有効にした公開リポジトリで、Free・Pro・Team・Enterprise Cloudです。権限拡大の提案ではありません。内部調査と外部説明を目的別に書く運用案です。
投稿後に種類を変更できない
通常コメントと機密コメントは投稿後に切り替えられません。直前に読者・本文・選択状態を確認します。仮説と確認済み事実を下書きで分けると確認しやすくなります。
内部担当者や未確認仮説を先に検討し、報告者には確認済み再現結果を説明する例です。GitHub必須様式ではありません。実際の秘密を試験コメントに使わないでください。
APIの欠落を記録の不存在と読まない
機密コメントはGraphQLで取得でき、RESTでは返されないと公式発表にあります。RESTだけの保存結果を調査全体と見なせません。取得経路と読者権限を記録します。
閲覧は監査ログに残りますが、本文の保存とは別です。出力や検索にはAPI、確認した読者、未確認範囲を示してください。見えないことと存在しないことを区別します。
無害な文章で手順を確認
チーム所有の試験勧告で非機密文を使い、種類と読者別範囲を確認する手順を設計します。担当者が対象・アカウント・権限を事前確認し、画面と取得結果を比較して記録します。
内部空間が増えると協力者への情報不足も起こり得ます。報告者への進捗・結果説明は続けてください。確認範囲は機能・権限・APIであり、安全性や速度の改善数値を推定しません。