2026年5月2日に確認された「GitHub Docs documentation update: Create SECURITY.md for security policy」は、GitHub Docsの機能追加というより、GitHub Docsリポジトリにセキュリティポリシー文書を追加しようとしたドキュメント更新案です。要点は、SECURITY.mdで「サポート対象バージョン」と「脆弱性の報告方法」を明文化することにあります。
ただし、確認時点のGitHub PR #44059はClosedであり、差分はSECURITY.mdを1ファイル追加する内容です。GitHub Docsの利用者がすぐに移行作業を迫られる変更ではありません。一方で、GitHubでリポジトリを公開・運用しているチームにとっては、自分たちのSECURITY.mdが実運用に合っているかを見直すよいタイミングです。特に、脆弱性報告をPublic Issueに誘導していないか、サポート対象バージョンが曖昧になっていないか、報告後の対応フローが決まっているかを確認しましょう。
GitHub Docs documentation update: Create SECURITY.md for security policyで確認すべき変更点
今回の「GitHub Docs documentation update: Create SECURITY.md for security policy」は、GitHub DocsリポジトリにSECURITY.mdを作成し、セキュリティポリシーを明文化する提案です。PR本文では、サポート対象バージョンと脆弱性報告に関するセキュリティポリシー文書を追加したと説明されています。(GitHub)
PRの差分としては、SECURITY.mdが1ファイル追加され、21行の追加のみが確認できます。内容は、サポート対象バージョンを表で示すセクションと、脆弱性の報告方法を説明するセクションで構成されています。(GitHub)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 対象ファイル | SECURITY.md | リポジトリのセキュリティポリシーを示すファイル |
| 主な追加内容 | サポート対象バージョン、脆弱性報告方法 | 利用者・研究者・開発者が「どこに報告すべきか」を判断しやすくなる |
| 変更規模 | 1ファイル、21行追加 | コード変更ではなく、運用・ドキュメント面の更新 |
| PR状態 | Closed | 確認時点では、そのままマージ済みの変更とは扱わない方がよい |
| 影響範囲 | GitHub Docsリポジトリのセキュリティポリシー案 | GitHub Docs利用者に直接の設定変更は発生しにくい |
注意したいのは、このPRが「GitHub Docsの画面やAPIの仕様変更」を意味するわけではない点です。GitHub上のPRページではClosedと表示されており、headリポジトリの削除によって閉じられたことも確認できます。(GitHub)
そのため、この記事では「マージ済みの新仕様」としてではなく、GitHub DocsリポジトリにおけるSECURITY.md追加提案から、リポジトリ運用者が確認すべきポイントを整理するという位置づけで解説します。
SECURITY.mdとは何か
SECURITY.mdは、GitHubリポジトリにおけるセキュリティポリシーを記載するMarkdownファイルです。GitHub Docsでは、セキュリティポリシーを追加することで、プロジェクト内の脆弱性を報告する方法を示せると説明されています。(GitHub Docs)
多くのリポジトリでは、READMEに利用方法、CONTRIBUTINGに貢献方法、LICENSEにライセンスを記載します。それと同じように、SECURITY.mdには「セキュリティ問題を見つけたときの連絡先・対象バージョン・報告後の流れ」を記載します。
SECURITY.mdに書くべき主な内容
SECURITY.mdに最低限入れておきたい内容は、次の4つです。
| 項目 | 書く内容 | 書かないと起きやすい問題 |
|---|---|---|
| サポート対象バージョン | 例：2.xは対応中、1.xは終了 | 古いバージョンの脆弱性対応を求められ、判断がぶれる |
| 報告方法 | メール、GitHub Security Advisory、専用フォームなど | Public Issueに脆弱性情報が投稿される |
| 初回返信の目安 | 例：3営業日以内に受領連絡 | 報告者が放置されたと感じ、公開開示に進む可能性がある |
| 開示方針 | 修正後にアドバイザリ公開、CVE申請方針など | 報告者・利用者・運用者の期待値がずれる |
GitHubの公式ドキュメントでも、SECURITY.mdにはプロジェクトのサポート対象バージョンと、脆弱性の報告方法を追加する手順が示されています。(GitHub Docs)
今回の更新で対応が必要な人
今回のGitHub Docs documentation updateは、すべてのGitHub利用者に作業を求めるものではありません。対応の優先度は、あなたがGitHub Docsを読むだけなのか、リポジトリを管理しているのかによって変わります。
| 対象者 | 対応優先度 | やるべきこと |
|---|---|---|
| GitHub Docsを参照する一般ユーザー | 低 | GitHub Docsの使い方に大きな変更がないか確認する程度 |
| GitHubリポジトリの管理者 | 高 | 自分のリポジトリにSECURITY.mdがあるか確認する |
| OSSメンテナー | 高 | 脆弱性報告先、サポート対象バージョン、開示方針を明文化する |
| 企業のGitHub管理者 | 高 | 組織内の標準テンプレートとしてSECURITY.mdを整備する |
| セキュリティ担当者 | 高 | 報告受付後のトリアージ、担当者、初動時間を決める |
| ドキュメント担当者 | 中 | READMEやCONTRIBUTINGとの整合性を確認する |
特に対応すべきなのは、公開リポジトリを持つチームです。GitHub Docsのベストプラクティスでは、SECURITY.mdを追加すると、プロジェクトで見つかった脆弱性を報告するための手順を共同作業者に示し、責任ある開示を促せるとされています。(GitHub Docs)
影響範囲は「機能変更」より「運用ルールの明文化」
今回の変更案から読み取れる影響は、GitHub Docsの画面操作やAPI仕様の変更ではなく、セキュリティ報告に関する運用ルールを文書化する重要性です。
SECURITY.mdがないリポジトリでは、脆弱性を見つけた人がどこに連絡すべきか分かりません。その結果、次のような問題が起きやすくなります。
- Public Issueに攻撃手法や再現手順が投稿される
- 古いバージョンの脆弱性に対応するかどうかで判断が遅れる
- 報告を受け取った人が、誰にエスカレーションすべきか分からない
- 修正前に情報が拡散し、利用者にリスクが広がる
- 報告者に返信できず、プロジェクトへの信頼が下がる
GitHub Docsの現在のセキュリティポリシーページでは、GitHub所有リポジトリに関する脆弱性について、Public Issue、Discussion、Pull Requestではなく、指定メールアドレスへ報告するよう案内されています。(GitHub)
この点は、自社・自分のリポジトリでも参考になります。脆弱性報告は、通常のバグ報告とは分けて扱うべきです。通常のIssueは透明性のために有効ですが、未修正の脆弱性情報を公開する場としては不適切です。
自分のリポジトリで確認すべき設定と移行ポイント
GitHub Docs documentation update: Create SECURITY.md for security policyをきっかけに、自分のリポジトリを確認する場合は、次の順番で見ると抜け漏れを減らせます。
まずSECURITY.mdの有無を確認する
GitHubのリポジトリで、以下のいずれかにSECURITY.mdがあるか確認します。
| 配置場所 | 向いているケース |
|---|---|
リポジトリ直下のSECURITY.md | そのリポジトリ専用のポリシーを置きたい場合 |
.github/SECURITY.md | 同じリポジトリ内でコミュニティ関連ファイルを整理したい場合 |
組織の.githubリポジトリ | 複数リポジトリで共通ポリシーを使いたい場合 |
個別リポジトリで製品やライブラリのライフサイクルが異なる場合は、共通テンプレートをそのまま使うより、リポジトリごとにサポート対象バージョンを明記する方が安全です。
GitHubの画面から追加する
GitHub Docsでは、リポジトリの「Security and quality」タブから「Security policy」を選び、SECURITY.mdにサポート対象バージョンと脆弱性報告方法を追加する手順が案内されています。(GitHub Docs)
実務では、次の流れで進めるとよいでしょう。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 既存のSECURITY.mdを探す | 直下、.github、組織共通設定を確認 |
| 2 | サポート対象バージョンを決める | 現行版、LTS、保守終了版を分ける |
| 3 | 報告窓口を決める | 個人メールではなく、チームで受けられる窓口にする |
| 4 | 初回返信の目安を決める | 実際に守れる営業日ベースで書く |
| 5 | Private vulnerability reportingの利用可否を確認する | GitHub上で非公開報告を受けたい場合に有効 |
| 6 | READMEやCONTRIBUTINGと整合させる | セキュリティ問題だけはPublic Issueに誘導しない |
| 7 | PRでレビューしてから反映する | セキュリティ担当、開発責任者、OSSメンテナーで確認 |
Private vulnerability reportingとの違いを理解する
SECURITY.mdとPrivate vulnerability reportingは似ていますが、同じものではありません。
GitHub Docsでは、Private vulnerability reportingはSECURITY.mdとは別の機能であり、有効化されている公開リポジトリでのみ、誰でも非公開で脆弱性を報告できると説明されています。(GitHub Docs)
| 項目 | SECURITY.md | Private vulnerability reporting |
|---|---|---|
| 役割 | 報告方法や方針を説明する文書 | GitHub上で非公開報告を受ける機能 |
| 対象 | 公開・非公開を問わず方針文書として使える | 主に公開リポジトリでの非公開報告に使う |
| 設定内容 | 連絡先、対象バージョン、対応方針 | GitHubのSecurity Advisory経由の報告受付 |
| 注意点 | 書いただけではGitHubの非公開報告機能は有効にならない | 有効化しても、運用方針の説明は別途必要 |
おすすめは、両方を組み合わせることです。SECURITY.mdで「報告はGitHubのReport a vulnerabilityを使ってください」と案内し、Private vulnerability reportingを有効にしておけば、報告者は迷いにくくなります。
実務向けSECURITY.mdの記載例
以下は、公開リポジトリ向けの実務的なSECURITY.md例です。プロジェクト名、連絡先、対応日数、対象バージョンは必ず自分の運用に合わせて変更してください。
# Security Policy
Thank you for helping keep this project secure.
Please do not report security vulnerabilities through public issues, discussions, or pull requests.
## Supported Versions
| Version | Supported |
| --- | --- |
| 2.x | Yes |
| 1.x | Security fixes only |
| < 1.0 | No |
## Reporting a Vulnerability
If you believe you have found a security vulnerability, please report it using one of the following methods:
- GitHub private vulnerability reporting, if available
- Email: [email protected]
Please include the following information when possible:
- Affected version, branch, or commit
- Steps to reproduce the issue
- Proof-of-concept code or screenshots, if safe to share
- Potential impact
- Any workaround you have identified
We aim to acknowledge reports within 3 business days.
After triage, we will let you know whether the report has been accepted, needs more information, or is outside the scope of this project.
## Disclosure
Please do not publicly disclose the vulnerability until we have investigated the report and, if needed, released a fix or mitigation.日本語リポジトリの場合は、日本語と英語を併記するのも有効です。OSSでは海外のセキュリティ研究者から報告を受けることもあるため、少なくとも報告先と禁止事項は英語でも書いておくと運用しやすくなります。
SECURITY.mdで失敗しやすいポイント
SECURITY.mdは、作るだけなら簡単です。しかし、実際に役立つ文書にするには、テンプレートの空欄を埋めるだけでは不十分です。
テンプレートの文言を残したまま公開する
よくある失敗は、「ここに報告方法を書いてください」「ここにサポート対象バージョンを書いてください」といったテンプレート文を残したまま公開することです。
この状態では、報告者は何も判断できません。公開前に、第三者の視点で次の質問に答えられるか確認してください。
- どのバージョンがセキュリティ修正の対象か
- 脆弱性をどこに送ればよいか
- Public Issueに投稿してよいのか、してはいけないのか
- 返信はいつ頃もらえるのか
- 報告後に何が起きるのか
サポート対象バージョンが曖昧
「最新版のみサポート」と書くだけでは、実務では困ることがあります。たとえば、2.3.1が最新版で、2.2.xを多くのユーザーが使っている場合、2.2.xの脆弱性に対応するのかどうかが不明です。
判断に迷う場合は、次のように分けると分かりやすくなります。
| バージョン | 対応方針の例 |
|---|---|
| 最新メジャー版 | 通常のセキュリティ修正を提供 |
| 1つ前のメジャー版 | 重大な脆弱性のみ期限付きで対応 |
| EOL版 | 原則として修正しない。アップグレードを案内 |
| 開発版・β版 | 本番利用を推奨せず、個別判断 |
「対応しない」と書くことは冷たい対応ではありません。むしろ、利用者がアップグレードの必要性を判断できる重要な情報です。
個人メールだけを報告先にする
小規模プロジェクトでは個人メールを使いがちですが、長期運用ではリスクがあります。担当者が退職・異動・休暇に入ると、報告が放置される可能性があるためです。
企業やチームで運用する場合は、個人ではなく次のような窓口を使う方が安全です。
- セキュリティチームの共有メールアドレス
- GitHubのPrivate vulnerability reporting
- 問い合わせ管理システムの専用フォーム
- 組織の脆弱性報告窓口
ただし、フォームだけにすると、報告者が添付ファイルやPoCを安全に送れない場合があります。メールとGitHubの非公開報告を併用するなど、報告しやすさも考慮しましょう。
返信期限を厳しく書きすぎる
「24時間以内に返信」と書いても、実際に守れないなら逆効果です。SECURITY.mdは約束に近い文書です。守れない期限を書くより、「3営業日以内に受領連絡」「重大度に応じて対応方針を連絡」のように、現実的な目安を書く方が信頼されます。
Public Issueへの誘導が残っている
READMEやCONTRIBUTINGで「バグはIssueに投稿してください」と書いている場合、セキュリティ問題もIssueに投稿される可能性があります。
対策として、READMEやIssueテンプレートに次のような文言を入れておくと安全です。
Security vulnerabilities should not be reported through public issues.
Please follow the instructions in SECURITY.md.日本語なら、次のように書けます。
セキュリティ上の脆弱性は、公開Issueに投稿しないでください。
報告方法はSECURITY.mdを確認してください。GitHub Docs利用者が確認すべきこと
GitHub Docsを参照しているだけのユーザーは、今回のPRを見て設定変更を行う必要は基本的にありません。ただし、GitHub DocsやGitHubリポジトリのセキュリティ報告に関わる場合は、次の点を確認しておくとよいでしょう。
GitHub Docs本体のセキュリティポリシーを確認する
GitHub DocsリポジトリのSecurity policyページには、GitHub所有リポジトリで脆弱性を見つけた場合の報告方法が記載されています。そこでは、Public Issue、Discussion、Pull Requestではなく、指定された連絡先に報告するよう案内されています。(GitHub)
つまり、GitHub Docsに関するセキュリティ上の問題を見つけた場合も、通常のドキュメント修正PRと同じ扱いにしないことが重要です。
PRの状態を見て「反映済み」と誤解しない
GitHubのPull Requestは、作成された時点では変更案です。今回のPR #44059もClosedであり、差分ページではSECURITY.mdの追加内容を確認できますが、それだけでGitHub Docsのmainブランチに反映されたと判断しない方が安全です。(GitHub)
ドキュメント更新を追うときは、次の順番で確認しましょう。
| 確認場所 | 見るポイント |
|---|---|
| PR Conversation | 目的、レビュー状況、Closed/Mergedの状態 |
| Files changed | 実際に何が追加・削除されたか |
| mainブランチ | 変更が現在の既定ブランチに存在するか |
| Security policyページ | GitHub上で表示される実際のポリシー |
| 公式Docsページ | 手順やUI名が現在の表示と一致しているか |
今回のように、PRの内容と現在の表示が異なる場合は、PR単体ではなく、リポジトリの現在状態も合わせて確認することが大切です。
企業・チームでの対応チェックリスト
社内でGitHubを使っている場合は、今回のGitHub Docs documentation updateをきっかけに、以下のチェックリストを回すと実務的です。
| チェック項目 | OKの状態 |
|---|---|
すべての公開リポジトリにSECURITY.mdがある | 直下、.github、組織共通のいずれかで確認できる |
| 報告先がチーム管理になっている | 個人メールだけに依存していない |
| サポート対象バージョンが明記されている | 現行版、旧版、EOL版の扱いが分かる |
| Public Issueでの報告を禁止している | 未修正脆弱性の公開を避けられる |
| 初回返信の目安が現実的 | 守れる営業日ベースで書かれている |
| Private vulnerability reportingを検討している | GitHub上で非公開報告を受ける導線がある |
| READMEやIssueテンプレートと矛盾しない | セキュリティ問題の導線が一貫している |
| 報告後の担当者が決まっている | 受領、再現確認、修正、開示までの責任者がいる |
GitHub Docsでは、Dependabot alerts、secret scanning、push protection、code scanningなど、リポジトリを保護するためのセキュリティ機能も案内されています。SECURITY.mdは報告窓口を整える文書ですが、検知や予防の設定と組み合わせて初めて効果が高まります。(GitHub Docs)
まとめ：次にやるべきこと
「GitHub Docs documentation update: Create SECURITY.md for security policy」は、GitHub Docsの使い方を大きく変えるアップデートではなく、SECURITY.mdによってセキュリティポリシーを明文化する重要性を示す更新案です。
確認時点ではPR #44059はClosedであり、GitHub Docs利用者が移行作業を行う必要は基本的にありません。一方で、GitHubでリポジトリを運用している管理者やOSSメンテナーは、自分のプロジェクトにSECURITY.mdがあるか、内容が実際の対応体制に合っているかを確認すべきです。
まずは、次の3点から始めてください。
- リポジトリに
SECURITY.mdが存在するか確認する - サポート対象バージョンと脆弱性報告先を明記する
- Public Issueではなく、非公開で報告できる導線を用意する
SECURITY.mdは、単なるMarkdownファイルではありません。脆弱性が見つかった瞬間に、報告者・利用者・メンテナー全員の行動をそろえるための運用ルールです。テンプレートを置くだけで終わらせず、実際に守れる内容として整備しておきましょう。
コメント