GitHubセキュリティアドバイザリー完全ガイド

Last updated at 2025-12-21Posted at 2025-12-21

GitHubセキュリティアドバイザリー完全ガイド

セキュリティ脆弱性の取り扱いは、オープンソースプロジェクトにおける最も重要な課題の一つです。GitHubは、脆弱性の発見から修正、そして公開までを体系的に管理できる強力な仕組みを提供しています。本記事では、GitHubのセキュリティアドバイザリー機能について、技術的な詳細を含めて解説します。

GitHub Advisory Databaseの構造
Repository Security Advisories：リポジトリレベルでの脆弱性管理
Private Vulnerability Reporting：直接報告の仕組み
アドバイザリーの検索とフィルタリング
アドバイザリーの編集とコミュニティ貢献
ベストプラクティス：バージョン指定の詳細
権限レベルと役割
協調的開示のベストプラクティス
GitHubでの2つの報告プロセス
REST APIとの統合
まとめ

1. GitHub Advisory Databaseの構造

GitHubは、既知のセキュリティ脆弱性とマルウェア情報を集約したGitHub Advisory Databaseを運営しています。このデータベースは、複数のソースから情報を収集し、Open Source Vulnerability (OSV)フォーマットのJSONファイルとして公開されています。

1.1. データソース

GitHub Advisory Databaseは以下のソースから情報を取得しています：

GitHub上で報告されたセキュリティアドバイザリー
National Vulnerability Database (NVD)
npm Security advisories database
FriendsOfPHP database
Go Vulncheck database
Python Packaging Advisory database
Ruby Advisory database
RustSec Advisory database
コミュニティからの貢献

1.2. アドバイザリーの3つのカテゴリー

データベース内のアドバイザリーは、以下の3つに分類されます：

1.2.1. GitHub-reviewed advisories（検証済みアドバイザリー）

GitHubが内容を精査し、サポート対象のエコシステムのパッケージにマッピングされた脆弱性情報です。完全な説明と、エコシステムおよびパッケージ情報の両方を含んでいます。

サポート対象エコシステム：

