Skip to main content

 

セキュリティ研究者のための
オープンソース ソフトウェア プロジェクトと脆弱性の公表を調整するためのガイダンス

（このページは Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects の参考訳です。）

おめでとうございます！セキュリティ上の脆弱性が見つかりました

そしてどうするのでしょうか？このガイドは、セキュリティ研究者（別名「発見者」）がオープンソース ソフトウェア (OSS) プロジェクトのメンテナーと連携して、強調的脆弱性対応プロセスを開始および参加できるようにすることを目的としています。

はじめる前に

脆弱性の開示プロセスに取り組む際は、完璧なソフトウェアは存在しないということを念頭に置いてください。ソフトウェアは(少なくとも今日では)人によって書かれており、人は時折間違いを犯します。これは、オープンソース ソフトウェア(OSS)だけでなく、クローズド(プロプライエタリ)なソフトウェアにも当てはまります。この問題は、オープン ソース ソフトウェアにとってさらに困難になる可能性があります。これは、OSSを非常に強力にする要因、つまり複数のコントリビューターによって様々に分かれている開発のためです。プロジェクトのライフサイクルのある時点で、ユーザー、コントリビューター、セキュリティ研究者、そしておそらくこのガイドの読者など、誰かがプロジェクトのセキュリティと有用性に影響を与える脆弱性を発見することがあるでしょう。このガイドを適用することで、関係者全員が迅速かつ効果的に対応する準備を整えることができます。

このガイドについて

このガイドは、個人およびOpen Source Security Foundation(OpenSSF) Vulnerability Disclosure Working Groupの貢献によって作成されました。このグループは、脆弱性を公開した経験を持つ個人で構成されており、一般的につまずくポイントから学び、コミュニティがベストエフォートで対応を開始また参照できるようにこのガイドを作成しました。開示は、プロセス内のコンテキストに応じて、さまざまな人々にとってさまざまな意味を持ちます。最終的には、セキュリティ上の欠陥は責任を持ってソフトウェア保守者に報告され、パッチを適用して評価および修正され、ダウンストリームの利用者に何らかの形で通知される必要があります。このグループは、ほとんどのオープンソース プロジェクトに適切なモデルとして協調的脆弱性開示(CVD) を奨励しており、このガイドのアドバイスはそのモデルに従っています。以下の情報は、その内容を正確に取り扱いが必要であり、一連のガイドラインは、協調的な脆弱性の開示前、最中、後に利用可能な多くの選択肢に関する概要を発見者に提供します。脆弱性の開示に関与する人は、ここでのすべてのアドバイスがすべてのオープンソース プロジェクトやすべての脆弱性を開示するイベントに適用されるわけではないことにも注意する必要があります。推奨事項は、それぞれの特定のプロジェクトと開示のニーズに合わせて調整する必要があります。ワーキング グループは以前、オープンソースのメンテナーがCVDプロセスの準備を行い、脆弱性レポートの取得を支援することに重点を置いたガイドをリリースしました。

発見した脆弱性を報告する目的は何ですか?

次のフレームワークはI Am The Cavalryによって作成されたもので、セキュリティの脆弱性を研究する動機の主要なカテゴリをカバーすることを目的としています。以下のフレームワークは包括的なものではありませんが、研究者が問題を発見した理由についての基本的な理解を提供しています。脆弱性を報告する動機にも同じ動機が当てはまります。

  1. 保護– 世界をより安全な場所にします。これらの研究者は、変化をもたらすことができると感じる問題に惹かれます。
  2. パズル– 好奇心からいじくり回します。このタイプの研究者は通常、物事がどのように機能するかを理解することに情熱を持っています。
  3. 名声– 誇りと注目を求めます。これらの研究者は、多くの場合、自分の研究で最も知名度が高く、有名になりたいと考えています。
  4. 利益– お金を稼ぐこと。これらの研究者は、自分のスキルを主な収入または副収入として取引しています。
  5. 抗議/愛国心– イデオロギー的かつ原則に基づいたもの。これらの研究者は、愛国者であろうと抗議者であろうと、大義に対し強く支持するか反対します。

