GitHubリポジトリに「SECURITY.md」が追加されたと聞くと、重大な脆弱性修正のように見えるかもしれません。今回の「GitHub documentation update: Adding Microsoft SECURITY.MD」は、アプリケーションコードの修正ではなく、Microsoft標準のセキュリティ報告ポリシーをリポジトリに追加する更新です。管理者がまず確認すべきことは、SECURITY.md の有無、脆弱性報告の受付先、Private vulnerability reportingの設定、そして開発者が公開Issueに脆弱性情報を書き込まない運用になっているかです。対象PRでは、Microsoftの標準 SECURITY.md を追加し、GitHubがこのファイルの存在をもとにセキュリティ関連の案内やファイルへのリンクを表示できるようにする意図が説明されています。(GitHub)
GitHub documentation update: Adding Microsoft SECURITY.MDの概要
今回の更新は、Microsoftの experiment-catalog リポジトリに SECURITY.md を追加するPull Requestとして行われました。GitHub上ではPR #2「Adding Microsoft SECURITY.MD」がmainブランチにマージされ、変更ファイルは SECURITY.md の1ファイルです。PR本文では、コミュニティがセキュリティポリシーと安全な脆弱性報告方法を理解できるよう、Microsoft標準の SECURITY.MD ファイルを追加するものだと説明されています。(GitHub)
追加されたMicrosoft標準の SECURITY.md では、MicrosoftがGitHub組織内のすべてのソースコードリポジトリを含めてセキュリティを重視していること、セキュリティ脆弱性を公開GitHub Issuesで報告しないこと、Microsoftリポジトリ向けの最新ガイダンスを参照することが示されています。(GitHub)
GitHubの公式ドキュメントでも、SECURITY.md はプロジェクト内のセキュリティ脆弱性をどのように報告すべきかを示すためのファイルとされています。作成時には、サポート対象バージョンと脆弱性の報告方法を記載することが推奨されています。(GitHub Docs)
| 確認項目 | 今回の更新で変わること | 管理者・開発者が見るべきポイント |
|---|---|---|
SECURITY.md | Microsoft標準のセキュリティ報告ポリシーが追加される | 自リポジトリにも明確な報告先があるか確認する |
| 公開Issueの扱い | 脆弱性を公開Issueで報告しない方針が明示される | IssueテンプレートやREADMEでも同じ案内になっているか確認する |
| GitHub上の表示 | GitHubがファイルの存在をもとにセキュリティポリシーへの導線を出せる | Security and qualityタブでポリシーが見えるか確認する |
| アプリケーションコード | コードや依存関係の直接修正ではない | デプロイ作業よりも運用ルールの確認を優先する |
SECURITY.mdは「脆弱性の入口」を整えるファイル
SECURITY.md の役割は、脆弱性そのものを修正することではありません。重要なのは、外部のセキュリティ研究者、利用者、社内開発者が「どこに、どの情報を、どのように報告すべきか」を迷わない状態にすることです。
脆弱性報告の入口が曖昧だと、次のような問題が起きやすくなります。
- 公開Issueに攻撃手順や再現コードが投稿される
- 開発者個人のSNSやメールに報告が分散する
- 重要な報告が通常の不具合チケットに埋もれる
- 報告を受けても誰が一次対応するのか決まっていない
- 修正前に脆弱性情報が広がり、利用者リスクが高まる
GitHubは、SECURITY.md の追加をリポジトリのベストプラクティスの一つとして位置づけています。公式ドキュメントでは、SECURITY.md が脆弱性報告手順を協力者に示し、責任ある開示を促すものだと説明されています。(GitHub Docs)
特にオープンソースや外部公開リポジトリでは、SECURITY.md は「あると親切」なファイルではなく、公開Issueへの誤投稿を減らすための実務的な安全装置です。
影響範囲：コードではなくリポジトリ運用に影響する
今回のMicrosoft SECURITY.MD追加は、ビルド、API、ランタイム、パッケージ依存関係を直接変更するものではありません。PRの差分は SECURITY.md のMarkdownファイル更新であり、GitHub上でも変更ファイルは1件として表示されています。(GitHub)
ただし、影響が小さいと判断して放置するのは危険です。影響するのは、開発チームのセキュリティ対応フローです。
影響を受ける人
| 対象者 | 具体的な影響 | 取るべき対応 |
|---|---|---|
| リポジトリ管理者 | セキュリティポリシーの表示、報告先、通知設定を管理する必要がある | SECURITY.md とPrivate vulnerability reportingを確認する |
| 開発者 | 脆弱性らしい報告を通常Issueや公開PRで扱わない判断が必要になる | 報告を受けた場合のエスカレーション先を把握する |
| セキュリティ担当 | 報告受付後のトリアージ、再現確認、修正、公開判断を担う | GitHub Security Advisoriesや通知設定を確認する |
| OSS利用者・研究者 | 安全な報告経路を見つけやすくなる | Security and qualityタブや SECURITY.md を確認して報告する |
影響しないもの
今回のような SECURITY.md 追加だけで、既存のコードが自動的に安全になるわけではありません。Secret scanning、Code scanning、Dependabot alerts、Push protectionなどの機能設定は別途確認が必要です。GitHub公式ドキュメントでは、公開リポジトリで最低限有効化を検討すべき機能として、Dependabot alerts、Secret scanning、Push protection、Code scanningなどが挙げられています。(GitHub Docs)
つまり、SECURITY.md は「報告の入口」、GitHubの各種セキュリティ機能は「検出・予防・修正支援」です。両方を揃えてはじめて、実務で使える脆弱性対応フローになります。
管理者が最初に確認すべき設定
SECURITY.mdが正しい場所にあるか
GitHubでは、リポジトリ内の SECURITY.md をセキュリティポリシーとして扱います。リポジトリごとに置く方法に加え、組織やアカウントの .github リポジトリに既定のコミュニティヘルスファイルとして配置する方法もあります。GitHub公式ドキュメントでは、既定ファイルは各リポジトリに同種のファイルがない場合に利用され、探索順は .github フォルダ、リポジトリルート、docs フォルダと説明されています。(GitHub Docs)
確認時は、次の順で見ると漏れが減ります。
| 確認場所 | 見るべき内容 | 判断基準 |
|---|---|---|
| リポジトリ直下 | SECURITY.md があるか | 個別リポジトリの事情を反映するなら直下配置が分かりやすい |
.github/SECURITY.md | リポジトリ内の .github フォルダにあるか | Issueテンプレートなどとまとめて管理したい場合に向く |
docs/SECURITY.md | ドキュメント配下にあるか | ドキュメント中心のリポジトリでは選択肢になる |
組織の .github リポジトリ | 既定の SECURITY.md があるか | 多数のリポジトリに共通ポリシーを展開したい場合に向く |
組織共通の .github リポジトリを使う場合、GitHub公式ドキュメントでは、ほとんどの既定コミュニティヘルスファイルを組織全体に適用するには .github リポジトリがpublicである必要があり、privateな .github リポジトリはサポートされないと説明されています。(GitHub Docs)
自社リポジトリでMicrosoftの文面をそのまま使わない
今回追加されたのは、Microsoftリポジトリ向けの標準 SECURITY.md です。Microsoft配下のリポジトリでは妥当でも、一般企業や個人開発のリポジトリがそのままコピーすると、報告者をMicrosoftの窓口へ誘導してしまう恐れがあります。
自社リポジトリで作る場合は、少なくとも次の情報を自分たちの運用に合わせて書くべきです。
| 記載項目 | 例 | 曖昧な場合に起きる問題 |
|---|---|---|
| 報告先 | セキュリティ窓口、専用フォーム、Private vulnerability reporting | 公開Issueや個人DMに報告が流れる |
| 報告してほしい情報 | 影響範囲、再現手順、PoCの有無、バージョン | トリアージに時間がかかる |
| サポート対象 | 現行メジャーバージョン、LTS版など | 古いバージョンの扱いで認識がずれる |
| 初回応答の目安 | 例：数営業日以内に受領連絡 | 報告者が放置されたと感じ、公開に踏み切る可能性がある |
| 公開方針 | 修正後にSecurity Advisoryを公開する、など | CVEや告知タイミングで混乱する |
GitHubのセキュリティポリシー作成画面でも、新しい SECURITY.md にサポート対象バージョンと脆弱性報告方法を追加する流れが示されています。(GitHub Docs)
Private vulnerability reportingとの違いを理解する
SECURITY.md と混同されやすいのが、GitHubのPrivate vulnerability reportingです。
SECURITY.md は、脆弱性をどう報告するかを説明するMarkdownファイルです。一方、Private vulnerability reportingは、セキュリティ研究者がGitHub上で非公開のまま脆弱性を報告できる機能です。GitHub公式ドキュメントでは、Private vulnerability reportingは SECURITY.md とは別の機能であり、機能が有効化されたリポジトリでのみ利用できると説明されています。(GitHub Docs)
| 項目 | SECURITY.md | Private vulnerability reporting |
|---|---|---|
| 役割 | 報告方法を説明する文書 | GitHub上で非公開報告を受け付ける機能 |
| 対象 | public/privateを問わずポリシーとして有用 | 主にpublicリポジトリの脆弱性報告で有用 |
| 設定場所 | リポジトリ内のMarkdownファイル | SettingsのAdvanced Security |
| 注意点 | 書いてあるだけでは通知や受付フローは自動化されない | 有効化しないと研究者がボタンから報告できない |
GitHub公式ドキュメントによると、Private vulnerability reportingを有効化できるのは、リポジトリ所有者、組織所有者、セキュリティマネージャー、adminロールを持つユーザーです。有効化すると、セキュリティ研究者はリポジトリのAdvisoriesページから非公開レポートを送信できるようになります。(GitHub Docs)
設定確認の手順
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | 対象リポジトリを開く | 管理権限があるアカウントで確認する |
| 2 | Settingsを開く | 設定タブが見えない場合は権限不足の可能性がある |
| 3 | SecurityセクションのAdvanced Securityを開く | セキュリティ関連機能の状態を一覧で確認する |
| 4 | Private vulnerability reportingを確認する | publicリポジトリなら有効化を検討する |
| 5 | 通知設定を確認する | 報告が届いても担当者が気付かなければ意味がない |
GitHubでは、Private vulnerability reportingで新しい脆弱性が報告された場合、条件を満たすリポジトリ管理者やセキュリティマネージャーへ通知されます。ただし通知はWatch設定や個人の通知設定に依存するため、機能を有効化しただけで安心せず、担当者が「Security alerts」または必要な通知を受け取れる状態か確認してください。(GitHub Docs)
開発チームに伝えるべき運用ルール
SECURITY.md を追加しても、開発者が読んでいなければ公開Issueへの誤投稿は防げません。管理者は、リポジトリにファイルを置くだけでなく、通常の開発フローにも反映する必要があります。
公開Issueに書いてはいけない情報を明確にする
脆弱性に関する内容は、通常の不具合報告とは扱いを分けるべきです。特に次の情報は公開Issueに書かせない運用が必要です。
- 認証回避の具体的な手順
- 攻撃に使えるPoCコード
- 未修正の脆弱性が存在するURLや環境情報
- 秘密情報、トークン、アクセスキー
- 悪用可能なログやリクエスト例
Microsoftの標準 SECURITY.md でも、セキュリティ脆弱性を公開GitHub Issuesで報告しないよう明記されています。(GitHub)
Issueテンプレートにも誘導を書く
失敗しやすいのは、SECURITY.md には正しいことが書いてあるのに、Issue作成画面では何も案内していないケースです。報告者は必ずしも先に SECURITY.md を読むとは限りません。
Issueテンプレートには、たとえば次のような案内を入れておくと実務上の事故を減らせます。
セキュリティ脆弱性に関する報告は、この公開Issueには記載しないでください。
脆弱性の疑いがある場合は、リポジトリのSecurity policyを確認し、指定された方法で非公開に報告してください。この文面は短くて十分です。重要なのは、通常の不具合報告とセキュリティ報告の入口を分けることです。
Microsoft配下のリポジトリで確認すべきこと
Microsoft関連のGitHubリポジトリを管理している場合は、今回の更新を「自分のリポジトリにも同じ標準ポリシーが必要か」を見直すきっかけにできます。PR本文では、Microsoft標準の SECURITY.MD ファイルを追加し、Microsoftの公式テンプレート由来の最新ファイルをコミットする意図が説明されています。(GitHub)
確認すべきポイントは次の通りです。
| 確認項目 | 理想的な状態 | 注意点 |
|---|---|---|
| Microsoft標準文面 | 公式テンプレートと大きく乖離していない | 独自編集で報告先が変わっていないか見る |
| 公開Issue誘導 | 脆弱性を公開Issueに書かない案内がある | Issueテンプレートにも同じ方針を反映する |
| リンク先 | Microsoftの最新ガイダンスへ誘導している | 古いURLや独自窓口が残っていないか確認する |
| レビュー履歴 | PRでレビュー・チェックを通している | セキュリティ方針ファイルは直接pushよりPR管理が安全 |
| 他リポジトリ展開 | 個別配置か組織共通配置か決めている | 同じ組織内で文面がばらつくと報告者が迷う |
Microsoft配下ではないリポジトリの場合、この更新から学ぶべき点は「Microsoftのリンクを使うこと」ではありません。学ぶべきなのは、脆弱性報告の入口を短く、明確に、GitHubが認識できる形で置くことです。
移行・展開時に失敗しやすいポイント
複数のSECURITY.mdが競合する
リポジトリ内に複数の SECURITY.md がある、または組織の .github リポジトリと個別リポジトリの両方にポリシーがある場合、どちらが表示されるのかを確認してください。GitHubは現在のリポジトリに対象ファイルがある場合はそれを優先し、なければ .github リポジトリの既定ファイルを使います。(GitHub Docs)
複数箇所にポリシーを置く場合は、次のように役割を分けると管理しやすくなります。
- 組織共通の
.githubリポジトリ：全社共通の報告窓口、禁止事項、責任ある開示方針 - 個別リポジトリの
SECURITY.md：サポート対象バージョン、製品固有の影響範囲、担当チーム
受付先だけを書いてSLAを書かない
「こちらに報告してください」だけでは、報告者はいつ返事が来るのか分かりません。特に高リスクの脆弱性では、返答がないと公開Issue、SNS、別の窓口へ情報が流れる可能性があります。
厳密な保証が難しい場合でも、次のような目安を書いておくとよいでしょう。
報告を受け取った場合、通常は数営業日以内に受領連絡を行います。
内容の確認後、必要に応じて追加情報をお願いすることがあります。断定しすぎると運用負荷になるため、実際に守れる範囲で書くことが重要です。
通知を個人アカウント任せにする
Private vulnerability reportingやSecurity alertsを使う場合、通知先が個人のWatch設定に依存していると、異動・退職・休暇で見落としが起きます。GitHub公式ドキュメントでも、Private vulnerability reportingの通知はWatch設定や通知設定に依存すると説明されています。(GitHub Docs)
管理者は、最低でも次を確認してください。
| 確認項目 | 推奨される状態 |
|---|---|
| セキュリティ担当チーム | 複数名で管理し、単一人物に依存しない |
| Watch設定 | Security alertsまたは必要な通知を受け取る |
| メール通知 | 重要報告をメールでも受け取れる |
| エスカレーション | 重大度に応じた連絡先が決まっている |
| 定期点検 | 四半期ごとなどに担当者と通知設定を棚卸しする |
SECURITY.mdを追加してセキュリティ対策が完了したと考える
SECURITY.md は入口であり、検出機能ではありません。依存関係の脆弱性、シークレット漏えい、コード上の脆弱性は、別の機能や運用で検出する必要があります。
GitHubのリポジトリセキュリティ設定では、Dependabot alerts、Secret scanning、Push protection、Code scanningなどを確認できます。これらは SECURITY.md とは目的が異なるため、セキュリティレビューではまとめて点検するのが現実的です。(GitHub Docs)
自社用SECURITY.mdの最小テンプレート
Microsoft標準ファイルをそのまま使えないリポジトリでは、次のような最小構成から始めると実務に載せやすくなります。
## Security Policy
私たちは、本プロジェクトのセキュリティを重視しています。
### Reporting a Vulnerability
セキュリティ脆弱性の疑いがある場合は、公開Issueには投稿しないでください。
以下の方法で非公開に報告してください。
- GitHubのPrivate vulnerability reportingが利用できる場合は、Securityタブから報告してください。
- それ以外の場合は、指定のセキュリティ窓口へ連絡してください。
報告時には、可能な範囲で次の情報を含めてください。
- 影響を受けるバージョン
- 再現手順
- 期待される挙動と実際の挙動
- 影響範囲
- PoCの有無
- 連絡可能なメールアドレス
### Supported Versions
現在サポート対象のバージョンは以下の通りです。
| Version | Supported |
|---|---|
| 最新メジャーバージョン | Yes |
| それ以前のバージョン | No |
### Disclosure
修正が完了するまで、脆弱性の詳細を公開しないようご協力をお願いします。
確認後、必要に応じて追加情報をお願いする場合があります。このテンプレートは、最初から完璧である必要はありません。重要なのは、公開Issueに書かせないこと、報告先を一つに絞ること、サポート対象と対応の流れを明記することです。
開発者が脆弱性報告を受けたときの対応手順
開発者個人がIssue、Pull Request、Discussion、メール、SNSなどで脆弱性らしい連絡を受けることがあります。その場合は、内容を公開の場で深掘りせず、決められた非公開フローへ移すことが重要です。
| 状況 | やること | やってはいけないこと |
|---|---|---|
| 公開Issueに脆弱性情報が書かれた | 速やかに管理者へ連絡し、必要に応じてIssueを制限・削除・編集する | 再現手順をコメントで質問する |
| 個人宛に報告が来た | SECURITY.md の正式窓口へ誘導する | 個人判断で修正PRを公開する |
| 依存ライブラリの脆弱性を見つけた | Dependabot alertsやSecurity Advisoryを確認する | 通常Issueで攻撃条件を詳述する |
| 修正が必要と判断した | 非公開ブランチやSecurity Advisoryの利用を検討する | 修正内容から脆弱性が推測できるPRを即公開する |
GitHubでは、報告された脆弱性に対してSecurity Advisoriesを使い、開示、修正、公開のプロセスを管理できます。既定コミュニティヘルスファイルのドキュメントでも、脆弱性報告後にGitHub Security Advisoriesを使って開示・修正・公開できることが説明されています。(GitHub Docs)
今回の更新を受けた実務チェックリスト
最後に、管理者がすぐ確認できる形でチェックリストを整理します。
| チェック | 確認内容 |
|---|---|
SECURITY.md が存在する | リポジトリ直下、.github、docs、組織 .github のいずれかを確認する |
| 報告先が明確 | 公開Issueではなく、非公開の報告経路へ誘導している |
| Microsoft文面の流用が適切 | Microsoft以外のリポジトリでMicrosoftの窓口へ誘導していない |
| サポート対象が書かれている | どのバージョンを受け付けるかが分かる |
| Private vulnerability reportingを確認した | publicリポジトリでは有効化を検討する |
| 通知先が複数人になっている | 管理者・セキュリティ担当が報告を見落とさない |
| Issueテンプレートに注意書きがある | 脆弱性を公開Issueに書かない案内がある |
| Security機能を点検した | Dependabot alerts、Secret scanning、Push protection、Code scanningなどを確認する |
| 開発者に周知した | 脆弱性らしい報告を受けたときのエスカレーション先を共有する |
今回のGitHub documentation updateは、派手な機能追加ではありません。しかし、SECURITY.md は脆弱性報告の入口を整える重要なファイルです。まずは自分のリポジトリで SECURITY.md が表示されるか、公開Issueに脆弱性情報が流れない導線になっているか、Private vulnerability reportingと通知設定が有効に機能するかを確認してください。ファイルを追加して終わりではなく、報告を受けてから修正・公開するまでの運用まで整えることが、今回の更新から学ぶべき実務上のポイントです。
コメント