GitHub の private vulnerability reporting で必須になった4項目と PoC 150文字以上、独自フォーム、CWE 必須化、REST API 連携への影響を整理する。
150文字以上 既定フォームで求められる PoC の最低文字数 GitHub Changelog（2026年10月1日）。summary・details・impact と並ぶ必須4項目の一つ
GitHub の private vulnerability reporting（非公開の脆弱性報告）で、報告者が自由記述欄ひとつで送る形が終わった。2026年10月1日の GitHub Changelog によると、既定では summary・details・proof of concept・impact の4項目が必須で、proof of concept は150文字以上を求められる。対象は private vulnerability reporting を有効にした public リポジトリで、プランは GitHub Free、GitHub Pro、GitHub Team、GitHub Enterprise Cloud だ。
メンテナー側の受け取り方は変わらない。4項目の回答はひとつにまとめられて advisory の説明文に入り、これまでどおりレビューして編集する。何もしなくても既定フォームが効くので、設定を触らずに済ませることもできる。手を入れる理由があるのは、項目を増やしたい、もっと詳しく書かせたい、CWE を必ず付けさせたい、というチームだ。
Changelog は理由として、自由記述欄ひとつでは質の低い報告や生成AI由来の報告を出しやすく、メンテナーがその中から本当の問題を見つけにくかったことを挙げている。再現可能な PoC を必須にしたのはそのためだ。
同じ日に別の Changelog で、報告の レート制限 も入った。新規報告の数をユーザーごと・日ごとに制限し、上限に達した報告者には後で試すよう求めるメッセージが出る。既存 advisory へのコメントは制限の対象外だ。リポジトリ管理者はリポジトリ全体の1日あたりの報告上限を独自に決められ、信頼する報告者を allow list に入れて制限から外すこともできる。フォームが報告の中身を、レート制限が報告の量を絞る組み合わせになっている。
既定の4項目で足りなければ、リポジトリの default branch に .github/VULNERABILITY_REPORT.yml を置く。書式は issue form の構文 で、各フィールドに min_length を付けて最低限の記述量を要求できる。
所有するすべてのリポジトリに同じフォームを使いたいなら、組織またはアカウントの .github リポジトリに置く。リポジトリ側と組織側の両方にファイルがある場合にどちらが優先されるかは、Changelog には書かれていない。
気をつけたいのは、フォームが不正なときの挙動だ。その場合は黙って既定フォームが使われる。YAML の書き間違いでエラーが出て報告を受け付けなくなることはないが、独自に足した項目が報告者に表示されていないことに気づきにくい。ファイルを置いたら、報告画面に自分の項目が出ているかを一度確かめておくとよい。
フォームとは別に、報告者が送信前に CWE を付けることを必須にできる。設定場所は Settings > Advanced Security > Private vulnerability reporting で、組織とエンタープライズのオーナーは policy でこの設定を強制できる。レート制限の設定も同じ画面の「Private vulnerability reporting」の横にある Settings から開く。
報告者の画面には、ほかに2つの変更がある。
SECURITY.md へのリンクを載せたバナーが出るAI 利用の申告は報告者が自分で付けるチェックボックスで、Changelog の範囲では必須とはされていない。チェックがないことを「AI を使っていない」証拠として扱える材料はない。
既存の自動化が壊れるかどうかは、独自フォームを置くかどうか で分かれる。
既定フォームは REST API には強制されない。スキャナーや社内ツールが API 経由で報告を送っていても、リポジトリが既定フォームのままなら今までどおり通る。
独自フォームを置くと話が変わる。API で送られた報告もそのフォームに合っている必要があり、合わなければエラーになる。そのエラーは、リポジトリが強制しているフォームを返す新しいエンドポイントを指す。新エンドポイントの名前やレスポンスの形は Changelog の本文には出ていない。
順番としては次のようになる。
組織の .github リポジトリにフォームを置くと、所有するすべてのリポジトリの API 送信が一度に対象になる。組織単位で入れる前に、どのリポジトリに API 連携があるかを確認しておきたい。
脆弱性の届き方に関する変更としては、npm 側でもリカバリーコードでのサインイン後に publish が止まる措置が全アカウントに広がっている（npm のセキュリティホールドの記事）。メンテナーのアカウントを守る話と、受け取る報告の質を保つ話は別々に進んでいるので、両方を見ておくとよい。