オープンソースのメンテナーとは誰ですか? 

オープンソースのメンテナーは、多くの場合、ソフトウェア エンジニアであり、オープンソース プロジェクトのコントリビューターです。通常、これらのユーザーはリポジトリをコードに関する上位の権限を持っており、リポジトリの設定を管理したり、メイン ブランチへの書き込みアクセスを許可したりできます。通常、プル リクエストとパッチをメイン ブランチにマージし、セキュリティ パッチを含むリリースに含まれるものを制御するのは彼らです。OSSプロジェクトには、その規模、成熟度、関心に応じて1人から複数のメンテナーが存在します。大規模なオープンソース プロジェクトには、そのコミュニティのセキュリティ関連タスクのみを実行する専任の個人またはチームが存在する場合もあります。すべてのオープンソース プロジェクトがまったく同じ方法で編成または開発されているわけではありません。世の中にあるオープンソース コードの大部分は、1人または2人のグループによって開発されています。外部からの関心や貢献が高まるにつれて、これらのプロジェクトの多くはより大きなコミュニティに成長し、開発者とコミュニティをサポートする基盤全体を備える規模にまで成長する場合もあります。一部のOSSプロジェクトは商用ベンダーによって作成されていますが、ほとんどはそうではありません。一部のプロジェクトは、そのグループで提供されるコンテンツを集め、管理し、理想的にはセキュリティ サポートを提供し、ディストリビューションまたはあるディストリビューション内のバンドルを提供します。それでも、これらのコミュニティの多くは、情熱のあるプロジェクトや趣味に時間を費やしているボランティアや専門家で構成されているため、セキュリティ サポートの保証はありません。発見者がソフトウェアのメンテナーと対話するとき、プロジェクトが持つ組織のレベルとその機能を理解し、それに応じて彼らとの対話を調整することが重要になります。たとえば、2人で維持されるプロジェクトには、セキュリティ スキャンと検証を実行するためのテスト インフラストラクチャやツールがない可能性があります。対照的に、ディストリビューションまたは商用サポートが提供されているものには、訓練を受けたアプリケーション セキュリティ エンジニアの専任チームが存在する場合があります。どちらにセキュリティ上の欠陥を報告するかは良好な対話の始めるための重要なポイントですが、前者は最後までやり遂げるためにより多くの関与が必要になる場合があります。同時に、後者では、長期にわたる公開禁止措置や、修復手順の作成とテストを完了するためにより多くの個人を関与させる必要性などの概念が考えられます。

オープンソースのメンテナーの動機は何でしょうか?

発見者やセキュリティ研究者と同様に、オープンソースのメンテナーも次のようなプロジェクトを維持するさまざまな動機を持っています。

  • 彼らは問題を解決や、学術プロジェクトの執筆を行っています
  • 彼らは楽しさを感じている、および/または何か新しいスキル/テクノロジーを学んでいます
  • 彼らはこのプロジェクトを趣味として始めたが、維持費は支払われていない
  • 関係者からの評価を求めている、またはプロジェクトを維持することが自分のキャリアをさらに進めると感じている
  • 彼らは仕事の一環としてオープンソースを使用しており、コミュニティへの貢献を強く意識しています
  • 彼らはプロジェクトで報酬を得られるので、このプロジェクトを始めた
  • 彼らはライブラリを使用しており、メンテナーとして活動を開始した唯一の人物でした

