脆弱性開示ポリシー

概要

このページは、NextPDF の協調的脆弱性開示ポリシーです。報告者がメンテナーに非公開で連絡する方法、想定される対応タイムライン、およびエンバーゴの仕組みについて説明します。

境界。 開示ポリシーはプロセスに関するコミットメントであり、タイムラインや結果を保証するものではありません。以下の目標は、報告者に対するメンテナーの誠実なコミットメントです。これらはプロジェクトが従うプロセスを説明するものであり、特定の報告が受領確認され、特定の期日までにトリアージ、修正、または開示されることを約束する契約上の保証ではありません。協調的開示のタイミングは交渉によって決定されるものであり、一方的に保証されるものではありません。

インストール

該当しません。脆弱性を報告するために何かをインストールする必要はありません。機械可読の連絡先情報は /.well-known/security.txt（RFC 9116）で公開されています。人が読める形式の正式なポリシーは、リポジトリの SECURITY.md です。

概念の概要

このポリシーは、ISO/IEC 29147 で定義された協調的脆弱性開示と、ISO/IEC 30111 の処理プロセス（iso_iec_30111#x9.x43.p2）を実装しています。具体的には、非公開での受付、トリアージと深刻度評価、エンバーゴ下での修正フェーズ、および共同での公開リリースです。脆弱性が複数のベンダーに影響する場合、アドバイザリのタイミングは一方的に設定されるのではなく、影響を受ける当事者間で調整されます（iso_iec_29147#x3.x110.p13）。

このプロセスは、EU サイバーレジリエンス法の製造者向け脆弱性対応義務（eu_cra#x1.p191）、および NIST Secure Software Development Framework の「脆弱性への対応」プラクティス（nist_sp_800_218#x15）とも整合しています。いずれも、こうした対応を再現可能なプロセス上の義務として位置付けており、個々の結果が保証されることを約束するものではありません。

API サーフェス

該当しません。開示は API ではなくプロセスです。機械可読の検出用情報は RFC 9116 の security.txt ファイルです。ツールはその Contact: フィールドと Expires: フィールドを解析します。このページでは、以下のチャネルを除き、そのファイルの内容を重複して記載しません。

コードサンプル — クイックスタート

該当しません。脆弱性を報告するために実行するコードはありません。非公開のチャネルを使用してください。

GitHub Security Advisories（推奨 — 保存時に暗号化、監査ログあり）: プロジェクトの GitHub の Security タブでドラフトアドバイザリを作成します。
メール: [email protected] 宛に、件名に [SECURITY] を付けて送信します。エンドツーエンドの暗号化が必要で、公開済みの OpenPGP 鍵がまだ security.txt に記載されていない場合は、代わりに GitHub Security Advisory チャネルを使用してください。

公開された issue、公開メーリングリスト、ソーシャルメディア、またはチャットで報告しないでください。修正前の公開開示は、パッチ未適用バージョンを使用しているユーザーを危険にさらします。

コードサンプル — 本番環境

該当しません。

エッジケースと注意点

目標はコミットメントであり、SLA ではありません。 以下のタイムラインは、プロジェクトが目指す目標を示しています。複数のコンポーネントが関係する複雑な問題や、上流での調整を必要とする問題には、より長い時間がかかる場合があります。その場合も報告者には随時状況が共有されます。
エンバーゴの期間は交渉可能ですが、上限があります。 デフォルトのエンバーゴは、トリアージから修正リリースまでの期間です。より長い期間を必要とする報告者は、アドバイザリを作成する際に明示的にリクエストする必要があります。上限を過ぎると、プロジェクトは業界における協調的開示の慣行に従い、修正が利用可能かどうかにかかわらずアドバイザリを公開します。これにより、アドバイザリが無期限に保留される状態からユーザーを保護します。
深刻度がスケジュールを決定します。 重大かつ実際に悪用されている問題は短縮されたタイムラインで処理されますが、深刻度の低いハードニングの提案は同じ扱いにはなりません。深刻度はトリアージ時に評価され、見直されることがあります。
CVE の発行はトリアージの一部です。 メンテナーは、トリアージステップの一環として、プロジェクトの GitHub Security Advisory CNA 登録を通じて CVE をリクエストします。報告者が別途リクエストする必要はありません。

パフォーマンス

該当しません。

セキュリティに関する注意事項

対応タイムラインの目標は、報告者に対するコミットメントであり、プロジェクトの脆弱性対応のベースラインを形成します。これらは目標であり、保証ではありません。

段階	目標
受領確認	1～2 営業日以内
初期トリアージと深刻度評価	約 5 営業日/7 暦日以内
パッチ開発と非公開レビュー	通常 14 営業日。深刻度に応じて、複雑で確認済みの CVE の場合は 30～90 日
CVE の割り当て（受理された場合）	パッチと同時、GitHub CNA チャネル経由
協調的な公開開示	パッチリリース時、報告者と共同で設定した日付
エンバーゴ（トリアージからリリースまで）	デフォルトは約 90 日。実際に悪用されている場合は短縮、明示的なリクエストにより固定された上限まで延長可能

レビュー担当者が確認できるプロセスルール:

非公開優先。 公開チャネルは受付チャネルとして認められていません。受け付けられるチャネルは、GitHub Security Advisory とセキュリティメールのみです。
一方的ではなく協調的。 開示のタイミングは、報告者および同じく影響を受けるベンダーと交渉して決定されます（iso_iec_29147#x3.x110.p13）。
期限付きエンバーゴ。 エンバーゴにはデフォルト値と厳格な上限があり、アドバイザリが無期限に保留されることはありません。
希望に応じたクレジット。 研究者は、匿名を希望しない限り、エンバーゴが解除された時点でクレジットされます。

これらの記述は、プロジェクトが従うことをコミットするプロセスを説明するものです。特定の報告が、修正、CVE、または特定の期日までの開示につながることを保証するものではありません。

適合性

これは適合性プロファイルではありません。このポリシーは、ISO/IEC 29147 および ISO/IEC 30111、ならびに上記で引用している CRA/SSDF のプロセス上の義務と整合しています。「整合している」という表現は意図的なものです。プロジェクトは、これらのいずれのスキームに対しても認証を主張するものではありません。これらは健全なプロセスのあり方を定義しており、このページはそうしたプロセスを運用するというプロジェクトのコミットメントを記載するものです。