Composer (レジストリ: https://packagist.org/)
Erlang (レジストリ: https://hex.pm/)
Go (レジストリ: https://pkg.go.dev/)
GitHub Actions (https://github.com/marketplace?type=actions/)
Maven (レジストリ: https://repo.maven.apache.org/maven2)
npm (レジストリ: https://www.npmjs.com/)
NuGet (レジストリ: https://www.nuget.org/)
Pip (レジストリ: https://pypi.org/)
Pub (レジストリ: https://pub.dev/packages/registry)
RubyGems (レジストリ: https://rubygems.org/)
Rust (レジストリ: https://crates.io/)
Swift

このカテゴリーのアドバイザリーは、Dependabotアラートの対象となります。

2. Unreviewed advisories（未検証アドバイザリー）

National Vulnerability Databaseフィードから自動的に公開される脆弱性情報です。有効性や完全性がチェックされていないため、Dependabotアラートは生成されません。

1.2.3. Malware advisories（マルウェアアドバイザリー）

npmセキュリティチームから提供されたマルウェアに関する情報で、npmエコシステム専用です。GitHubによる編集やコミュニティからの貢献は受け付けていません。多くの場合、下流ユーザーが解決できない脆弱性のため、Dependabotアラートは生成されません。

1.3. アドバイザリーの識別子

各アドバイザリーには、GHSA IDと呼ばれる一意の識別子が割り当てられます。

フォーマット： GHSA-xxxx-xxxx-xxxx

xは、23456789cfghjmpqrvwxのセットから選ばれた文字または数字
GHSA部分以外は小文字で、ランダムに割り当てられる

正規表現での検証：

/GHSA(-[23456789cfghjmpqrvwx]{4}){3}/

1.4. CVSSによる深刻度評価

GitHub Advisory Databaseは、CVSS version 3.1とversion 4.0の両方をサポートしています。深刻度レベルは、Common Vulnerability Scoring System (CVSS)で定義された以下の4段階です：

Low（低）
Medium/Moderate（中）
High（高）
Critical（緊急）

GitHubがCVEを取得した場合、メンテナーが割り当てたCVSSバージョン（3.1または4.0）を使用します。インポートされたCVEの場合、CVSS version 4.0、3.1、3.0をサポートします。

1.5. EPSS（Exploit Prediction Scoring System）

EPSSは、Forum of Incident Response and Security Teams (FIRST)が考案した、脆弱性が悪用される可能性を定量化するシステムです。

EPSSスコアの読み方：

スコア範囲：0〜1（0〜100%）
スコアが高いほど、悪用される可能性が高い
パーセンタイルも表示される

例：あるアドバイザリーのEPSSスコアが90.534%で、95パーセンタイルの場合：

今後30日以内にこの脆弱性が悪用される確率は90.534%
モデル化された全脆弱性の95%は、この脆弱性よりも悪用される可能性が低い

GitHubは毎日EPSSデータを同期しています。スコアのパーセンテージは常に完全に同期されますが、パーセンタイルは大きな変化があった場合にのみ更新されます。

2. Repository Security Advisories：リポジトリレベルでの脆弱性管理

Repository Security Advisoriesは、パブリックリポジトリのメンテナーが脆弱性を非公開で議論し、修正し、公開するための機能です。

2.1. 主な機能

ドラフトセキュリティアドバイザリーの作成
- 脆弱性の影響を非公開で議論
一時的なプライベートフォークでの協力
- 非公開で脆弱性を修正
セキュリティアドバイザリーの公開
- パッチがリリースされたらコミュニティに通知
CVE識別番号の取得
- GitHubはCVE Numbering Authority (CNA)として、CVE IDを発行可能
- 既存のCVE IDがある場合は、それを使用することも可能

2.2. Repository Security Advisoriesの作成手順

2.2.1. 前提条件

リポジトリ所有者、組織所有者、セキュリティマネージャー、または管理者権限を持つユーザーが作成できます。

セキュリティ研究者の場合、管理していないリポジトリではメンテナーに連絡して代わりに作成してもらう必要があります。ただし、Private Vulnerability Reportingが有効な場合は、直接報告できます。

2.2.2. 作成ステップ

2.3. クレジットタイプ

脆弱性の発見や修正に貢献した人にクレジットを付与できます。クレジットを受けた人は、受諾するか辞退するかを選択できます。

クレジットタイプ	理由
Finder	脆弱性を発見した
Reporter	CNAに脆弱性を通知した
Analyst	脆弱性の正確性または深刻度を検証した
Coordinator	協調的な対応プロセスを促進した
Remediation developer	コード変更または修正計画を準備した
Remediation reviewer	脆弱性修正計画またはコード変更の有効性と完全性をレビューした
Remediation verifier	脆弱性またはその修正をテストして検証した
Tool	脆弱性の発見または識別に使用したツールの名前
Sponsor	脆弱性の識別または修正活動を支援した

クレジットを受諾した人のユーザー名は、セキュリティアドバイザリーが公開されると公開されます。

2.4. 一時的なプライベートフォークでの協力

セキュリティ情報を安全に保つため、一時的なプライベートフォークにはCI を含むインテグレーションはアクセスできません。

2.4.1. 命名規則

一時的なプライベートフォークの名前は、GitHub Advisory Databaseのアドバイザリーと同様の規則に従います：

フォーマット： リポジトリ名-ghsa-xxxx-xxxx-xxxx

リポジトリ名：元のリポジトリの名前（100文字制限のため、80文字に切り詰められる）
ghsa-xxxx-xxxx-xxxx：ドラフトセキュリティアドバイザリーの一意の識別子

例： octocat-repoというリポジトリで、アドバイザリーIDがGHSA-x854-cvjg-vx26の場合：

octocat-repo-ghsa-x854-cvjg-vx26

2.4.2. 作業フロー

重要な注意点：

一時的なプライベートフォークでは、個別のプルリクエストをマージできません
代わりに、対応するセキュリティアドバイザリーで全ての開いているプルリクエストを一度にマージします
ステータスチェックは実行されないため、PRがマージ可能かどうかを手動で確認する必要があります
mainブランチに対するPRが複数ある場合、マージがブロックされます

2.5. セキュリティアドバイザリーの公開

アドバイザリーを公開すると、一時的なプライベートフォークは削除されます。

2.5.1. 公開前の確認事項

可能な限り、アドバイザリーを公開する前に修正バージョンを追加することを推奨します。修正バージョンなしで公開すると、Dependabotはユーザーに問題を警告しますが、更新先の安全なバージョンを提供できません。

状況別の推奨事項：

修正バージョンがすぐに利用可能な場合
- 修正が準備できるまで待って開示する
修正バージョンが開発中だが未リリースの場合
- アドバイザリーでその旨を記載し、公開後に編集する
修正する予定がない場合
- アドバイザリーで明確に記載し、ユーザーが取れる緩和策の手順を含める

2.5.2. CVE識別番号のリクエスト（オプション）

GitHubからCVE IDをリクエストする場合、通常72時間以内にレビューされます。リクエストしてもアドバイザリーは公開されません。

条件：

プロジェクトの脆弱性に対するCVE IDが必要で、まだ持っていない場合
他のCNAの対象となるプロジェクトの場合、GitHubはCVEを割り当てられません

既存のCVEがある場合は、セキュリティアドバイザリーフォームにCVEを追加できます。

2.5.3. 公開後の影響

公開されたリポジトリからのアドバイザリーは、誰でも閲覧可能になります：

アドバイザリーデータの現在のバージョン
クレジットされたユーザーが受諾したアドバイザリークレジット

編集履歴は一般公開されず、公開されたバージョンのみが表示されます。

2.5.4. Dependabotアラート

GitHubは公開された各アドバイザリーをレビューし、GitHub Advisory Databaseに追加します。影響を受けるリポジトリにDependabotアラートを送信するために使用される場合があります。

処理時間： 最大72時間

フォークからのアドバイザリー： フォークが公開パッケージレジストリに一意の名前でパッケージを所有している場合のみ、アラートが送信されます。

3. Private Vulnerability Reporting：直接報告の仕組み

Private Vulnerability Reportingは、セキュリティ研究者がメンテナーに直接かつ非公開で脆弱性を報告できる機能です。

3.1. 有効化方法

3.1.1. リポジトリレベル

3.1.2. 組織レベル

組織所有者とセキュリティマネージャーは、組織内の全パブリックリポジトリに対してPrivate Vulnerability Reportingを有効化できます。

方法：

GitHub推奨のセキュリティ設定を使用
カスタムセキュリティ設定を作成

3.2. 通知の設定

新しい脆弱性が非公開で報告されると、GitHubはリポジトリメンテナーとセキュリティマネージャーに通知します。

通知条件：

リポジトリの全アクティビティを監視している
リポジトリの通知が有効になっている

メール通知を受け取るための設定：

リポジトリを監視（Watch）する
通知設定で「All Activity」を選択
通知設定で「Email」を選択

3.3. セキュリティ研究者からの報告フロー

フォームの推奨事項：

タイトルと説明のみが必須ですが、できるだけ多くの情報を提供することを推奨します：

エコシステム
パッケージ名
影響を受けるバージョン
パッチされたバージョン
脆弱な関数
CVSS スコア
CWE番号

これにより、メンテナーが報告について十分な情報に基づいた判断を下せます。

3.4. メンテナーの対応フロー

重要な考慮事項：

ステータスが「Triage」のアドバイザリーは非公開です
報告を受諾しても、まだ公開されません
ドラフトリポジトリセキュリティアドバイザリーとして作業できます
セキュリティリスクではないと判断した場合、理由を説明してクローズすべきです

4. アドバイザリーの検索とフィルタリング

GitHub Advisory Databaseは、強力な検索機能を提供しています。

4.1. 検索修飾子

修飾子	例	説明
`type:reviewed`	`type:reviewed`	GitHub検証済みのセキュリティ脆弱性アドバイザリーを表示
`type:malware`	`type:malware`	マルウェアアドバイザリーを表示
`type:unreviewed`	`type:unreviewed`	未検証のアドバイザリーを表示
`GHSA-ID`	`GHSA-49wp-qq6x-g2rf`	このGHSA IDのアドバイザリーを表示
`CVE-ID`	`CVE-2020-28482`	このCVE ID番号のアドバイザリーを表示
`ecosystem:ECOSYSTEM`	`ecosystem:npm`	npmパッケージに影響するアドバイザリーのみを表示
`severity:LEVEL`	`severity:high`	高い深刻度レベルのアドバイザリーのみを表示
`affects:LIBRARY`	`affects:lodash`	lodashライブラリに影響するアドバイザリーのみを表示
`cwe:ID`	`cwe:352`	このCWE番号のアドバイザリーのみを表示
`credit:USERNAME`	`credit:tanaka_taro`	"tanaka_taro"ユーザーアカウントにクレジットされたアドバイザリーのみを表示
`sort:created-asc`	`sort:created-asc`	最も古いアドバイザリーから並べ替え
`sort:created-desc`	`sort:created-desc`	最も新しいアドバイザリーから並べ替え
`sort:updated-asc`	`sort:updated-asc`	最も古い更新から並べ替え
`sort:updated-desc`	`sort:updated-desc`	最も新しい更新から並べ替え
`is:withdrawn`	`is:withdrawn`	撤回されたアドバイザリーのみを表示
`created:YYYY-MM-DD`	`created:2021-01-13`	この日付に作成されたアドバイザリーのみを表示
`updated:YYYY-MM-DD`	`updated:2021-01-13`	この日付に更新されたアドバイザリーのみを表示

4.2. 日付フォーマット

日付はISO8601標準に従う必要があります：YYYY-MM-DD（年-月-日）

オプションで時刻情報を追加できます：THH:MM:SS+00:00

範囲検索：

日付を検索する際、より大きい、より小さい、範囲修飾子を使用してさらに結果をフィルタリングできます。

4.3. 脆弱なリポジトリの表示

GitHub検証済みのアドバイザリーについて、セキュリティ脆弱性またはマルウェアの影響を受けるリポジトリを確認できます。

手順：

github.com/advisories にアクセス
アドバイザリーをクリック
アドバイザリーページ上部の「Dependabot alerts」をクリック
オプション：検索バーまたはドロップダウンメニューでリストをフィルタリング
リポジトリ名をクリックして詳細を確認

注意： 脆弱なリポジトリを表示するには、そのリポジトリのDependabotアラートへのアクセス権が必要です。

5. アドバイザリーの編集とコミュニティ貢献

5.1. リポジトリアドバイザリーの編集

リポジトリ所有者のみが編集できます。

編集手順：

5.2. グローバルアドバイザリーへの貢献

GitHub Advisory Databaseのグローバルセキュリティアドバイザリーは、誰でも改善を提案できます。

貢献できる内容：

追加の影響を受けるエコシステム
深刻度レベル
影響を受ける人の説明
その他の詳細

貢献手順：

クレジット：

コミュニティ貢献が承認され公開されると、プルリクエストを提出した人には自動的に「Analyst」クレジットタイプが割り当てられます。

直接プルリクエストも可能：

github/advisory-databaseリポジトリのアドバイザリーファイルに直接プルリクエストを開くこともできます。

ベストプラクティス：バージョン指定の詳細

セキュリティアドバイザリーを書く際、特にバージョン指定は重要です。GitHub Advisory Databaseの構文に従うことで、以下のメリットがあります：

GitHubが「GitHub-reviewed」アドバイザリーとして追加できる
Dependabotがリポジトリを正確に識別してアラートを送信できる
コミュニティメンバーが修正の編集を提案する可能性が低くなる

バージョン構文の基本

数値の比較：

小さい数値は大きい数値よりも前のバージョン
例：1.0.0 < 2.0.0

アルファベットの比較：

アルファベット順で前の文字は後の文字よりも前のバージョン
例：2.0.0-a < 2.0.0-b

プレリリースの扱い：

数字の後に文字が来る場合、それはプレリリースとみなされる
プレリリースは、文字がないバージョンよりも前のバージョン
例：2.0.0-alpha < 2.0.0-beta < 2.0.0-rc < 2.0.0

修正バージョンの制約：

修正バージョンは、脆弱なバージョン範囲（VVR）の最大値より小さくできない
例：脆弱なバージョンがリリースされ、メンテナーがダウングレードを推奨する場合、そのより低いバージョンを修正またはパッチされたバージョンとしてFixedフィールドにラベル付けできない

6.2. サポートされている演算子

演算子	意味	推奨
`>=`	このバージョン以上	✓
`>`	このバージョンより大きい	△（OSVフォーマット非対応のため非推奨）
`=`	このバージョンと等しい	✓
`<=`	このバージョン以下	✓
`<`	このバージョン未満	✓

6.3. 影響を受けるバージョンの指定方法

有効な影響を受けるバージョン文字列は、以下のいずれかで構成されます：

下限演算子シーケンス
上限演算子シーケンス
上限と下限の両方の演算子シーケンス（下限が最初、カンマとスペース1つ、その後上限）
等号演算子を使用した特定のバージョンシーケンス

演算子シーケンスの形式：

演算子 スペース バージョン

バージョンの形式：

数字で始まる
その後、任意の数の数字、文字、ドット、ダッシュ、アンダースコアが続く（スペースとカンマ以外）

注意事項：

文字列の先頭または末尾にスペースを含めることはできません
上限演算子は包含的（<=）または排他的（<）にできます
下限演算子は包含的（>=）または排他的（>）にできます
ただし、リポジトリアドバイザリーをグローバルアドバイザリーに昇格させる場合、下限文字列は包含的（>=）のみ可能です
排他的下限演算子（>）は、バージョンが0の場合のみ許可されます（例：> 0）

6.4. スペースの適切な使用

正しい使用法：

演算子とバージョン番号の間にスペースを使用する
カンマと上限演算子の間にスペースを使用する

間違った使用法：

>=や<=内にスペースを使用しない
>= 下限, <= 上限の数字とカンマの間にスペースを使用しない

6.5. 設定例

6.5.1. 上限のみ設定

上限のみを設定する場合：

<=または<を使用
>= 0を含める必要はない（暗黙的に> 0が下限）

例：

< 3.3.23
<= 14.10.21

6.5.2. 下限のみ設定

推奨しない： マルウェア以外のアドバイザリーで下限のみを設定することは推奨されません。修正バージョンがリリースされた場合、アドバイザリーが手動で更新されるまで、修正バージョンのユーザーが不要なDependabotアラートを受け取り続けます。

使用する場合：

>= 0を使用（全バージョン）
> 0は一般的に使用されない

6.5.3. 単一の影響を受けるバージョン

= 2.0.0

等号（=）は、指定されたバージョンのみに適用され、パブリックまたはプライベートプレビューは自動的に含まれません。

6.5.4. 複数の範囲と演算子

例：XWiki Platformの脆弱性（GHSA-wcg9-pgqv-xm5v）

このアドバイザリーには4つの脆弱なバージョン範囲があります：

>= 1.1.2, < 14.10.21
>= 15.0-rc-1, < 15.5.5
>= 15.6-rc-1, < 15.10.6
= 16.0.0-rc-1

解説：

最初の3つの範囲は、プレリリースを含む
最後の範囲（= 16.0.0-rc-1）は、16.0.0-rc-1のみが脆弱で、その後の通常リリース16.0.0は脆弱ではないことを示す
ロジックは16.0.0-rc-1と16.0.0を別のバージョンとみなし、16.0.0-rc-1を前のリリースとして扱う

パッチの情報：

2024年1月24日にバージョン16.0.0用のパッチが公開
16.0.0-rc-1は2024年1月22日に公開（修正前）
16.0.0は2024年1月29日に公開（修正後）

6.5.5. ブランチ名を含むバージョン番号

例：Google Guavaの脆弱性

Guavaにはandroidとjreの2つのブランチがあります。

間違った設定：

パッチバージョンを32.0.0に設定すると、32.0.0-androidと32.0.0-jreの両方が誤って脆弱としてマークされる（バージョンロジックが32.0.0の後の文字をプレリリースと解釈するため）
パッチバージョンを32.0.0-jreに設定すると、32.0.0-androidが誤って脆弱としてマークされる（アルファベット順でandroidがjreより前のため）

正しい設定：

パッチバージョン: 32.0.0-android

ロジックは32.0.0-android以降のアルファベット順の全てをパッチ済みと解釈するため、両方のブランチが正しくパッチ済みとマークされます。

6.6. よくある間違い

6.6.1. 不適切な上限設定

間違い：

脆弱なバージョン範囲: < n
パッチバージョン: n+1

正しい：

< nはnが脆弱でない場合のみ使用すべき
この場合、VVRは<= nまたは< n+1であるべき

6.6.2. 公式バージョン番号で数字のみを使用

ソフトウェアにlinuxとwindowsの2つのブランチがある場合：

2.0.0-linuxと2.0.0-windowsをリリース
脆弱なバージョンとして< 2.0.0を使用すると、両方が脆弱としてマークされる
バージョンロジックが-linuxと-windowsをプレリリースと解釈するため

解決策：

アルファベット順で最も早いブランチ2.0.0-linuxを最初のパッチバージョンとしてマークする

7. 権限レベルと役割

7.1. Repository Security Advisoriesの権限

アクション	書き込み権限	管理者権限
ドラフトセキュリティアドバイザリーを表示	✓	✓
セキュリティアドバイザリーに協力者を追加		✓
セキュリティアドバイザリー内の全てのコメントを編集・削除	✓	✓
一時的なプライベートフォークを作成	✓	✓
一時的なプライベートフォークに変更を追加	✓	✓
一時的なプライベートフォークでプルリクエストを作成	✓	✓
セキュリティアドバイザリーで変更をマージ		✓
セキュリティアドバイザリーでメタデータを追加・編集		✓
セキュリティアドバイザリーのクレジットを追加・削除		✓
ドラフトセキュリティアドバイザリーをクローズ		✓
セキュリティアドバイザリーを公開		✓

重要な違い：

リポジトリアドバイザリー：リポジトリ所有者、組織所有者、セキュリティマネージャー、管理者権限を持つユーザーが編集可能
グローバルアドバイザリー：誰でもGitHub Advisory Databaseに貢献可能（編集はリポジトリ上のアドバイザリーには影響しない）

8. 協調的開示のベストプラクティス

8.1. 脆弱性報告者向け

脆弱性を非公開でメンテナーに報告することが良い慣行です。

避けるべき行動：

メンテナーに修正の機会を与えずに脆弱性を公開する
メンテナーをバイパスする
コードの修正バージョンが利用可能になる前に脆弱性を開示する
公開バウンティプログラムが存在しない場合、問題の報告に対する報酬を期待する

開示ポリシー：

脆弱性報告者は、報告プロセスの一部として開示ポリシーの条件を明確に示すべき
厳格なポリシーに従わない場合でも、意図する脆弱性開示のタイムラインについてメンテナーに明確な期待を設定することが推奨される

公開開示のタイミング：

一定期間後、以下の場合に脆弱性を公開することは許容される：

メンテナーに連絡しようとしたが応答がなかった
メンテナーに連絡し、開示を待つように求められたが、待ち時間が長すぎる

8.2. メンテナー向け

明確な連絡方法の提供：

脆弱性の報告方法と場所を明確に示す
この情報が明確に利用できない場合、脆弱性報告者は適切なセキュリティ連絡先を見つけられず、gitコミット履歴から開発者のメールアドレスを抽出しようとする可能性がある

タイムリーな開示：

脆弱性をタイムリーに開示することが推奨されます。リポジトリにセキュリティ脆弱性がある場合：

セキュリティ問題として扱う
- 単純なバグではなく、セキュリティ脆弱性として対応する
- リリースノートで明示的に言及する
迅速な受信確認
- すぐに調査のためのリソースがない場合でも、脆弱性レポートの受領を可能な限り早く確認する
- 迅速に対応し行動するメッセージを送る
脆弱性報告者を関与させる
- レポートの影響と真実性を検証する際、脆弱性報告者を関与させる
- 脆弱性報告者は、様々なシナリオで脆弱性を考慮する時間を既に費やしている
適切な修正方法で対処
- 脆弱性報告者が提供する懸念とアドバイスを慎重に考慮する
- 脆弱性報告者は、セキュリティ研究の背景がなければ見落としやすい特定のコーナーケースや修正バイパスの知識を持っている
発見をクレジット
- 脆弱性をクレジットする際、必ず脆弱性報告者を認める
できるだけ早く修正を公開
エコシステム全体に認識させる
- 脆弱性を開示する際、より広いエコシステムに問題とその修正を認識させる
- 認識されたセキュリティ問題がプロジェクトの現在の開発ブランチで修正されても、コミットまたはその後のリリースが明示的にセキュリティ修正またはリリースとしてマークされていないケースは珍しくない
- これは下流の消費者に問題を引き起こす可能性がある

セキュリティ脆弱性の詳細を公開しても、メンテナーの評判が悪くなることはありません。 セキュリティ脆弱性はソフトウェアのあらゆる場所に存在し、ユーザーはコード内のセキュリティ脆弱性を開示する明確で確立されたプロセスを持つメンテナーを信頼します。

9. GitHubでの2つの報告プロセス

9.1. 標準プロセス

注意点：

npmの場合：マルウェアの報告を受けた場合、GitHubは非公開で連絡を試みます。タイムリーに問題に対処しない場合、開示されます
GitHub自体の脆弱性の場合：GitHub Security Bug Bountyプログラムを通じて報告してください

9.2. Private Vulnerability Reportingプロセス

利点：

研究者とメンテナーの両方にとって効率的
GitHub内で完結する非公開プロセス
メンテナーへの即座の通知
より良いコミュニケーションフロー

10. REST APIとの統合

GitHubは、セキュリティアドバイザリーを管理するためのREST APIエンドポイントを提供しています。

10.1. 利用可能な操作

リポジトリセキュリティアドバイザリー：

アドバイザリーの作成
アドバイザリーのリスト取得
アドバイザリーの更新
一時的なプライベートフォークの作成

グローバルセキュリティアドバイザリー：

アドバイザリーの検索
アドバイザリーの詳細取得

Private Vulnerability Reporting：

非公開で脆弱性を報告

10.2. GraphQL APIの利用

GitHub Advisory DatabaseはGraphQL APIを使用してもアクセス可能です。デフォルトでは、クエリはtype:malwareを指定しない限り、セキュリティ脆弱性のGitHub検証済みアドバイザリーを返します。

GraphQL クエリ例：

query {
  securityVulnerabilities(first: 10, ecosystem: NPM) {
    nodes {
      advisory {
        ghsaId
        summary
        severity
      }
      package {
        name
      }
      vulnerableVersionRange
    }
  }
}

REST API エンドポイント例：

# グローバルアドバイザリーの取得
curl -H "Accept: application/vnd.github+json" \
  https://api.github.com/advisories

# 特定のアドバイザリーの取得
curl -H "Accept: application/vnd.github+json" \
  https://api.github.com/advisories/GHSA-xxxx-xxxx-xxxx

# リポジトリアドバイザリーの作成
curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/security-advisories \
  -d '{"summary":"脆弱性の概要","description":"詳細な説明","severity":"high"}'

11. まとめ

GitHubのセキュリティアドバイザリー機能は、脆弱性の発見から修正、公開までの全プロセスを体系的に管理できる包括的なシステムです。

主要な特徴：

GitHub Advisory Database：複数のソースから集約された脆弱性情報
Repository Security Advisories：非公開での協力と修正
Private Vulnerability Reporting：研究者からの直接報告
CVE統合：CVE IDの発行と管理
Dependabot統合：自動的な脆弱性アラート
コミュニティ貢献：誰でもアドバイザリーの改善に貢献可能

技術者として押さえるべきポイント：

バージョン指定の正確な構文理解
OSVフォーマットとの互換性
一時的なプライベートフォークでのCI制約
権限レベルと役割の理解
協調的開示のベストプラクティス

これらの機能を適切に活用することで、セキュリティ脆弱性を効率的かつ責任を持って管理し、より安全なオープンソースエコシステムの構築に貢献できます。セキュリティは継続的なプロセスであり、GitHubのこれらのツールは、そのプロセスをサポートするための強固な基盤を提供しています。

付録A：実践的なワークフロー例

A.1. メンテナーの日常的なセキュリティ管理

ステップ1：通知設定の確認

# .github/CODEOWNERS ファイルの例
# セキュリティチームに自動的に割り当て
/.github/SECURITY.md @your-org/security-team
/security/ @your-org/security-team

ステップ2：セキュリティポリシーの設定

# SECURITY.md の例

## セキュリティ脆弱性の報告

本プロジェクトのセキュリティ脆弱性を発見された場合は、
以下の方法でご報告ください：

### Private Vulnerability Reporting（推奨）
1. リポジトリの Security タブにアクセス
2. "Report a vulnerability" をクリック
3. フォームに詳細を記入して送信

### 対応時間
- 初回応答：24時間以内
- トリアージ：72時間以内
- 修正リリース：深刻度に応じて1-4週間

ステップ3：Dependabot設定

# .github/dependabot.yml の例
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # セキュリティアップデートのみを自動マージ
    open-pull-requests-limit: 10

A.2. 脆弱性報告を受けた場合の対応フロー

A.3. バージョン指定の実践例

ケース1：単純な範囲指定

脆弱性：2.0.0から2.5.9まで
パッチ：2.6.0

指定方法：
- Affected versions: >= 2.0.0, < 2.6.0
- Patched versions: 2.6.0

ケース2：複数ブランチの指定

脆弱性：1.x系の全バージョンと2.0.0-2.3.5
パッチ：1.9.8と2.3.6

指定方法：
製品1:
- Affected versions: >= 1.0.0, < 1.9.8
- Patched versions: 1.9.8

製品2（同じアドバイザリー内）:
- Affected versions: >= 2.0.0, < 2.3.6
- Patched versions: 2.3.6

ケース3：プレリリースを含む指定

脆弱性：3.0.0-rc.1から3.0.0-rc.5まで
パッチ：3.0.0

指定方法：
- Affected versions: >= 3.0.0-rc.1, <= 3.0.0-rc.5
- Patched versions: 3.0.0

付録B：よくある質問（FAQ）

B.1. アドバイザリー作成について

Q: ドラフトアドバイザリーは誰が見られますか？

A: 以下の人のみが閲覧可能です：

リポジトリの管理者権限を持つユーザー
セキュリティマネージャー
明示的に追加された協力者

Q: 一時的なプライベートフォークはいつ削除されますか？

A: アドバイザリーを公開した時点で自動的に削除されます。

Q: CVE IDのリクエストが却下されることはありますか？

A: はい。以下の場合は却下される可能性があります：

プロジェクトが他のCNAの対象範囲である
報告内容がセキュリティ脆弱性に該当しない
必要な情報が不足している

B.2. Private Vulnerability Reportingについて

Q: 報告者は匿名で報告できますか？

A: いいえ。GitHubアカウントが必要で、メンテナーには報告者のユーザー名が表示されます。

Q: 報告後、進捗を確認できますか？

A: はい。アドバイザリーの協力者として追加されるため、コメントや進捗を確認できます。

Q: 報告が却下された場合、理由は通知されますか？

A: メンテナーが理由をコメントで説明することが推奨されていますが、必須ではありません。

B.3. バージョン指定について

Q: セマンティックバージョニングに従っていないプロジェクトの場合は？

A: 可能な限りプロジェクトのバージョニング方式に従ってください。不明な場合は、アドバイザリーの説明欄に詳細を記載してください。

Q: 「全バージョン」を指定したい場合は？

A: >= 0 を使用します。上限を指定しない場合、暗黙的に無限大が指定されます。

Q: バージョン範囲に矛盾がある場合は？

A: GitHubのバリデーションがエラーを表示します。修正バージョンは必ず脆弱なバージョン範囲の外側に設定してください。

付録C：チェックリスト

C.1. メンテナー向けセキュリティ準備チェックリスト

SECURITY.mdファイルを作成し、連絡方法を明記
Private Vulnerability Reportingを有効化
Dependabotアラートを有効化
セキュリティチームの連絡先を設定
通知設定を確認（メール、Slack等）
セキュリティインシデント対応手順を文書化
定期的なセキュリティレビュープロセスを確立

C.2. アドバイザリー作成チェックリスト

タイトルは明確で具体的か
説明に影響範囲、回避策、参照情報が含まれているか
エコシステムとパッケージ名が正確か
バージョン範囲が正しく指定されているか
深刻度が適切に評価されているか
CWE番号が指定されているか
貢献者へのクレジットが追加されているか
CVE IDが取得済みか（必要な場合）

C.3. アドバイザリー公開前チェックリスト

修正パッチがテスト済みか
修正バージョンがリリース済みか
ドキュメントが更新されているか
リリースノートにセキュリティ修正が明記されているか
一時的なプライベートフォークの変更がマージ済みか
影響を受けるユーザーへの通知準備ができているか

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitHubセキュリティアドバイザリー完全ガイド

GitHubセキュリティアドバイザリー完全ガイド

目次

1. GitHub Advisory Databaseの構造

1.1. データソース

1.2. アドバイザリーの3つのカテゴリー

1.2.1. GitHub-reviewed advisories（検証済みアドバイザリー）

2. Unreviewed advisories（未検証アドバイザリー）

1.2.3. Malware advisories（マルウェアアドバイザリー）

1.3. アドバイザリーの識別子

1.4. CVSSによる深刻度評価

1.5. EPSS（Exploit Prediction Scoring System）

2. Repository Security Advisories：リポジトリレベルでの脆弱性管理

2.1. 主な機能

2.2. Repository Security Advisoriesの作成手順

2.2.1. 前提条件

2.2.2. 作成ステップ

2.3. クレジットタイプ

2.4. 一時的なプライベートフォークでの協力

2.4.1. 命名規則

2.4.2. 作業フロー

2.5. セキュリティアドバイザリーの公開

2.5.1. 公開前の確認事項

2.5.2. CVE識別番号のリクエスト（オプション）

2.5.3. 公開後の影響

2.5.4. Dependabotアラート

3. Private Vulnerability Reporting：直接報告の仕組み

3.1. 有効化方法

3.1.1. リポジトリレベル

3.1.2. 組織レベル

3.2. 通知の設定

3.3. セキュリティ研究者からの報告フロー

3.4. メンテナーの対応フロー

4. アドバイザリーの検索とフィルタリング

4.1. 検索修飾子

4.2. 日付フォーマット

4.3. 脆弱なリポジトリの表示

5. アドバイザリーの編集とコミュニティ貢献

5.1. リポジトリアドバイザリーの編集

5.2. グローバルアドバイザリーへの貢献

ベストプラクティス：バージョン指定の詳細

バージョン構文の基本

6.2. サポートされている演算子

6.3. 影響を受けるバージョンの指定方法

6.4. スペースの適切な使用

6.5. 設定例

6.5.1. 上限のみ設定

6.5.2. 下限のみ設定

6.5.3. 単一の影響を受けるバージョン

6.5.4. 複数の範囲と演算子

6.5.5. ブランチ名を含むバージョン番号

6.6. よくある間違い

6.6.1. 不適切な上限設定

6.6.2. 公式バージョン番号で数字のみを使用

7. 権限レベルと役割

7.1. Repository Security Advisoriesの権限

8. 協調的開示のベストプラクティス

8.1. 脆弱性報告者向け

8.2. メンテナー向け

9. GitHubでの2つの報告プロセス

9.1. 標準プロセス

9.2. Private Vulnerability Reportingプロセス

10. REST APIとの統合

10.1. 利用可能な操作

10.2. GraphQL APIの利用

11. まとめ

付録A：実践的なワークフロー例

A.1. メンテナーの日常的なセキュリティ管理

A.2. 脆弱性報告を受けた場合の対応フロー

A.3. バージョン指定の実践例

付録B：よくある質問（FAQ）

B.1. アドバイザリー作成について

B.2. Private Vulnerability Reportingについて

B.3. バージョン指定について

付録C：チェックリスト

C.1. メンテナー向けセキュリティ準備チェックリスト

C.2. アドバイザリー作成チェックリスト

C.3. アドバイザリー公開前チェックリスト