オープンソースのメンテナー/プロジェクトにおいてボランティア能力を強調することは重要です。対話に対する期待は、商業的な活動を行う組織と協力する場合よりもスケジュールが長くなる可能性があることを理解した上で設定する必要があります。人間のやり取りも、提出/トリアージ/修復プロセス中の異なる可能性があります。オープンソースのメンテナーは、より直接的で技術的なコミュニケーション スタイルを採用している場合があります。研究者は、メンテナーが悪意や無礼からこのアプローチを採用しているわけではないことを覚えておく必要があります。代わりに、メンテナーがプロジェクトをサポートし健全にするため、多くの場合ボランティアの立場で賢明に取り組んでいることを理解し、ポジティブな意図を認識できる対話で有るべきです

オープンソースのコントリビューターについてさらに詳しく知るために、Linux Foundationは、 FOSSのメンテナーとコントリビューターの多くの側面を詳しく説明したレポートを発行しました。

協調的脆弱性開示とは何ですか?

協調的脆弱性開示(CVD)は、脆弱性に対応して修正、修復できる個人またはグループと脆弱性の詳細を共有するプロセスです。この対象は通常、オープン プロジェクトのメンテナーですが、プロジェクト開発者、共同作業者、管理者、またはその他の投資関係者が含まれる場合もあります。

CVDプロセスには、脆弱性の詳細を非公開で公開し、脆弱性に対する修正を作成してテストし、その後、修正と詳細をダウンストリームのすべての利用者に同時に公開することが含まれます。この調整により、必要なすべての関係者が修正、連絡、アップデートの準備を同時に行うことができます。この方法で脆弱性を開示する利点は、すべての利用者が同時に修正を利用できるため、特定のグループが他のグループよりも大きなリスクにさらされることがないことです。

ここでユーザーを保護するために、影響緩和策とパッチ適用の段階で情報の開示の抑制の管理を行うことが重要です。

プロジェクトが脆弱性をどのように処理するか (別名「セキュリティ ポリシー」) を理解する

オープンソース プロジェクトは、セキュリティの脆弱性が発見された場合、運用/品質の両方の観点から、不具合に関するレポートをどのように処理するかについて、コントリビューターや発見者と期待する内容について共有する必要があります。これは通常、プロジェクトがどのようにレポートの優先順位付けや対処をするか示すポリシーを通じて伝えられます。セキュリティ ポリシーでは、プロジェクトにおける脆弱性関連情報の処理に関する期待事項を概説する必要があります。通常、このポリシーには次のものが含まれます。

  • 脆弱性情報をプロジェクトに報告する方法に関する情報(電子メール、イシュートラッカーなど)
  • 機密情報の取り扱い方法(暗号化、TLP マーカー)
  • 脆弱性レポートの提出後に報告者が期待できること(対応タイムライン、潜在的な対応決定、別名「バグ バー」)
  • 適用免除基準(誠意を持って行われた脆弱性報告に対して法的措置は取らないことを約束する明示的な声明)

セキュリティ ポリシーは、リポジトリ内のSECURITY.mdファイルやプロジェクトの Webサイトに配置されたSECURITY.txtファイル、会社/プロジェクトWebサイト自体として表現されていることがあります。これらのファイルには通常、上記の情報に加えて、プロジェクトのセキュリティ チームの連絡先情報が含まれています。

セキュリティ ポリシーでは、レポートの提出方法とプロジェクトがそれをどのように処理するかを説明する必要がありますが、脆弱性レポートを提出するための多くの受付方法があります。この詳細はセキュリティ ポリシー内に明示的に含める必要があります。脆弱性の提出の受け付けは、セキュリティ関連の電子メール アドレスのリスト (報告者が新しい脆弱性/潜在的な脆弱性を提出する宛先となるsecurity@のEメールのエイリアス)、不具合/イシューのトラッカー、またはサードパーティのVDPまたはバグ報奨金プラットフォームを介した提出まで多岐にわたります。プロジェクトが公開している期待する対応方法に従うことで、この問題に関して協力する用意があることが示され、問題が迅速に解決される可能性が高まります。

