GitHub のセキュリティアドバイザリーにコメント API、公開リポジトリ限定で削除は未対応

GitHub のリポジトリのセキュリティアドバイザリーについたコメントを、REST API で一覧・取得・追加・編集できるようになった。2026年10月2日に GitHub Changelog で public preview として告知されたもので、対象は GitHub Free、GitHub Pro、GitHub Team、GitHub Enterprise Cloud の公開リポジトリだ。非公開の脆弱性報告（private vulnerability reports）から作られた advisory も対象に含まれる。

ただし、triage の記録を API でそっくり抜き出せるわけではない。confidential コメントはこのエンドポイントから返らず、コメントの削除も API ではまだできない。監査や移行のためにエクスポートを組むなら、取れるのは confidential を除いたコメントだけで、後片付けは API の外に残る。この前提で設計する必要がある。

使える操作は4つ、一覧は更新時刻で絞れる

Changelog が挙げている操作は次のとおり。

• advisory のコメント一覧（指定した時刻以降に更新されたものだけに絞り込める）
• 単一コメントの取得
• コメントの追加
• コメントの編集

これまで advisory 上の議論は Web UI からしか見られなかった。GitHub は告知の中で、その議論が脆弱性報告の triage で最も役に立つ文脈を持っていることが多い、と書いている。想定用途として挙がっているのは、監査や移行のための議論のエクスポート、triage メモの自動追加、issue や pull request と同じ形で動く advisory 向けワークフローの構築だ。

更新時刻で一覧を絞れるので、前回の取得以降に動いたコメントだけを拾う定期ジョブは組みやすい。リクエストのパスやパラメータ名は告知本文には載っていないため、実装の前に REST API ドキュメント側で確かめることになる。

件数フィールドが数えるもの

コメント本体とは別に、レスポンスに件数が加わった。repository security advisory のレスポンスにはその advisory のコメント数が、global advisory のレスポンスには紐づく repository advisory のコメント数が入る。コメントを取りに行く前に、議論が付いている advisory を見分けるためのフィールドである。

注意したいのは数え方だ。この件数は非 confidential のコメントだけを数える。件数が 0 の advisory でも、confidential コメントまで無いとは言えない。件数を見て「議論なし」と判断し取得をスキップする実装は、confidential 側の議論を最初から視野の外に置くことになる。

権限は advisory 本体の可視性に従う

コメントへのアクセスは advisory そのものと同じ規則で決まる。前提として advisory を閲覧できる権限があり、そのうえで repository security advisories の read または write の権限、またはトークンのスコープが要る。advisory を見られない人は、そのコメントも見られない。

どの操作に read と write のどちらが要るかの対応は告知には書かれていない。triage メモの追加や編集まで自動化するなら、write を持たせる前提で権限を設計しておくのが無難だ。

コラボレーターでない利用者は internal comments を見られない、とも明記されている。同じ日には「Confidential comments on repository security advisories」というリリースも Changelog に並んでいる。メンテナー間だけで共有するコメントの仕組みは advisory の報告者から見えないコメント で扱った。告知でいう internal comments と confidential comments が同じものを指すのかは、この告知の文面からは判断できない。

監査用エクスポートで抜け落ちるもの

エクスポートを組む前に、取れない範囲を並べておく。

• confidential コメント。REST エンドポイントは返さない。件数フィールドにも含まれない。
• 公開リポジトリ以外の advisory。public preview の対象は公開リポジトリだけだ。
• 削除操作。ボットが誤って追加した triage メモを API から消す手段は、今のところない。

監査の証跡として使うなら、エクスポート結果に「confidential を除く」と明記しておかないと、後から読む人が全量だと誤解しかねない。移行先へ議論を写す場合も、confidential 側の内容は別経路で扱う必要がある。public preview の段階なので、エンドポイントの仕様が今後どう変わるかもまだ分からない。

GitHub App で動かすならトークンの長さも確認する

triage ボットを GitHub App のインストールトークンで動かしている場合は、同じ 10月2日に告知された別の変更にも関係がある。2026年4月27日に始まった stateless 形式への段階移行が完了し、新しく発行されるインストールトークンは ghs_ で始まる約 520 文字の文字列になった。従来は 40 文字だった。

GitHub は、トークンを 40 文字固定と見なす検証、長さ上限の小さい DB カラムやシークレットストア、長い Authorization ヘッダーを切り詰めるプロキシ、旧形式だけに一致するログのマスキング規則を点検するよう求めている。新形式を試すための一時ヘッダー X-GitHub-Stateless-S2S-Token は 2026年11月30日に廃止される。コメント API を新たに組み込むついでに、トークンの扱いも同じタイミングで見直しておくとよい。