クリアコードではFluentdおよびFluent Packageのメンテナンスを継続的に行っています。2026年6月にリリースしたFluentd v1.19.3と、9月にリリースしたFluentd v1.19.4では、複数の脆弱性に対応しました。
脆弱性対応では、コードの修正に加えて、報告者とのやり取り、非公開でのレビュー、CVE番号の申請、修正版のリリース、アドバイザリーの公開といった作業が必要になります。普段OSSをメンテナンスしていても、これらの操作に触れる機会は多くないかもしれません。
2021年にもGitHubセキュリティアドバイザリーを公開したときの記事を書きました。今回は実際のスクリーンショットを使って、GitHub Security Advisoriesで報告を受け付けてから公開するまでの手順と、CVEの採番などで経験した待ち時間を共有します。
脆弱性対応の流れ
ここでは、GitHubの公開リポジトリでPrivate Vulnerability Reportingを有効にして、外部から非公開の報告を受け付ける場合を扱います。
- 報告内容を確認し、受理してドラフトのアドバイザリーにする
- 一時的なプライベートフォークで修正とレビューを進める
- 公開文面を整え、CVE申請とIPAへの届出・JVNの公開日の調整を進める
- 修正を公開リポジトリへマージし、修正版をリリースする
- アドバイザリーを公開する
CVE番号の申請とIPAへの届出は、アドバイザリーの準備と並行して進めました。IPAへの届出後には、こちらのリリース予定日を伝え、JVNでの公開日を調整しています。GitHubでの公開後は、CVEやNVDへの反映も確認します。
以下の画面は2026年7月から9月に撮影したものです。複数の脆弱性への対応から、それぞれの操作が分かる画面を選んでいます。画面内のタイトルなどは作業途中の情報を含むため、個々の脆弱性の最新情報は公開済みのアドバイザリーを参照してください。
1. 報告を確認し、ドラフトとして受理する
非公開で脆弱性が報告されると、リポジトリの「Security and quality」タブにある「Advisories」から確認できます。受付時の状態は Triage です。内容を確認して「Accept and open as draft」を選ぶと、非公開のまま Draft になります。詳しい操作はGitHubの非公開報告の管理手順にも記載されています。
報告には、概要や再現手順（PoC）、影響、報告者が評価した深刻度やCVSSスコア、弱点の種類を表すCWE番号などが含まれます。まずはPoCで問題を再現できるか、脆弱性として成立するか、影響度の評価が妥当かを確認します。
次の画像は、in_http に関する報告を受理した後の画面です。履歴には報告を受理したことが記録され、上部の状態が Draft になっています。
この例では、Package、Affected versions、Patched versions がまだ空欄です。下部の Required advisory information には、影響を受けるバージョンの入力が必要と表示されています。修正バージョンは Suggested advisory information に表示されており、必須項目とは区別されています。
2. 一時的なプライベートフォークで修正する
通常の公開IssueやPull Requestで修正を進めると、修正版のリリース前に脆弱性や攻撃手法が知られてしまいます。GitHub Security Advisoriesでは、関係者だけがアクセスできる一時的なプライベートフォークを使って修正を進められます。
アドバイザリーの「Collaborate on a patch in private」にある「Start a temporary private fork」を押します。すると、fluent/fluentd-ghsa-xxxx-xxxx-xxxx のような名前の非公開リポジトリが作成されます。
「Clone and create a new branch」の指示に従い手元にクローンし、ブランチを作成して作業します。
Pull Requestとレビュー
フォークに修正ブランチをpushしたら、アドバイザリーの「Compare & pull request」から非公開のPull Requestを作成します。通常のPRと同様に、関係者へレビューを依頼できます。
通常のPRと異なり、一時的なプライベートフォークではGitHub ActionsなどのCIが動きません。情報を非公開に保つため、CIを含む外部連携がアクセスできない仕組みです。テストはローカル環境で実行して確認します。
また、ApproveされてもPR画面から直接マージすることはできません。マージ操作はアドバイザリー画面から行います。ここでマージを実行すると、そのアドバイザリーに紐づくオープン状態のPRがまとめてマージされます。
一括マージするには、開いているすべてのPRがマージ可能な状態で、コンフリクトがないことが前提です。GitHubの公式ドキュメントには、一時的なプライベートフォークの main ブランチを対象とするPRが複数あると、マージがブロックされる制約も記載されています。
3. アドバイザリーの準備と公開日の調整
修正の見通しが立ったら、「Edit advisory」から公開用の情報を整えます。報告者の再現手順だけでなく、利用者が自分の環境への影響と必要な対応を判断できる説明にすることが大切です。
| 項目 | 記入する内容 |
|---|---|
| Package | エコシステムとパッケージ名。Fluentdでは RubyGems と fluentd |
| Affected versions | 影響を受けるバージョンの範囲 |
| Patched versions | 修正を含むバージョン |
| Description | 概要、影響を受ける条件、修正内容、利用者が行う設定変更、更新できない場合の緩和策など |
GitHubの公開範囲の説明によると、一般に公開されるのは現在のアドバイザリーの内容と、本人が掲載を承諾したクレジットです。ドラフト段階の変更履歴や報告者とのやり取りまで一般公開されるわけではなく、協力者向けの情報として残ります。
そのため、最初の報告に攻撃用のPoCが含まれていても、公開前に本文から取り除き、影響範囲や対処方法など、利用者に伝える情報を整理して公開できます。編集前のPoCや非公開の議論が、アドバイザリーの公開とともに一般の閲覧者に見えるようになるわけではありません。
必須情報がそろうと、下部が Required advisory information has been provided に変わります。修正バージョンも記入しておくと、利用者に更新先を示せます。
Request CVEで事前に採番を依頼する
リリースのお知らせにCVE番号を載せたい場合は、ドラフトの段階で「Request CVE」を押してGitHubへ採番を依頼します。この操作だけではアドバイザリーは公開されません。
GitHubはCVE番号を割り当てるCNA（CVE Numbering Authority）の一つです。GitHubの説明では、申請を通常72時間以内にレビューし、対象となる脆弱性に番号を予約した後、アドバイザリーの公開に合わせてCVEの詳細を公開するとされています。番号の採番と、CVEの詳細情報の公開は別の段階です。
ただし、昨今はOSS全体で脆弱性の報告やCVE申請が増加している影響もあってか、実際の待ち時間はこの目安どおりにはなりませんでした。
| 対応したリリース | CVE番号の申請後の状況 |
|---|---|
| Fluentd v1.19.3（2026年6月） | 申請から約1週間で採番された |
| Fluentd v1.19.4（2026年9月） | リリースの約1ヶ月前に申請したが当日にも採番されず、リリースから1ヶ月経過した2026年10月30日時点でも採番待ち |
なお、アドバイザリー画面の下部には「最大3営業日（up to 3 working days）」という記載がありますが、これは公開後のアドバイザリーをGitHubがレビューしてDependabotアラートなどに反映するまでの目安であり、CVE採番の所要時間ではありません。
v1.19.4では、CVE番号を待たずに修正版とアドバイザリーを公開しました。CVEの採番が間に合わない場合でも、GHSA番号とURLで脆弱性を案内できます。CVE番号が付いた段階でリリース記事にも追記する予定です。
IPAへの届出とJVNの公開日の調整
日本の企業・組織では、JVNやJVN iPediaの情報をもとに影響を調査する運用もあります。そうした利用者にも情報を届けるため、GitHubでアドバイザリーの文面を整えるのと並行して、IPAへ脆弱性関連情報を届け出ました。
今回は、IPAの「脆弱性関連情報の届出受付」から届け出ました。第三者が発見した脆弱性を開発者へ中継してもらう場合は「ソフトウエア製品脆弱性関連情報」を使いますが、今回は報告を受けたFluentd開発者の立場で届け出るため、自社製品に準ずる扱いとして「自社製品に関する脆弱性関連情報」を選びました。
届出後のやり取りでは、こちらで予定しているリリース日を伝え、JVNでの公開日をいつにするか調整しました。修正版のリリースと脆弱性情報の公表のタイミングを調整するため、公開前から進めておく作業です。
IPAの担当の方には親身に対応していただき、脆弱性のスコアの付け方に誤りがあることも教えていただきました。こちらはこうした対応に不慣れだったので、とても助かりました。
通常の第三者からの届出ではIPAが受付、JPCERT/CCが製品開発者への連絡と公表の調整を担当しますが、「自社製品に関する脆弱性関連情報」として届け出た場合は開発者への連絡は省略され、公表に向けた調整へ進みます。GitHubへのCVE申請とは別の手続きであり、「Publish advisory」を押すとJVNにも自動的に掲載されるわけではありません。
v1.19.3で対応した脆弱性は、JVN#36011274「Fluentdにおける複数の脆弱性」として公表されています。GitHubの英語のアドバイザリーに加えて、ククログの日本語記事やJVNにも情報を載せることで、国内外の利用者に修正内容と緩和策が届くようにしています。
4. 修正をマージし、修正版をリリースする
リリースの準備が整ったら、アドバイザリー画面から修正PRを本体リポジトリへマージします。Fluentdでのマージ先は master です。
マージ前にコミットを整理する
一時的なプライベートフォークから本体にマージすると、このコミットのように、Merge commit from fork という件名のコミットが作成されました。
今回の画面では、通常のPRのように「Squash and merge」を選ぶ操作は見当たりませんでした。作業中のコミットを一つにまとめたい場合は、マージ前にプライベートフォーク側でsquashしておく必要がありそうです。
ブランチ保護ルールがある場合
「3. アドバイザリーの準備と公開日の調整」で掲載した画像には、This advisory may be blocked by repository rules という表示があります。その下には「Merge and bypass branch protections」のチェックボックスと「Merge pull request」ボタンが表示されています。
通常のPRでCIの成功などを必須にしていても、一時的なプライベートフォークではステータスチェックが実行されません。マージ前にリポジトリのルールと、ローカルでのテスト結果、レビュー結果を確認する必要があります。
今回の画面では、権限のあるメンテナーが「Merge and bypass branch protections」にチェックを入れてマージします。この操作が必要かどうかはリポジトリの設定や権限によります。
マージすると、その時点で公開リポジトリに修正コミットが反映されます。アドバイザリーがドラフトのままでも、修正コードは誰でも読める状態になります。そのため、マージはGemやパッケージをリリースできる準備を整えてから、リリース直前に行います。
マージ後は、FluentdのGemとFluent Packageのリリース作業を進めます。
5. アドバイザリーを公開する
PRをマージし終え、修正版を利用者が入手できることを確認したら、アドバイザリーも公開します。
緑色のボタンの右にあるドロップダウンから「Publish advisory」を選びます。「Request CVE」は非公開のまま採番を依頼する操作、「Publish advisory」はアドバイザリーを一般公開する操作です。同じボタンのメニューに並んでいますが、CVEの申請とアドバイザリーの公開は別の操作なので、誤って公開しないよう注意します。GitHubの公開手順でも、CVEの申請は別の操作として説明されています。
確認ダイアログには、公開すると一時的なプライベートフォークが削除されることが表示されます。「Delete fork and publish」を押すと、フォークが削除され、アドバイザリーが公開されます。
公開後は、GitHubによるレビューを経てGitHub Advisory Databaseに追加されます。その情報が、影響を受けるリポジトリへのDependabotアラートに使われることもあります。アドバイザリーの公開と、これらの反映・通知が同時に完了するわけではありません。詳細は公開後のDependabotアラートの説明を参照してください。
CVEの公開とNVDへの反映
GitHubでアドバイザリーを公開した後も、CVEや脆弱性データベースへの反映には時間差があります。区別しておきたいのは、次の段階です。
- GitHubがCVE番号を割り当てる
- アドバイザリー公開後、GitHubがCVEの詳細をCVE Listへ公開する
- 公開されたCVEがNVDに取り込まれ、NVDでの分析・情報の補完が進む
NVDのFAQによると、NVDはCVE Listで公開された情報を取り込み、分析や情報の補完を行います。CVEの公開と、NVDでの処理は別の段階です。
v1.19.3への対応では、アドバイザリーの公開からNVDへの反映を確認するまでに約3週間かかりました。ただし、この期間をそのままNVDの処理時間とみなすことはできません。CVEの詳細がまだ公開されていない段階と、NVDに掲載されてから分析を待っている段階は分けて確認する必要があります。
脆弱性スキャナが参照するデータソースによっても、検知できる時期は変わります。NVDへの反映を待っている間も、利用者が影響範囲や緩和策を確認できるよう、公開済みのGHSAへ案内できるようにしておきます。
対応を振り返って
GitHub Security Advisoriesを使うと、報告の受付から非公開での修正、レビュー、公開までを一つのアドバイザリーで進められます。一方で、CIが動かないこと、マージした時点で修正コードが公開されること、CVEの採番や各データベースへの反映に時間差があることは、通常の開発とは異なる点でした。
特にCVEの採番は、早めに申請してもリリースまでに間に合うとは限りません。修正版とGHSAを先に公開し、CVE番号は後から案内する進め方も含めて、リリースを準備しておくと対応しやすくなります。
これからOSSの脆弱性対応を行う方の参考になれば幸いです。