セキュリティ ポリシーのもう1つの要素は、報酬の明確化です。脆弱性開示プログラム(VDP)には、通常、報告された脆弱性に対する報酬体系が暗黙的に含まれていません。公開のタイミングを調整することは、前例に従い適切に従わなければいけません。プログラムが金銭的な報酬を提供する場合、それは多くの場合、バグ報奨金プログラム(BBP)と呼ばれます。BBPは本質的にはVDPと同じ目的/目標を果たし、プロジェクトのメンテナーへの脆弱性の報告を促進します。VDPと同じような仕組みを含むと明確に示されたセキュリティ ポリシーを手にすることができ、それは報酬の範囲が明確に定義される可能性があります。

プロジェクトが選択した受け入れ方法の種類に関係なく、脆弱性を報告する際にはセキュリティ ポリシーをよく読むことが重要です。一部のポリシーには、メンテナーまたはメンテナンスする組織の許可なしに脆弱性の詳細を一般または第三者に開示することを禁止する非公開ポリシー(いわゆるNDA)が含まれています。オープンソースを対象とするBBPは非常にまれですが、営利団体がオープンソース プロジェクトをサポートし、非公開または招待制のBB を運営し、そのような組織と協力する場合、この種の契約に遭遇する可能性があります。これらの場合には、開示についてより厳格な要件となる場合があります。他の契約と同様に、規約をよく読むことをお勧めします。

ある特定のプロジェクトの脆弱性報告方法やセキュリティ ポリシーを探そうとしている場合は、discover.ioなどのオープン ソース データベースも参照先として利用できます。もし、プロジェクトがCVE命名機関(CNA)によるCVEプログラムの一部である場合、その連絡先情報とセキュリティ ポリシーはCVEプログラムのパートナーのリストに含まれるでしょう。

プロジェクトの CVD チャネルを見つけるための追加のソース

明確に定義されたセキュリティ連絡先情報が見つからない場合は、次の解決策を試してください。

  1. イシュートラッカーを使用してセキュリティ担当者を公開リクエストする。
  2. 電子メール、ソーシャル メディア、またはプロジェクトのリアルタイム チャット システムを通じて、プロジェクトのメンテナー、オーナー、または最も積極的な活動するコントリビューターに連絡する。
  3. プロジェクトがより大きなコミュニティの一部であるか、連絡先や専任のセキュリティ チームがいる可能性のある団体の一部であるかを理解する。
  4. プロジェクトの組み込みやサポートできる商用ベンダーに連絡する。
  5. 関連するメーリング リスト、oss-securityなどに連絡し、プロジェクトに開示したい非公開のイシューがあることを伝える。
  6. 連携の支援を受けるため、MITRE/CVEやCERT/CCなどのサードパーティ組織に連絡する。

これらのソリューションのいずれかを使用する場合は、適切な相手と適切なコミュニケーション チャネルを設定するまで、機密情報を共有しないようにしてください。

簡単に受け付け・開示ができるようにレポートを作成する

提案事項：最初に公開する内容は、連絡を取り合うメンテナーだけでなく一般利用者に向けて記述してください。これにより、脆弱性に関するプロセスの最後に一般向けにレポートを書き直す必要がなくなります。

有益な情報を提供する

脆弱性レポートには、メンテナーが問題を自分で再現できるように、十分に脆弱性の詳細について含める必要があります。公開されている参考文献も必ず含めてください。レポートで回答を記しておく必要がある質問は、次のようなものがあります。

  • どのような問題が見つかりましたか?
  • どのバージョンに脆弱性があると思われますか?
  • 脆弱性が含まれる製品、パッケージ、またはプロジェクトは何ですか?
  • 脆弱性を見つけるためにどのような手順を実行しましたか?
    • 脆弱性を再現するために必要となる特定のソフトウェアおよびハードウェア要件を含めます。
    • 実証実験環境(POC)またはエクスプロイト例がある場合は、メンテナーまたはプロジェクトのセキュリティ メンバーへの安全なチャネルを確立した後にそれを含めます。
  • プロジェクトのソース コードのどの行が脆弱ですか?
    • 根本原因を特定できますか?
    • これがいつ導入されたか特定できますか?
  • 悪用された場合、どのような影響がありますか?
    • 重大度 (CVSSv3.1) スコアを推定できますか? メンテナー/プロジェクトはこのコードの専門家であるため、スコアを見直する可能性があることに注意してください。ここで、不具合がどのように動作するかを伝え、影響について話し合う機会となります。
    • この脆弱性はどのCWEに該当しますか? CWE情報は、攻撃を分類するのに役立ちます。分類は、物理、メモリ(バッファ オーバーフロー)、ROPなどです。問題がどこに該当するか確認するのに役立ち、メンテナーが他の潜在的に関連する脆弱性を見つけるための情報を提供します。
  • これが積極的に悪用されているかどうか知っていますか?
  • 修復または軽減に関する手順を提案できますか? この情報は、多くの場合において、脆弱性の解決を早めるのに役立ちます。パッチはいつでも大歓迎です。
  • この情報の公開に影響する時間的な制約はありますか?(会議への提出、既存の公開予定日、個人開示ポリシー)。
  • この情報は他の誰かと共有されましたか?もし共有された場合、いつ、どのように共有されましたか?
  • あなたが見つけたことを示すために、メンテナーとオンラインで合うことを希望しますか?

脆弱性レポートのサンプル/テンプレートは、以下の付録に含まれています。

開示

脆弱性の開示は過去10年間で大幅に一般化しましたが、ソフトウェアの脆弱性の開示に抵抗する当事者が依然として存在します。これは、プロセスに不慣れであるか、脆弱性開示プロセスを管理するための適切な機能やリソースを持っていないことが原因である可能性があります。オープンソースのメンテナーに報告するときは、常に前向きな意図を前提とし、特に、彼らは無給のボランティアであるか、コードを書くのが好きなだけで、報告内容を理解するためのトレーニングや背景となる情報を持っていない可能性があることを考慮してください。

開示に対する期待を適切に設定する

脆弱性の開示に取り組むときは、自分自身の目標と期待を早めに宣言することをお勧めします。これにより、すべての関係者がどのように関与するのかその境界を理解できるようになります。

脆弱性の開示はほとんどの場合うまくいきますが、時折、メンテナーが反応しなかったり、脆弱性の影響について意見の相違があったり、メンテナーが脆弱性の修正よりも他の作業を優先したりすることがあります。脆弱性開示のタイムラインを事前に明記しておくことで、いつどのように開示されるかについて明確な予想を立てることができます。このような明確な期限は、メンテナーが脆弱性を修正するために必要な時間を十分に確保し、ユーザーが長期間気付かないまま放置されず、修正ができるだけ早くリリースされることを保証するのに役立ちます。

ソフトウェア開発に関するメモ

通常、ソフトウェア開発者はソフトウェア開発ライフサイクル (SDL) モデルに従います。このモデルは、少なくとも以下のいくつかのフェーズで構成されており、それぞれが次の段階へと進んでいきます。このプロセスは通常、何度も実行され、最後のステップから最初に戻る形で循環していきます（詳細についてはこの記事を参照してください）。

  • 要件の収集 – 問題を特定し、優先順位を付けます。
  • 設計 – 収集した要件を分析し、それらを満たす方法を理解します。
  • 開発 – 設計を実装するコードを作成し、レビューして承認します。
  • 検証 – 新しい問題が発生したり、既存の機能が低下したりすることなく、コードが問題を解決することを検証します。
  • リリース – ユーザーが目的に合わせてソリューションを利用できるように新しいコードをビルドし、パッケージ化します。
  • メンテナンス/モニタリング/フィードバックの収集 – 次のサイクルで必要となる要件の基礎となるフィードバックを収集しながら、時間をかけてソリューションをメンテナンスします。

一般に、オープンソース プロジェクト チームと外部から脆弱性の発見者として協力することは、最後のメンテナンス/フィードバック収集フェーズで行われます。その目的は、次のサイクルでその修正が含まれるようにし、脆弱性の優先順位を高くするためです。

開示方法の選択肢

最も一般的な開示方法のいくつかを以下にリストします。これらは互いに排他的ではなく、場合によっては何らかの方法で重複するなど、順番に実施することができます。どのようなルートを採用するかはあなた次第ですが、OpenSSFはここでのガイダンスも提供します。このガイダンスは、大まかに言うと、あらゆる形式の脆弱性の開示が、このドキュメント全体にわたるCVDガイドラインに従って、調整された方法で行われるというものです。以下は、開示がどのようなものかを説明する開示方法のリストです。特に明記されていない限り、これらはそれぞれ、発見者とプロジェクトの共同作業として実行されるものとなります。

脆弱性の開示を調整するには、通常、発見者とプロジェクトの管理者との間の健全な協力が必要です。スムーズな開示のためには多くの詳細について合意する必要があるため、各CVDインスタンスの早い段階で詳細について両当事者間で話し合うことをお勧めします。

ここに開示文に関する小さなメモを記載します。研究者には、プロセスの早い段階でレポートの内容が可能な限り完全となるよう検討することをお勧めします。完全な分析とレポートは、セキュリティアドバイザリ、情報開示の通知、ブログの投稿、初期レポートとして再利用できるため、かなりの時間と労力を節約できます。

開示方法 説明 シナリオ例 OpenSSF
推奨
開示なし 発見者は情報を自分自身に保持し、管理者、一般人、
または非公開で他の人と共有しません。		 企業による対応
調整済み CVD (協調的脆弱性の開示) には、「脆弱性発見者から
情報を収集し、関連する利害関係者間でその情報の共有を
調整しソフトウェアの脆弱性の存在とその軽減策を
一般の人々を含むさまざまな利害関係者に開示すること」
が含まれます。- CERT/CCによる定義		 X
限定 脆弱性に関する情報の一部を公開しますが、
一部の情報は非公開にします (例：POCを公開しない)。		 秘密保持契約(NDA)
の締結、信頼できる
パートナー 等		 X
すべて 脆弱性の詳細の公表（調査、得られた結果、
特定の状況におけるPOC）		 サードパーティ
プラットフォーム
での完全な開示		 X
ゼロデイ 金銭のためではない/完全な開示：研究者は、自分の研究に
対して金銭を受け取りたくない場合があり、脆弱性やPOCを
完全に開示して、修正されパッチが適用されるまで、
影響を受ける製品を脆弱なままにしておきます。
販売：一般な営利目的。これは通常、研究者が未公開の
脆弱性に対して報奨金を提供する民間企業に研究結果を
販売することを意味します。

CVE ID の取得

CVE ID は脆弱性のための一意に割り当てられる識別子です。何らかの形でエンド ユーザーに出荷されるソフトウェアに脆弱性が存在する場合、そのソフトウェアは CVEを受け取る必要があります。脆弱性にCVE識別子があることで、その脆弱性が別の脆弱性と混同されないようにすることができ、エンドユーザーやセキュリティ コミュニティが問題を認識して対処する可能性が高めることができます。多くの脆弱性対応プロセスにおいて、脆弱性を確認し、修正するためには、脆弱性に割り当てられているCVEが重要になります。CVEは、ユーザーが特定のシステム バージョンのセキュリティ リスクについて学習でき、パッチが適用されたバージョンへの更新を選択するのに役立ちます。

報告者は、開示プロセス中の任意の時点でCVEプログラムかCVE識別子を取得できます。これは、メンテナーに報告した後に取得することもできますが、識別子を含めることができるように、一般に公開する前に取得するのが理想的です。CVEを取得するには、報告者またはメンテナーは適切なCVE Numbering Authority (CNA)に連絡する必要があります。CNAは、新しい脆弱性にCVE識別子を割り当てる権限を与えられた組織です。CNAにはさまざまなスコープがあり、そのスコープ外ではCVEを発行しません。プロジェクトメンテナーは、プロジェクトを対象範囲とする、最初に問い合わせる先となるCNAとの関係をすでに確立している場合があります。報告者は、可能な限りメンテナーと協力してCVEを取得する必要があります。CVEの管理を行う組織であるMITREは、オープンソース プロジェクトにおける「ラストリゾートとなるCNA」でもあり、より適切な範囲のCNAがない場合に使用できます。

その他の脆弱性識別子。フォーマットとデータベース

CVEに加えて、その他の多くの脆弱性識別子、形式、データベースが存在し、セキュリティ業界で使用されています。CVEは脆弱性識別子として存在し、それらの情報はデータベースに記録されています。情報の共有が行われた場所に応じて、脆弱性には異なる識別子または保管的な識別子が割り当てられる可能性があります。

協調的な脆弱性開示に関する一般的な課題のトラブルシューティング

協調的脆弱性開示プロセスがスムーズに進まないことがあります。このセクションでは、遭遇する可能性のあるいくつかの潜在的な課題に対するアドバイスを提供します。

プロジェクトのメンテナーがレポートをセキュリティ上の問題とは判断しない

脆弱性レポートがメンテナーによってセキュリティ上の問題とはみなされなかった場合は、その決定の背景について直接的に質問し、理論的な根拠をより深く理解することができるかもしれません。メンテナーがその領域の専門家と協力して追加の意見や意見を収集したかどうかを確認してください。レポートに不明確な点がないかを尋ね、あなたのレポートおよび/またはその後のコミュニケーションに次の要素が含まれていることを確認してください。

  • 脆弱性はコードのどの行にありますか?
  • この脆弱性は具体的にどのようにセキュリティ リスクを引き起こすのか?
  • プロジェクトがコードをそのまま放置した場合、攻撃者は最終的に何をすることができるのか?
  • プロジェクトでは問題をどのように再現できるのか? / チームに見せたい実用的なPOCはあるか?
  • 問題を解決するにはプロジェクトは何をしなければいけないか?

プロジェクトが問題をより深く理解し、問題を修正できるよう支援するために追加の時間を投資する意思がある場合は、そのことをメンテナーに明確に伝えてください。彼らがこの追加の支援を受け入れた場合は、彼らの時間を尊重し、協力的かつ率直なアプローチをとって、協力して脆弱性を修復できるようにしてください。

ゼロデイ脆弱性に関する注意事項

トレンドマイクロによると、ゼロデイ脆弱性とは、公開されたもののまだパッチが適用されていないシステムまたはデバイスの脆弱性です。ゼロデイ脆弱性を攻撃するエクスプロイトはゼロデイエクスプロイトと呼ばれます。(出典)

ゼロデイ脆弱性は、公開しているブログやメーリング リストを通じて発表したり、TwitterやSeclist Full Disclosure Mailing Listなどのチャネルを通じて共有したりできます。この開示パスを使用する場合でも、CVE IDの取得を試み、それを最初の開示に含める必要があります。何らかの理由で、支援するCNAがCVE IDの発行に応じない場合、CVEシステムには正式な異議申し立てプロセスがあります。

謝辞

Googleオープンソース プログラム オフィスとGoogleセキュリティ チーム、OpenStack脆弱性管理プロセス、Project Zeroの開示プロセス、Kubernetesのセキュリティと開示プロセスなど、このガイドの活動に貢献した広範なセキュリティおよびオープンソース コミュニティに感謝します。また、この文書の作成にMITREからの多くのリソースを利用していることについても強調させていただきます。

付録

用語集

用語集とその定義については、OpenSSFの教育SIGの用語リポジトリを参照してください。

参考文献

この参考文献は、Webページのスナップショットとともに、このZoteroグループでも見つけることができます。

テンプレート/例

翻訳協力：松本央

Close Menu